Upgrading from OpenMediaVault 1.x to OpenMediaVault 2.x

Having an older PC about, I decided to install OpenMediaVault on there earlier in the year after adding in a 6 TB hard drive for storage, a Gigabit network card to speed up backups and a new BeQuiet! power supply to make it quieter. It has been working smoothly since then and the release of OpenMediaVault 2.x had me wondering how to upgrade to it.

Usefully, I enabled an SSH service for remote logins and set up an account on there for anything that I needed to do. This includes upgrades, taking backups of what is on my NAS drives and even shutting down the machine when I am done with what I need to do on there.

Using an SSH session, the first step was to switch to the administrator account and issue the following command to ensure that my OpenMediaVault 1.x installation was as up to date as it could be:

omv-update

Once that had completed what it needed to do, the next step was to do the upgrade itself with the following command:

omv-release-upgrade

With that complete, it was time to reboot the system and I fired up the web administration interface and spotted a kernel update that I applied. Again the system was restarted and further updates were noticed and these were applied, again through the web interface. The whole thing remains based on Debian 7.x but I am not complaining since it quietly does exactly what I need of it.

Tinkering with Textpattern

Textpattern 5 may be on the way but that isn’t to say that work on the 4.x branch is completely stopped though it is less of a priority at the moment. After all, version 4.40 was slipped out not so long ago as a security release, a discovery that I made while giving a section of my outdoors website a spring refresh. During that activity, the TinyMCE plugin started to grate with its issuing of error messages in the form of dialogue boxes needing user input to get rid of them every time an article was opened or saved. Because of that nuisance, the guilty hak_tinymce plugin was ejected with joh_admin_ckeditor replacing it and bringing CKEditor into use for editing my Textpattern articles. It is working well though the narrow editing area is causing the editor toolbars to take up too much vertical space but you can resize the editor to solve this though it would be better if it could be made to remember those size settings.

Another find was atb_editarea, a plugin that colour codes (X)HTML, PHP and CSS by augmenting the standard text editing for pages and stylesheets in the Presentation part of the administration interface. If I had this at the start of my redesign, it would have made doing the needful that bit more user-friendly than the basic editing facilities that Textpattern offers by default. Of course, the tinkering never stops so there’s no such thing as finding something too late in the day for it to be useful.

Textpattern may not be getting the attention that some of its competitors are getting but it isn’t being neglected either; its users and developer community see to that. Saying that, it needs to get better at announcing new versions of the CMS so they don’t slip by the likes of me who isn’t looking all the time. With a major change of version number involved, curiosity is aroused as what is coming next. So far, Textpattern appears to be taking an evolutionary course and there’s a lot to be said for such an approach.

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 but that was my choice, as strange as it will sound to some. However, 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 got to replacing the old FCKEditor plugin with a newer CKEditor one and that has gained me post or page autosaving. The more cosmetic word counting feature is not active until a draft is manually saved but I can live with that. Other than that, the interface remains familiar with all (X)HTML tags on show in the source code view without any being hidden away from view like in WordPress’ implementation of TinyMCE. That isn’t to see that WordPress is doing something wrong but just that there are alternative way 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 in 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 bigger 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 but 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 but I’ll be doing some testing ahead of time to be sure that is the case.

Take a great leap forward, then consolidate…

While I have been a user of WordPress since late 2006, I only began to start keeping tabs on its development following my hearing news of dramatic changes coming in what became 2.5. Since a pattern developing with bigger changes coming in 2.5 and 2.7 while both 2.6 and 2.8 didn’t add too much in the way of upheaval but rather evolved what was already there. With 2.8, theme and widget management got the once over while there were plenty of other tweaks that polished a well received forbear. The differences between 2.7 and 2.8 are discernible without breaking anything that shouldn’t be broken. In short, I rather like the result.

The reaction to 2.5 was mixed, to say the least, and that in part led to the dramatic changes in 2.7, especially with regard to the administration interface. I admit to having had doubts about these when I first saw them development and there was so much chopping and changing during development that stepping back until things settled down became a necessity. Even adding a ticket to the TRAC was problematical unless you had sight of what was happening behind the scenes because it became too easy to add an invalid ticket.

With the release of 2.8 into the wild, 2.9 is now on the horizon and I am inclined to suspect that we might see bigger changes again. For one thing, there was that interface poll a little while ago and who knows what impact that may have on what comes next. The structure of the administration screens may not alter that much but that still leaves changes to colours and icons with the aim of separating navigation from what else is on there, something that doesn’t trouble me at all. In fact, I don’t see very much wrong with how how things are right now and wonder if there’s any point in making too many changes at all. The forecasted incorporation of WPMU functionality is a bigger change that would mean the end of WordPress MU as a separate entity and would concern me more with the amount of under the bonnet re-engineering that would be needed. Add Google Summer of Code projects to this mix and 2.9 looks as if it could be a step change in the spirit of 2.5 and 2.7, if not in feel. Summer 2009 could be very interesting for WordPress and I only hope that it continues to work for me in the way that it does as we move from version to version.

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. Some may even have put the thing to those kinds of uses but I am of the opinion that it has a way to go yet 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. That mix of different platforms might seem odd in architectural terms but 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. In hindsight, I might have been trying to get Drupal to perform a role for which it was never meant so I am not holding its non-fulfillment of my requirements against it. Drupal may have changed since I last looked at it but 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, Textpattern might feel less polished when you start to compare it with alternatives like WordPress or Drupal but 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 remember correctly, Textpattern’s default configuration is that of a blog and 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. My ideas weren’t entirely developed so 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 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 and 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. It may be a hack but it appears to work well in practice. Being able to make a page template work in the way that you require really offers a great amount of flexibility and I have gone with one sidebar rather than two as found in the default set up.

Txp also has 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 sake of maintaining the security and integrity of your installation. I added the navigation facility for my sidebar and breadcrumb links in this manner and back end stuff like Tiny MCE editor and Akismet came as plugins too. There may not be as many of these for Textpattern but the ones that I found were enough to fulfill 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 Textpattern to Textpattern apart from doing a MySQL database copy. Some alternatives to this were suggested but 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 (think blogroll from WordPress). Of these, it is the comment or link facilities that I don’t use and even have turned comments off in the Txp preferences. I use categories to bundle together similar articles for appearance on the same page and am 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 many to whom WordPress might be geared. My reason for saying that is because it is a technical tool and 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 and 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.

There may be omissions from Txp like graphical presentation of visitor statistics in place of the listings that are there now and the administration interface might do with a little polish but it does what I want from it and that makes those other considerations less important. That more cut down feel makes it that little more useful in my view and the fact that I have created A Wanderer’s Miscellany may help to prove the point. You might even care to take a look at it to see what can be done and I am sure that it isn’t even close to exhausting the talents of Textpattern. I can only hope that I have done justice to it in this post.