Technology Tales

Moves to Hugo

What amazes me is how things can become more complicated over time. As long as you knew HTML, CSS and JavaScript, building a website was not as onerous as long as web browsers played ball with it. Since then, things have got easier to use but more complex at the same time. One example is WordPress: in the early days, themes were much simpler than they are now. The web also has got more insecure over time, and that adds to complexity as well. It sometimes feels as if there is a choice to make between ease of use and simplicity.

It is against that background that I reassessed the technology that I was using on my public transport and Irish history websites. The former used WordPress, while the latter used Drupal. The irony was that the simpler website was using the more complex platform, so the act of going simpler probably was not before time. Alternatives to WordPress were being surveyed for the first of the pair, but none had quite the flexibility, pervasiveness and ease of use that WordPress offers.

There is another approach that has been gaining notice recently. One part of this is the use of Markdown for web publishing. This is a simple and distraction-free plain text format that can be transformed into something more readable. It sees usage in blogs hosted on GitHub, but also facilitates the generation of static websites. The clutter is absent for those who have no need of the Gutenberg Editor on WordPress.

With the content written in Markdown, it can be fed to a static website generator like Hugo. Using defined templates and fixed assets like CSS together with images and other static files, it can slot the content into HTML files very speedily since it is written in the Go programming language. Once you get acclimatised, there are no folder structures that cannot be used, so you get full flexibility in how you build out your website. Sitemaps and RSS feeds can be built at the same time, both using the same input as the HTML files.

In a nutshell, it automates what once needed manual effort used a code editor or a visual web page editor. The use of HTML snippets and layouts means that there is no necessity for hand-coding content, like there was at the start of the web. It also helps that Bootstrap can be built in using Node, so that gives a basis for any styling. Then, SCSS can take care of things, giving even more automation.

Given that there is no database involved in any of this, the required information has to be stored somewhere, and neither the Markdown content nor the layout files contain all that is needed. The main site configuration is defined in a single TOML file, and you can have a single one of these for every publishing destination; I have development and production servers, which makes this a very handy feature. Otherwise, every Markdown file needs a YAML header where titles, template references, publishing status and other similar information gets defined. The layouts then are linked to their components, and control logic and other advanced functionality can be added too.

Because static files are being created, it does mean that site searching and commenting, or contact pages cannot work like they would on a dynamic web platform. Often, external services are plugged in using JavaScript. One that I use for contact forms is Getform.io. Then, Zapier has had its uses in using the RSS feed to tweet site updates on Twitter when new content gets added. Though I made different choices, Disqus can be used for comments and Algolia for site searching. Generally, though, you can find yourself needing to pay, particularly if you need to remove advertising or gain advanced features.

Some commenting service providers offer open source self-hosted options, but I found these difficult to set up and ended up not offering commenting at all. That was after I tried out Cactus Comments only to find that it was not discriminating between pages, so it showed the same comments everywhere. There are numerous alternatives like Remark42, Hyvor Talk, Commento, FastComments, Utterances, Isso, Mouthful, Muut and HyperComments but trying them all out was too time-consuming for what commenting was worth to me. It also explains why some static websites even send readers to Twitter if they have something to say, though I have not followed this way of working.

For searching, I added a JavaScript/JSON self-hosted component to the transport website, and it works well. However, it adds to the size of what a browser needs to download. That is not a major issue for desktop browsers, but the situation with mobile browsers is such that it has a sizeable effect. Testing with PageSpeed and Lighthouse highlighted this, even if I left things as they are. The solution works well in any case.

One thing that I have yet to work out is how to edit or add content while away from home. Editing files using an SSH connection is as much a possibility as setting up a Hugo publishing setup on a laptop. After that, there is the question of using a tablet or phone, since content management systems make everything web based. These are points that I have yet to explore.

As is natural with a code-based solution, there is a learning curve with Hugo. Reading a book provided some orientation, and looking on the web resolved many conundrums. There is good documentation on the project website, while forum discussions turn up on many a web search. Following any research, there was next to nothing that could not be done in some way.

Migration of content takes some forethought and took quite a bit of time, though there was an opportunity to carry some housekeeping as well. The history website was small, so copying and pasting sufficed. For the transport website, I used Python to convert what was on the database into Markdown files before refining the result. That provided some automation, but left a lot of work to be done afterwards.

The results were satisfactory, and I like the associated simplicity and efficiency. That Hugo works so fast means that it can handle large websites, so it is scalable. The new Markdown method for content production is not problematical so far apart from the need to make it more portable, and it helps that I found a setup that works for me. This also avoids any potential dealbreakers that continued development of publishing platforms like WordPress or Drupal could bring. For the former, I hope to remain with the Classic Editor indefinitely, but now have another option in case things go too far.

Turning off the full height editor option in WordPress 4.0

Though I casually follow WordPress development, it's not nearly as rigorous as when I submitted a patch that earned me a mention on a main WordPress release's contributor list. This may explain why I barely noticed the full editor setting, which is turned on by default.

WordPress has become so mature now that I almost do not expect major revisions like the overhauls received by the administration back-end in 2008. The second interface was got so right that it still is with us, even if there were concerns in my mind at the time as to how usable it would be. Sometimes, those initial suspicions can come to nothing.

However, WordPress 4.0 introduced a major editor change that I'm not sure is successful. A full-height editor sounds good in principle, but its implementation has rough edges that make me wonder if any UX person reviewed it. Scrolling becomes strange, with the editor's toolbar fixing in place when you scroll down far enough. The sidebar then scrolls out of sync with the editor box, creating an odd sensation. Keyboard shortcuts like CTRL + HOME and CTRL + END don't work properly, which convinced me this new arrangement wasn't for me and I wanted to disable it.

A Google search found nothing useful, so I tried the WordPress.org forum. This revealed I should have looked in the screen options dropdown box for "Expand the editor to match the window height" to deselect it. Because of a Visual Editor control there, I'd checked the user profile screen but found nothing, showing the setup logic is poor. Perhaps the Visual Editor option should be a screen option too. Thankfully, the window height editor setting only needs changing once for both posts and pages, covering all situations.

With a distraction-free editing option available, I'm not sure why someone added the full height editor too. If WordPress keeps this feature, it needs refinement to behave more conventionally. I wouldn't build a website with such ill-synchronised scrolling. This needs work, as does the Visual Editor setting location. Perhaps both settings should be at the user level, rather than having one above that level. Before finding the solution, I considered using distraction-free mode permanently and installed the WP Editor plugin. I kept the plugin for its code highlighting, even though entering code view always creates a new revision. Despite this issue, things are now better.

Setting the PHP version in .htaccess on Apache web servers

The default PHP version on my outdoors, travel and photography website is 5.2.17 and that is getting on a bit now since it is no longer supported by the PHP project and has not been thus since 2011. One obvious impact was Piwik, which I use for web analytics and needs at least 5.3.2. Since WordPress 4.0 will not work without having 5.2.24 or later, that upgrade became implausible. Therefore, I contacted Webfusion's support team, and they showed me how to get to at least 5.3.3 and even as far as 5.5.9. The trick is the addition of a line of code to the .htaccess file (near the top was my choice) like one of the following:

PHP 5.3.x

AddHandler application/x-httpd-php53 .php

PHP 5.5.x

AddHandler application/x-httpd-php55 .php

When I got one of these in place, things started to look promising, but for a locked database due to my not watching how big it had got. Replacing it with two additional databases addressed the problem of losing write-access, though there was a little upheaval caused by this. Using PHP 5.5.9 meant that I spotted messages regarding the deprecation of the mysql_connect function, so that needed fixing too. Prefixing it with @ might have been a temporary fix while I sought a more permanent one. Thus, I opted for piggybacking off what WordPress uses; make use of MySQLi or PDO_MySQL are other options. Sorting the database issue meant that I saw the upgrade message for WordPress as well as a mix of plugins and themes, so all looked better, leaving me to be less concerned about losing security updates. Also, I am up to the latest version of Piwik too, and that's an even better way to be.

Changing to CKEditor from FCKEditor for WordPress Content Editing

The post editor that I have been using on my WordPress-powered outdoors blog has not been TinyMCE but FCKEditor. My use of that editor has meant that WordPress' autosave and word counting features have not been available to me. As strange as it may sound to some, that is my choice. Even so, there have been times when I have missed the autosaving functionality and lost work.

Since FCKEditor has been replaced by CKEditor, there are plugins available for adding that editor to WordPress' administration interface. Recently, I replaced the old FCKEditor plugin with a newer CKEditor one, which has gained me post or page autosaving. Though the more cosmetic word counting feature is not active until a draft is manually saved, I can live with that.

Other than that, the interface remains familiar with all (X)HTML tags shown in the source code view without any being hidden away from view like on WordPress' implementation of TinyMCE. That isn't to see that WordPress is doing something wrong, only that there are alternative ways of doing things, that are equally valid. After all, why would there be choices if there only ever was one right way to do anything?

Like any WordPress plugins, those replacing the default content editor on WordPress can be vulnerable to changes in the publishing platform, and there is one of those in the pipeline for 3.2: a minimalist post/page editor that is billed as being non-distracting. That planned new feature is drawing inspiration from the likes of QuietWrite, where you can write content and transfer it over to WordPress or leave it where it was written.

Even with substantial changes like this, my experience never has been that design decisions made for new WordPress releases have restricted to any great extent how I use the thing. That's not to say that my usage hasn't changed over time, yet I have felt that any decisions were mine to make and not all made for me. In that light, I can foresee CKEditor continuing to work on WordPress 3.2 along with some testing ahead of time to be sure that is the case.

Turning off the admin bar in WordPress 3.1

Work on WordPress 3.1 is in full swing at the moment, though I initially thought that they were taking a little break after 3.0. From what I can see, many refinements are being made to the multi-blog functionality and behind-the-scenes work is ongoing on the administration screens too.

Another under-the-bonnet change has been to make WordPress less tied to MySQL, since the possibility of dropping in support for an alternative such as PostgreSQL is now a reality even if it isn't part of the default package. For now, it looks as if this will be plugin territory rather than default multi-database support, though that may become a sensible development in the light of Oracle's acquisition of MySQL and its sabre-rattling regarding Java patents. So far, the change to WordPress has affected my use of its database engine to power an offline version of my online photo gallery, but a quick spot of code editing sorted that issue.

One more obvious alteration will be the addition of a WordPress.com style administration bar to the top of all content and administration screens for a user who is logged into the system. Though it will be turned on by default, there will be the option of turning it off for those among who prefer things that way. All that will be needed for this is to add the following line near the top of wp-config.php:

define( "WP_SHOW_ADMIN_BAR", false);

The chance to see new additions like those above and be ready for is my main reason for following WordPress development. It's best to be ready instead of being surprised, though it has to be said that the blogging or CMS platform is a very polished one these days.

Removing a column from a MySQL data table

My trying out WordPress 3.0 in advance of its final release has brought me errors on the management page for website links. After a spot of poking around the TRAC, I found that the bug already has been reported and that the cause is an extraneous column in the *_links table called link_category. The change in taxonomy handling over the years seems to have made it redundant, so I removed the said column from the database using a command like the following from both the MySQL command line and MySQL Query Browser:

alter table database.wp_links drop link_category;

That seems to have made those errors go away, and I hope that their upgrade code takes care of this before WordPress 3.0 is let loose of the general blogging public. Taking out the coding brittleness would do too.

Going mobile

Now that the mobile web is upon us, I have been wondering about making my various web presences more friendly for users of that platform, and my interest has been piqued especially by the recent addition of such capability to WordPress.com. With that in mind, I grabbed the WordPress Mobile Edition plugin and set it to work, both on this blog and my outdoors one. Well, the results certainly seem to gain a seal of approval from mobiReady so that's promising. While it comes with a version of the Carrington Mobile theme, you need to pop that into the themes directory on your web server yourself, as WordPress' plugin installation routines won't do that for you. It could be interesting to see how things go from here, and the idea of creating my own theme while using the plugin for redirection honours sounds like a way forward; I have found the place where I can make any changes as needed. Homemade variants of the methodology may find a use with my photo gallery and Textpattern sub-sites.

Investigating Textpattern

With the profusion of Content Management Systems out there, open source and otherwise, my curiosity has been aroused for a while now. In fact, Automattic's aspirations for WordPress (the engine powering this blog) now seem to go beyond blogging and include wider CMS-style usage. Though some may even have put the thing to those kinds of uses, I believe that it has a way to go before it can put itself on a par with the likes of Drupal and Joomla!.

Speaking of Drupal, I decided to give it a go a while back and came away with the impression that it's a platform for an entire website. At the time, I was attracted by the idea of having one part of a website on Drupal and another using WordPress, but the complexity of the CSS in the Drupal template thwarted my efforts and I desisted. The heavy connection between template and back end cut down on the level of flexibility too. Though that mix of different platforms might seem odd in architectural terms, my main website also had a custom PHP/MySQL-driven photo gallery too and migrating everything into Drupal wasn't going to be something that I was planning. Since I might have been trying to get Drupal to perform a role for which it was never meant, I am not holding its non-fulfillment of my requirements against it. While Drupal may have changed since I last looked at it, I decided to give an alternative a go regardless.

Towards the end of last year, I began to look at Textpattern (otherwise known as Txp) in the same vein, and it worked well enough after a little effort that I was able to replace what was once a visitor dossier with a set of travel jottings. In some respects, Though Textpattern might feel less polished when you start to compare it with alternatives like WordPress or Drupal, the inherent flexibility of its design leaves a positive impression. In short, I was happy to see that it allowed me to achieve what I wanted to do.

If I recall correctly, Textpattern's default configuration is that of a blog, which means that it can be used for that purpose. So, I got in some content and started to morph the thing into what I had in mind. Because my ideas weren't entirely developed, some of that was going on while I went about bending Txp to my will. Most of that involved tinkering in the Presentation part of the Txp interface, though. It differs from WordPress in that the design information like (X)HTML templates and CSS are stored in the database rather than in the file system à la WP. Txp also has its own tag language called Textile and, though it contains conditional tags, I find that encasing PHP in <txp:php></txp:php> tags is a more succinct way of doing things; only pure PHP code can be used in this way and not a mixture of such in <?php ?> tags and (X)HTML. A look at the tool's documentation together with a perusal of Apress' Textpattern Solutions got me going in this new world (it was thus for me, anyway). The mainstay of the template system is the Page, while each Section can use a different Page. Each Page can share components and, in Txp, these get called Forms. These are included in a Page using Textile tags of the form <txp:output_form form="form1" />. Style information is edited in another section and you can have several style sheets too.

The Txp Presentation system is made up of Sections, Pages, Forms and Styles. The first of these might appear in the wrong place when being under the Content tab would seem more appropriate but the ability to attach different page templates to different sections places their configuration where you find it in Textpattern and the ability to show or hide sections might have something to do with it too. As it happens, I have used the same template for all bar the front page of the site and got it to display single or multiple articles as appropriate using the Category system. Though it may be a hack, it appears to work well in practice. Being able to make a page template work in the way that you require really offers a considerable amount of flexibility; it allowed me to go with one sidebar rather than two as found in the default set up.

Txp also has the facility to add plugins (look in the Admin section of the UI) and this is very different from WordPress in that installation involves the loading of an encoded text file, probably for the sake of maintaining the security and integrity of your installation. I added the navigation facility for my sidebar and breadcrumb links in this manner, with back end stuff like Tiny MCE editor and Akismet coming as plugins too. While there may not be as many of these for Textpattern, the ones that I found were enough to fulfil my needs. If there are plugin configuration pages in the administration interface, you will find these under the Extensions tab.

To get the content in, I went with the more laborious copy, paste and amend route. Given that I was coming from the plain PHP/XHTML way of doing things, the import functionality was never going to do much for me with its focus on Movable Type, WordPress, Blogger and b2. The fact that you only import content into a particular section may displease some, too. Peculiarly, there is no easy facility for performing a Textpattern to Textpattern migration apart from doing a MySQL database copy. While some alternatives to this were suggested, none seemed to work as well as the basic MySQL route. Tiny MCE made editing easier once I went and turned off Textile processing of the article text. This was done on a case by case basis because I didn't want to have to deal with any unintended consequences arising from turning it off at a global level.

While on the subject of content, this is also the part of the interface where you manage files and graphics along with administering things like comments, categories and links (like a blog roll on WordPress). Of these, it is the comment or link facilities that I don't use, allowing me to turn comments off in the Txp preferences. So far, I am using categories to bundle together similar articles for appearance on the same page, while also getting to use the image and file management side of things as time goes on.

All in all, it seems to work well, even if I wouldn't recommend it to the sort of audience to whom WordPress might be geared. My reason for saying that is because it is a technical tool that is used best if you are prepared to your hands dirtier from code cutting than other alternatives. I, for one, don't mind that at all because working in that manner might actually suit me. Nevertheless, not all users of the system need to have the same level of knowledge or access; usefully, it is possible to set up users with different permissions to limit their exposure to the innards of the administration. In line with Textpattern's being a publishing tool, you get roles such as Publisher (administrator in other platforms), Managing Editor, Copy Editor, Staff Writer, Freelancer, Designer and None. Those names may mean more to others, but I have yet to check out what those access levels entail because I use it on a single user basis.

Txp may lack certain features, such as graphical visitor statistics instead of the current text listings. While, its administration interface could benefit from refinement, it fulfils my core requirements. The more streamlined approach makes it more practical in my opinion, which is demonstrated by my creation of A Wanderer's Miscellany. Consider exploring it yourself to see what's possible, since I am certain that I have only scratched the surface of Textpattern's capabilities.

Remove Revisions 2.2

There is already a post on here devoted to version 1.0 of this plugin, which clearly tells you what it does. The new version will work with the forthcoming WordPress 2.7 (itself a release that's had a development cycle with such upheavals that it would make you want to watch from the relative safety of the sidelines) and has been made to be a little more user-friendly in its actions; in fact, it behaves more like any other plugin now.

Download Remove Revisions 2.2

A radical new look on the way for WordPress' administration area

One thing that you can never say about Automattic is that it stands still for very long. That may generate adverse commentary from some, yet it's bad to leave things stagnate, too. In fact, resting on laurels also generates flak, so you can't please everyone all the time.

Earlier on this year, the WordPress administration screens went through something of an overall for version 2.5. In hindsight, it wasn't terribly dramatic, but the prospect had me checking out what was happening with the development version and contributing to the project in my own small way. Now, it appears that a bigger upheaval is in prospect with wireframes and what not being brought into play on the design side.

The first change that anyone will notice is that the navigation has moved from the top to the side, and that some things have been moved around and renamed. Another thing that you'll see soon enough is that there is a QuickPress section added to the dashboard screen for those quick and short postings. Sticking with the subject of content creation, alterations to post and page editing screens and the link creation screen are obvious too. The thing that really comes to mind here is the level of customisation on offer, so you can make yourself feel right at home: some of the screen furniture can be moved about, and you can remove what you feel is nothing but useless clutter. Content generates comments, so the addition of keyboard shortcuts for comment moderation should be a boon for those with very active readers.

Some functionality currently added by plugins is getting incorporated in the main application. An example is automatic upgrades of WordPress itself. In the development version, it installs the latest nightly build, but I am certain that it can be made to point to the latest stable release. That makes it more convenient for keeping a backseat eye on things rather than getting stuck into the hurly-burly of checking on what's in Subversion.

There are some pieces that remain incompletely functional at present, such as the Inbox and Media added to this post pieces, but I have seen nothing that used to work to be broken. So, while the development version of WordPress is more of a work in progress than I have seen for a while, it will do what you need it to do. Since you always need to be cautious, I'd advise you to keep away until it's ready for the big time, unless you have the knowledge to put things back should the undesirable befall your blog. I had an automatic WordPress update kick in maintenance mode without turning it off again. Nothing happened to the database, so a manual re-installation was all that was required to restore order. Otherwise, the development installation remains relatively stable, though there are display problems in IE6 that do not afflict either Firefox, Opera or even IE8 Beta2.

All in all, these changes will make the next major WordPress release a substantial one, and I have little doubt that the new administration interface will make for many comments. While I must admit that I wasn't too taken with it when I first glimpsed it in the crazyhorse branch, it now seems to be growing on me. The most significant change on the aesthetic front is that there's a lot less whitespace, about which may or may not float your boat. In any event, you can always change the colours like I have to make things more amenable.

Even so, I reckon that WordPress 2.7 will be a major step forward when it comes, one that I might like. Saying that, I reckon that the release date is a good while away for now, and the fact that 2.6.2 is being readied for release is telling in itself. Leaving plenty of time to remove any roughness is never a bad thing, especially so when you see the changes that are being made. Meanwhile, I am certain that most people can wait.