In the last 38 days there have been two urgent security fix releases of WordPress. In the last 3 and a tiny bit months there have been three maintenance releases of WordPress. In the last 4 and a tiny bit months there have been four releases of WordPress.

Other than the fact I’m starting to get pretty worried about the security and stability of the software in general, it’s a pain in the rear to have to keep upgrading. So I’m making it easier for me. WordPress themselves have helped by having a decent system in place for making it easy to get the latest.

I now have the simplest of shell scripts which:

1. Backs up my database.
2. Backs up my WordPress folder.
3. Gets the latest WordPress release.
4. Unpacks that release.
5. Deploys that release live.

Being nice, I’m going to share it with you:

mysqldump --host=localhost --user=wordpress --password=wordpress wordpress > wordpress.sql
tar -zcf wordpress_backup.tgz wordpress_live
wget http://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
cp -r wordpress/* wordpress_live/
rm -r wordpress


Of course this assumes that you have a wordpress database in a localhost MySQL instance with username and password wordpress and that your live wordpress folder is wordpress_live so you can cope with a temporary wordpress folder from the unpack. It also assumes that mysqldump, tar and wget are available in your shell.

Also, I don’t just do this on live. I back up my live, put it on my portable instance and test the new version first. Then I do it on live. Then I update the versions of my plugins.

What an arse. This is why I prefer Geeklog. It’s more secure and doesn’t change at an alarming rate.

Now I can SSH into my server and type ./upgradewordpress.sh when I’m ready then hit http://inanger.com/[secretlocationofadmin]/wp-upgrade.php and finish things off. Job done. I still have a pain in the rear as I have to test the release locally first (./upgradewordpress.sh on local instance of course, after restoring a fresh backup of live into it and adjusting the config to refer to my local instance).

And I think this is less risky than tracking WordPress via SVN on live.

Popularity: 46% [?]

The web is global.

Lots of websites do not cope with this. They do not provide a user setting for the language and deliver their content in that language.

Clearly, this is bad. If you are producing an application, like Multiblog, then you need to make it international. It needs the UI at least (content is a more thorny issue) to work in the users preferred language. Otherwise they will experience friction trying to use the confusing foreign thing.

There are a lot of ways to achieve this. Geeklog and PHPBB3 use arrays to translate content and allow the user to pick things. Drupal uses the GNU GetText system. And there are other approaches.

Choosing the right approach and using it correctly is difficult. I’m currently experimenting with approaches for Multiblog and other projects. I’m currently looking into the very interesting Zend Framework‘s Zend_Translate class. This allows a number of different approaches, including both Array and GetText.

GetText appears to be the recommended choice. There are a number of free tools that can generate your translation files, as the translation files are not human readable. It’s fast and threadsafe. The Zend Framework Manual offers some advice on how to structure your translation files. There are several suggested methods, but, there is no suggestion of how to structure your translation modules.

The question I asked was “What’s the best practice?”, and no-one seems to know, so I guess I need to figure it out for myself from basic principles.

Now, GetText was written to provide internationalisation for the GNU software. Including the core of the Linux OS. Here, the GetText file is (I assume) parsed once at start up and held in memory to translate as things go. Web applications are different. Every page view is essentially a new start up. That GetText translation source is going to be loaded hundreds and thousands of times. Not just once on boot of the web server.

So, if we want to get this right, we need to know what our best bet is. Do we want a monolithic all translations file, or do we want to modularise this file and load it as needed? Does it use the file like a database and seek things out, or does it parse the whole thing every time and process it internally?

I’ve done some simple testing. I produced a basic test catalogue with poEdit and compiled a mo file from it:

msgid ""
msgstr ""
"Project-Id-Version: Test Zend GetTextn"
"POT-Creation-Date: n"
"PO-Revision-Date: 2007-06-21 12:20-0000n"
"Last-Translator: THEMike n"
"Language-Team: n"
"MIME-Version: 1.0n"
"Content-Type: text/plain; charset=utf-8n"
"Content-Transfer-Encoding: 8bitn"
"X-Poedit-Language: Englishn"
"X-Poedit-Country: UNITED KINGDOMn"
"X-Poedit-SourceCharset: utf-8n"

msgid "This is a test."
msgstr "[Translated]This is a test.[/Translated]"

I then wrote a simple test harness PHP file which loads a Zend_Translate using gettext and translates a single line. Before performing a translation, I var_dump the Zend_Translate instance to see what’s in it:

  <?php
  /* Configuration: */
  define('PATH_TO_ENGINE', '/development/engine/');
  define('PATH_TO_LANGUAGE', '/development/language/');/* Put engine on the include path */
$curPHPIncludePath = ini_get( 'include_path' );
if (defined( 'PATH_SEPARATOR')) {
    $separator = PATH_SEPARATOR;
} else {
    // prior to PHP 4.3.0, we have to guess the correct separator ...
    $separator = ';';
    if( strpos( $curPHPIncludePath, $separator ) === false ) {
        $separator = ':';
    }
}
if (ini_set('include_path', PATH_TO_ENGINE . $separator . $curPHPIncludePath) === false){
        die('Buggered');
}
require_once 'Zend/Translate.php';
$t = new Zend_Translate('gettext', PATH_TO_LANGUAGE.'test.en.mo', 'en');
echo('<pre>');var_dump($t);echo("</pre><hr/>n");echo($t->_('This is a test.'));?>

The result of the var_dump being:

object(Zend_Translate)#1 (1) {
  ["_adapter:private"]=>
  object(Zend_Translate_Adapter_Gettext)#2 (6) {
    ["_bigEndian:private"]=>
    bool(false)
    ["_file:private"]=>
    resource(21) of type (stream)
    ["_locale:protected"]=>
    string(2) "en"
    ["_languages:protected"]=>
    array(1) {
      ["en"]=>
      string(2) "en"
    }
    ["_options:protected"]=>
    array(1) {
      ["clear"]=>
      bool(false)
   }
    ["_translate:protected"]=>
    array(1) {
      ["en"]=>
      array(2) {
        [""]=>
        string(339) "Project-Id-Version: Test Zend GetText
POT-Creation-Date:
PO-Revision-Date: 2007-06-21 12:20-0000
Last-Translator: THEMike
Language-Team:
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Poedit-Language: English
X-Poedit-Country: UNITED KINGDOM
X-Poedit-SourceCharset: utf-8
"
        ["This is a test."]=>
        string(40) "[Translated]This is a test.[/Translated]"
      }
    }
  }
}

As you can see, before I’ve even called a translate call, the entire mo translation catalogue has been loaded into memory and parsed internally to form a PHP array. Which is then used for translation.

Clearly, this indicates a very modular translation system. I would want a core.lang.mo file for “common” translations used througout the application and then a controller.lang.mo file for each controller that had that controller’s specific phrases in it which is only loaded by that controller.

However, note that the translation is done to a PHP array. Essentially, it seems the gettext translator is really a front-end loader of the array translator. So why not use the array translator?

The only downside I can see is that it’s harder to get non-programmers to generate valid PHP arrays when supplying your translation. Other than that, anything that the PHP extension does to optimise compilation and processing of PHP code will kick in and give you a significantly improved performance. Put extra things on top of that like the Zend Optimisers and so forth, and you have a compelling reason to use highly modular array based translation.

The problem then remains getting valid PHP array files back from your translators, and frankly, that can be solved by writing a simple front end for your translators so they have a GUI to use.

Popularity: 35% [?]

As I noted in my last post, adverts put people off. As does paying for a service. Jeff Atwood points out that registering for a service also puts people off.

If your application requires users to log in, don’t underestimate the impact of the login barrier you’re presenting to users. Consider utilizing anonymous, cookie-based accounts to give users a complete experience that more closely resembles the experience that named users get. By removing the login barrier and blurring the line between anonymous users and named users, you’re likely to gain a lot more of the latter.

Just asking users to login or register scares them away. And he’s right. When I’m looking at new sites online, I don’t want to sign up to find out if I want to sign up. I want to poke around before I create yet another registration, yet another version of my information. Jeff’s post was very timely, I need to take this into account when building Multiblog.

The barrier to entry needs to be so low anyone can get over it. Or no-one will.

However, given it’s nature this is going to be difficult with Multiblog. I guess it’s possible to create accounts tied to an anonymous cookie and allow them to create blog accounts on that account. But it’s hardly secure. What I need to do is allow anonymous users to wander round everything, toy with configuring accounts, even draft and hit post on entries. Then I’m afraid I’m going to have to stop them and make them sign up. But, this has to be painless.

How do I do this? There are numerous options I could take. One idea is to prompt for an OpenID, the idea behind OpenID is that it’s an Open system for authentication, everyone should support OpenID and then you can allow people to post behind an identity on any site without signing up.

I think that’s great for many applications, such as posting comments on blogs (like this one), but it doesn’t work for services like Multiblog. Even the OpenID site says so:

This is not a trust system. Trust requires identity first.

There has even been spam originating from OpenID sources. So we need something else.

I’m going to have to go with an infrequently used option. I’m going to prompt for an email address. That’s it. This isn’t a site with profiles, so there is no need for usernames or anything else. When you first start using Multiblog I just need a globally unique way of referencing people. And that’s their email address. Couple that with a random password and then you have a full sign-up and authentication system. On entry of the email I’ll send an activation password. On logging in with that password, I’ll set everything up and have the user back at the “are you sure you want to post this entry?” stage. Job done.

As frictionless as it is, it’s a threat. This is predicated on at least one free post to all users. Which is an exploitable hole. People could buy a domain and have an infinite number of email addresses. So, I’ll have to make blog accounts (the accounts Multiblog posts to) be unique, monitor sign-ups (not expecting high volume) and take appropriate other anti-spam/abuse techniques.

But basically, I think it’s a good approach. It will allow users to sign up in seconds and to explore 95% of the application without an account. I hope Jeff likes it more than an vanilla textarea control.

Popularity: 41% [?]

For web based businesses, being able to accurately report the number of unique visitors to your site and the amount of time they spend on your site is essential you need to be armed with this information and the evidence to back it up in order to attract good rates from advertisers.

Back in the old days, you’d just parse your weblogs and count “hits”, every access was a hit, no matter what it was. That was fine until pages linked in Javascript, CSS, Images etc. Then we had to move to “Page Views”. We just looked at the specific “root” file for a page, and discounted the other objects that were loaded as a result.

Of course, then that doesn’t allow for pages like the request-o-meter on snakenet, which auto-refreshes to show people when they can next request. Does this really count as another page view? Not to advertisers mostly. Advertisers don’t want to see a buy ads on a site with 10,000 page views per hour, if that page view count comes from 2 users.

And so, sites and advertisers started to track with cookies, but that’s no good any more:

BBC NEWS | Technology | Web counting tools ‘need change’:

The way web audiences are measured could be ripe for an overhaul, according to two reports out this week….

In comScore’s study, an analysis of 400,000 home PCs in the US found that a hardcore minority of web users are clearing their cookies from their computers on a regular basis.

This causes servers to deposit new cookies which in turn could lead to an over-estimate of unique users to a particular website.

It found that 7% of computers accounted for 35% of all cookies, which extrapolated could mean the size of a site’s audience is being overstated by as much as 150%, said comScore.

Justly, many users don’t like cookies. And these are the most web literate users. It’s an invasion of your privacy they argue. People trying to profile you and track your habits. So they can better target their advertising to the right sites and the right people.

Perhaps unsurprisingly, comScore offers a very different approach to audience measurement – using the panel-based system favoured by the TV and radio industries which relies on using a representative sample of net users to gauge behaviour.

This works for TV, because TV is pretty limited. It takes a big chunk of capital to set up a TV channel, to make a TV show, to get someone to air it. It’s free to set up a web site. And thus, there are a lot of them. A lot of competition, lots of sudden start-ups. Things are niche. Take social networking, there’s MySpace, Facebook, LiveJournal, LinkedIn. Loads of them. People gravitate towards different ones on all sorts of random basis.

You can’t generalise traffic to one of those sites. There are new services getting tons of traffic from markets you can’t generalise. There are massively trafficked sites I’ve not heard of.

Perhaps the complexity is just in finding out how to come up with sensible representative survey groups. With the social networking it’s a bit easier. People who’ve been online a long time are more likely to use LiveJournal, which isn’t a true social networking site, but has aspects of it and has been around a long time. School kids and students will gravitate to facebook. Professionals to LinkedIn. That’s an easy one. But to music sites? You can’t judge the internet radio sites people visit that easily.

I know of several sites with no reason to choose between them that can be generalised. It’s down to the community. Some people fit in better elsewhere. So how are you going to be able to calculate their sites on that basis?

But, I guess this approach isn’t really about figuring out the traffic for every site, but just for the big sites, that everyone knows about.

So, they’re playing round with ways to get an accurate idea to estimate the number of unique people visiting bigger sites so they can sell advertising.

People expect the web to be free. They don’t want to pay to use facebook. Facebook need to make money. Even if it’s a cool idea that someone sets up because they think that would be a cool service running a big site is not free. The internet is only free to the consumer. The middle-men, the people who run the sites have to pay money to the bandwidth people, the power people. They don’t get that free. So you have to find a way to get money that doesn’t directly take it out of the pockets of your users.

And that’s advertising.

And your users hate it.

There are many things around that exist purely to take the advertising out of the web. I use AdBlock Plus in firefox to strip the vast majority of adverts out of every site I visit. I combine this with Greasemonkey and some user scripts to take other adverts out of sites I use a lot. And so do a lot of other people. Plus people use tools to block cookies that are used to track their use of sites and their browsing habits. Some people just purge all, but there are tools more like AdBlock Plus that do extend and enhance Firefox’s user permissions to blacklist and whitelist cookie providers. Spybot, Adaware and other tools rip out these tracking cookies.

So on the one hand, you’ve got the problem accurately reporting your usage and getting that user base up to get revenue from advertisers. On the other hand you have a hard-core minority of web users trying to eliminate that revenue stream because they don’t want your crappy invasive adverts and they don’t want to be profiled and tracked.

You have to find another revenue stream for your online business. Adverts alienate users and dilute your brand image. But people don’t want to pay for things. I guess that’s a bit of a problem for me isn’t it? On the one hand, I won’t attract users and keep users if I make Multiblog a pay service. I will have problems attracting advertisers to start with and producing evidence of my true user base to get them later on. And if I do get adverts, many of my users will be blocking adverts or alienated by them. Blogging to multiple-blogs in one hit is a very web literate thing to want to do. My core demographic is the advert avoiders.

So what do I do?

The answer isn’t great. I’m not going to waste my time building an advertising funded service. My users will ad-block. I’m not going to get anywhere charging for everything. I have to follow the web equivalent of the shareware model. I have to start free, then I have to introduce charges for advanced features later.

It’s essential that I’ve identified this model early, because I’m going to have to design user accounts and features around the fact that some features or sub-features will one day switch to paid user only, and I may even have tiers of paid users. Critical thing. if you miss that at the start, then you’re really not going to manage to deliver the payment extensions later on.

Popularity: 23% [?]

Ok, so we’ve briefly discussed the importance of figuring out what your software should do, so what will my software do? What I need to do is sit down and write out what the software will do, and review that from an experienced developer stand point and figure out where I’ve not been precise enough. Let’s start with this (based on what MultiBlog the desktop app can do):

MultiBlog will allow users to register an account. Within that account they will be able to configure multiple remote blog accounts. They will then be able to write blog entries and cross post this to multiple blogs within multiple blog accounts.

That’s great. But that’s very high level, clearly that needs some expansion. What details are needed to register an account? What makes up a remote blog account? How do they write entries? How do they cross post the entry? It will serve as a statement of intent, but it’s light years away from a specification. I’m going to take one aspect of this and expand it as a worked example, that will be the writing of entries.

MultiBlog will allow a logged in user to write blog entries within a browser-based WYSIWG editor with the option to edit the raw mark-up of the entry. The software will support drafting of entries.

An initial screen will list all current, unposted draft entries the user has been composing. The user will be able to select a draft to continue editing, or to create a new draft. Upon selecting one of these options, the user will be presented with an editor screen.

The editor screen will contain controls to capture:

• Post title
• Post body
• Post tags
• Current Mood
• Current Music
• Post date and time

The editor will autosave drafts every 5 minutes, and allow for manual saving of drafts.

In addition, in a future release, the editor screen will integrate to external web services to insert content, for example, product information for Amazon content or Flickr images. This will allow easy blogging about films, books and photos taken etc. However, this will not be implemented for MultiBlog Online 1.0.

This is better. There is much more detail. However, there are still blank areas, what exactly will the WYSIWG editor do? What are it’s features? This is something I won’t expand as I’m just going to go with one of the leading open source, browser based WYSIWYG editors for HTML, after evaluating them against the other requirements in this area. One of these is of particular interest for several reasons. The final paragraph of my requirements for the Blog Entry Editor is a future requirement to allow easy insertion of data from Amazon, Flickr or other web services. Whatever editor I pick up is going to have to be easy to extend/adapt so I can use widgets to pull that information across.

This is an isolated packet of requirements. How does this interact with the rest of MultiBlog? What else will the rest of the application do? Obviously, I need a full MultiBlog requirements specification. I don’t intend to post that as a Blog entry. I will produce a document, which I will publish, that covers and elaborates everything I intend the application to do.

That will then form the basis of my high-level software design and architecture.

Popularity: 12% [?]

Typically for me, I’ve got sidetracked for the last few articles with technical stuff. What platform? Where to develop? Get the development environment set up. All that kind of stuff. Of course, that just hand waves away the fundamentally most important aspect of writing software:

Clearly identifying what you are going to produce, what it is going to do and how it is going to do it.

That is where both bespoke and product development most typically comes unstuck. Not agreeing up-front what you’re going to write and what it’s going to do. Now, for bespoke work, where you’re creating a custom solution tailored to a customers exacting requirements, that’s a massive issue. There are many problems en-route. Such as simple mis-understandings and, even worse, the things the customer thinks go without saying.

These are the things that cause scope creep and late delivery. Much bespoke work involves fixed price and/or timescales, so this is a major issue.

Of course, in the product world it’s not such a serious issue as much of the time. Obviously, there are issues making sure that your software does something that customers want, and does it in a way that will make them want to pay for it. Also, there are issues with making that first release in a timely fashion to start getting a revenue stream. Or some users and feedback etc.

But for product software, the biggest failing at this requirements capture phase is short-termism. You might decide that the software is going to do so and so. All very well and good, and that might lead down a certain path. That path might turn out to be a cal-de-sac when you realise later on that it was obvious that so and so was right, but, implementing it in such a way means you can’t do a natural extension of so and so that could have been an obvious thing to want to do later right at the start.

So, before I get any more carried away with the platform and the development environment, I think it’s time to sit down and figure out what the basic features of Multiblog are, and where the road map will take it in the future.

Popularity: 11% [?]

I’ve already posted an article about choosing a platform for your development. I missed a very important point, when choosing a language to develop in you also buy into the platform available to you, in this context, this means the third party libraries and supporting frameworks available to you. And as Jeff Atwood points out:

When you choose a language, like it or not, you’ve chosen a platform. And as Steve so patiently and calmly explained to all the Lisp enthusiasts, the platform around the language, more than the language itself, sets the tone for your development experience. The availability of common, popular libraries and the maturity of the development environment end up trumping any particular significance the language holds.

This was something I was planning to move on to talk about in more detail later. When you pick a language, you do need to look around at the choices of libraries available to you. PHP is lucky. It’s mature. There are a lot of libraries out there.

But, you must be very careful when confronted by such choice. Take a look at the options available for templating. Pear (a major source of libraries) have several implementations. There’s Smarty, and numerous other “just templating” libraries. The new Zend Framework also has a templating implementation.

There is a lot to choose from. Making the choice to go Pear::Flexy because that fits in with your use of Pear::DB, or to make use of the entire Zend Framework might be completely the wrong thing to do. You might want to create your own lightweight abstraction. Or go for something like SimpleT.

Picking a language with a small platform footprint can actually be better than picking a language with a large platform footprint.

But I’ll be talking about the costs associated with blindly using a library from the “PHP platform” for every project. When all you have is a hammer, everything looks like a nail. If you only have one type of hammer, that’s not worse than having a whole basket of different hammers.

Popularity: 19% [?]

So, today I’ve finally finished installing and configuring a WordPress installation for running InAnger.com. This may seem a fairly odd decision to certain people who know certain things. The main reason it’s odd is that I am a member of the core development team for the Geeklog system. WordPress is a PHP application using a MySQL database for running a Blog. So is Geeklog. So then, if I am a Geeklog developer, why have I chosen a competing system to run my new site? Interesting question, and one I shall discuss in length.

Firstly, I consider it important to investigate the innovation going on in competing products. I take a similar approach with software languages and tools. Something else is out there and has some buzz, so I play with it to find out why it has that buzz and what that new thing can do for me. With software languages and tools this is likely to be a switch to develop with a new language, even if it’s just for certain tasks that that language is particularly handy for. With a piece of software like a Media Player it’s a possible full switch to that product if it’s better.

With a CMS however, it’s more likely to be that I experiment with it and frankly steal the neat features and implement them in Geeklog. So, I’ve often seen posts “I tried geeklog, but now I’ve switched to wordpress and like it more”. Time to find out why and see if I can address those issues.

That’s not all though. I’m a terrible one for tinkering. I can’t find-out that some piece of software I use is customisable or configurable without becoming dissatisfied with what it can do, and try and customise it. As a Geeklog core developer, if I was using Geeklog, I’d get constantly side-tracked customising things and re-writing things. With WordPress being a stable application with an active development community which I am not a member of I’m more likely to be able to keep my hands off, and concentrate on using the application.

So, WordPress vs Geeklog, what’s the difference?

WordPress

WordPress is a highly popular Open Source blogging tool. It’s focussed on “aesthetics, web standards and usability”. It has a simple elegant usable interface.

Geeklog

Geeklog is also an Open Source blogging tool. It’s focussed on security. Out of the box it provides a full portal implementation as well as the core blogging features.

Installation

Installation of both is reasonably simple. In both cases you download a tarball archive of the latest version. In both cases you extract this and create an empty MySQL database to install into (in Geeklog’s case, you may use a Microsoft SQL Server database too). In both cases you set up database connection information in a configuration file. In the case of Geeklog all your site’s basic configuration is also in the configuration file and may be edited at the same time, plus, there is the additional need to configure file paths in two files (the configuration file and lib-common.php, the core functionality file). In WordPress’ case you have to copy the config file to a new name.

Then you navigate to the install script location for either system and execute the install process. Voila, two complete blog package installs. You’re then left to configure up your system to meet your needs.

Publishing Blog Entries

The main thing you’re going to be concerned with day to day with your blog engine is writing, editing, posting and maintaining entries.

Both Geeklog and WordPress have similar options for your posts. Advanced HTML editors (though I feel the use of FCKEditor gives Geeklog the edge here), control over the way the link is generated (post slug in WordPress and Story ID in Geeklog, they form part of the URL for Search Engine Friendly URLs), control over user feedback permitted (comments etc), the ability to place an article into a category (and here WordPress wins with multiple category support), image upload etc.
So where are the differences? Well, WordPress allows Custom Fields on stories. I have yet to fully explore these, but they allow plugins to provide rich functionality easily to stories. Geeklog has Autotags which replace this functionality.

Geeklog has a strong security model, you can have many user groups and can set permissions for stories and topics in a very controlled fashion. WordPress lacks any of this subtle security, it’s focussed on public blogging.

Geeklog also has the ability to auto-archive stories after a certain amount of time.

Really at the story level, the only differentiation seems to be that Geeklog has an excellent security system and also allows users to contribute stories (via moderation if necessary) to the site.

Both have strong API’s for plugins to extend things, however, I think extending the posting engine in WordPress is a lot easier than in Geeklog.

So what about at the display end of stories? Both support comments, trackbacks and pingbacks with anti-spam measures and control over who can comment etc. Both have ways the display of a story can be tailored to suit the webmaster’s needs. It’s pretty even , with minor differences.

That leaves the user experience. Geeklog is (out of the box) a richer and more complex application than WordPress. It does more. And thus, it’s a bit harder to learn your way around at first. That doesn’t mean WordPress is a saint. I think I found my way round it reasonably quickly, from scratch, but, it could have been a clearer process. That said, WordPress’ documentation which is linked at the foot of every admin screen is rich and detailed and vastly superior to the limited (by comparison) documentation for Geeklog.

Other Features

WordPress is a blogging engine. That’s about it. It gives you static pages and links. But out of the box, that’s pretty much your lot. Geeklog is more of a portal, it comes with a calendar (for events, not to be confused with a monthly post view calendar which both systems have), polls system, links directory and static pages. Geeklog has a modular system for blocks on both the left and right hand side of the page, which allows the administrator to configure up static text, import RSS feeds, or use various built in functions to produce various types of dynamic boxes. To do this in WordPress, you must edit the theme to include the HTML and/or function calls.

Themeing/Skinning

Both Geeklog and WordPress come with perfectly nice default themes. But you don’t want your site to look like Just Another Geeklog/Wordpress Site. You want it to look individual and have an identity of it’s own. Both systems therefore offer a theming system to change the look and feel of your site.

WordPress has a small number of PHP files that make up the base theme. These contain PHP function calls to output data and even loop structures to iterate over posts. This is quite confusing for non-programmers to get to grips with, but there is a lot of documentation, many community developed themes and lots of community support for this work. Plus, there aren’t that many files to edit.

Geeklog has many THTML files that make up the base theme. These contain HTML and place holders for dynamic data (in curly braces, for example {story_title}). It takes a fair bit of work to get your head around how these files are used to actually construct the layout of your site, and the documentation isn’t fantastic on these. But, I feel the content of each template is less confusing.

Extending

Both systems support plugins to provide the functionality you want. Some of Geeklog’s out of the box functionality is from core plugins (calendar, links, polls) and can be uninstalled if you do not like it.

The Geeklog API consists of a lot of functions you can define that get called at appropriate points. The WordPress API consists of a lot of places you can tell WordPress that your plugin wants a function call inserting into the chain. Both API’s seem to be pretty mature and well thought out and provide a really great way of extending the application.

If anything, I would suggest the opinion that Geeklog’s API is more mature and powerful, implementations include various image galleries (including integrations of popular Open Source gallery applications like Gallery), forums, file repositories and even further anti-spam measures. WordPress however seems to have many more plugins available, more focussed on adding features to the story engine.

Summary

So, to just recap. Geeklog is a bigger system. It does a lot more. But, for people who just want to set up a simple blog, that might be too much, too daunting, too confusing. They’re targeted at different audiences. Geeklog is for running sites that are more than just a blog. WordPress is for sites that are just a blog. The reason people are switching, is because all that power and all those features get in the way of having a plain, simple blog that everyone can read.

Popularity: 100% [?]