WordPress and SMF: Open Source Software

[#1]

As some people will realise (and others may not) - the Community Site is built using a collection of Open Source Software - specifically WordPress for the blogging aspect and SimpleMachines Forum for the forum aspect. There's also a collection of Backend Plugins which we make use of which are Open Source, and some which aren't - although these are the few as it's mainly ones we've written which won't be of any use to other people. In this blog post I am going to be taking a look at some of the ways in which the two pieces of software we use to power the site differ and some of the challenges this has caused us. Be warned: some bits of this post may be 'geeky' and technical and include code examples. Sorry! Firstly, I should state that I am not trying to annoy or belittle the people that have written either Wordpress or SMF - I think they are both very good at what they do, but as a developer (and as a webmaster in a previous incarnation) I find that they don't always make life easy for me. I'm going to look at two key areas in this blog - Extending the Software and Implementing Custom designs.

Extending the Software

Over the time the site has been running, we've been making enhancements to the site in both the blog and in the forums. For example, we've added the plugin written for us by Mike Whitehead (hover over 'EOD' and you'll see an example of it) and various other examples to the blogs. We haven't really extended the forums as much, and there's a key reason for this. To extend Wordpress it is quite straight forward, either find a plugin or write a plugin and upload it to 'wp-content/plugins/' on your server. It then appears in your Admin panel and you are able to activate it and the functionality it provides is there immediately. If necessary, you can also remove the functionality quite easily. With SMF, on the other hand, the process of extending it is vastly different. You can still download modifications to the software but to install these involves the system going through and making changes to the actual source code files on your server to provide the new functionality. Although, to be fair to SMF, it does offer some integration points, there are very few of these, and they all appear to be in places where I haven't needed to do anything. (Although, to be fair, in my previous days in the UserGroup I did actually make use of them) This presents two issues (although they are in related) - what happens when it becomes time to update the Plugin or the main product. To upgrade a Wordpress plugin, it's simply a case of disabling the existing plugin, backing it up and overwriting it with the new one and activating it again. To upgrade an SMF plugin, you are best advised to uninstall the existing version and then install the new version. To upgrade the core package, with Wordpress you just need to ensure the plugins work with the new version and disable them. Then you upload the new source code and upgrade the database if required and then re-enable the plugins. To upgrade SMF, you may need to uninstall all your changes to get back to the core code and then upgrade as your modifications may have touched the file(s) being updated. This means that if you have to react to an urgent security update, then the time for this is increased as you try and deal with all your plugins - whereas with Wordpress it's just a case of checking compatibility. Wordpress manages this because it provides you with the ability to 'hook in' to various functions which are called on page generation so that you can then call your own specific code to ensure that your own functions are called. This means you can very easily change something the behaviour of something. However, SMF does not provide this ability.

Implementing Custom Designs

(or otherwise known as Templating). As we've decided to integrate two pieces of software together on the one site, we've worked to ensure that there is a consistent look and feel across both sites so that it's a seamless user experience. This means that we want both applications to have the same look and feel. Initially, we thought 'easy - just create a mockup, convert it to HTML and the rest will be simple'. Alas, it was not to be. Given that both applications are web-based, we obviously would need the same HTML for both for the common parts of the layout (Header, Footer etc.) - which thanks to the designers was produced quite easily. Then came the fun bit... tackling the integration with the applications. Both packages have a 'concept' of Templating, although neither really does it well (or at least, well enough to keep me happy ;)). While there are packages like Smarty which provide a templating language that you can use consistently across applications, both packages make use of their own custom templates. Again, we became unstuck. Although Wordpress makes it quite simple to do templating (relatively) there are bits of code that you can use to generate certain parts of your blog page which have hardcoded HTML elements built in. This of course means that if you want to use them, you have to hope that your chosen template matches it and your styles are correct. Changing these without hacking on the original distributed code is difficult unless the function provides either a method of returning the relevant data in a different format (eg. array) or provides a hook where you can 'post-process' the data before it ends up on your page. It also allows you to mix PHP in with your template meaning that it's quite easy for a non-PHP coder to break. For example:

<?php while (have_posts()) : the_post(); ?> 
    <div class="post" id="post-<?php the_ID(); ?>"> 
    ... 
    </div> 
<?php endwhile; ?>

The above example is taken from the index page of the default Wordpress theme, demonstrating the point about code being mixed in with the templates. Wordpress also gives you the ability to style different parts differently - so the index page can have one layout, then the pages viewing a specific post can have a different layout - all by just creating a new file. SMF forums however, have a completely different templating system. Again, it has mixed PHP and HTML together in the one file - but different parts of the page are handled by different template files and different functions within the template file. While you may expect the HTML header to be in file called (for example) header.tpl, it's actually a function in index.template.php called template_html_above() which also has 6 global variables containing some data that it might make use of - for example, the URL to the page you are viewing, the userdata of the logged in user and the settings for the specific forum you are visiting. Changing this means changing some PHP - and even for PHP developers it's still possible to get confused and break things. Believe me... I know as I have been there and done it on a number of occasions recently. Now, admittedly, there would still be differences in the templates if the packages did make use of the same templating system - they are fundamentally different things, but at least it would make it easier for people that are trying to build integrated websites if people adopted a 'standard' templating system. So, what can be done to improve things? Putting on my 'Webmaster' hat from many (well, OK - 2-3) years ago, I would prefer things to have a consistent templating system. The best one that I know of at the moment is Smarty, so if I want to reskin my Blog, Forum or CMS then I only have to learn one system. Of course, there'll be bits that are different in the system (for example the variable to get the username of the logged in user) but at least I'll know that it's likely to be displayed in a header as:

<h1>Hello {$user.name}</h1>

and not

<h1>Hello <?php echo $user->getLoggedInUsername(); ?></h1>

I'd also hope that if authors are hoping that the Community will hope to build on their work, as I would hope many will, as I've yet to find a software package on the web that does exactly what I want without some additional work, then they will make it easy. This means providing actions I can hook in to and change the behaviour if I so desire.