Now that it’s been a while since the blog started being powered by WordPress, I figured it was the time to do a comparison of the two systems.
I guess the short of it is that if you don’t need plugins that much… MT would be the better system. It’s highly configurable on it’s stock setting. In other words, you probably can do most content “filtering” with a base install of MT, while you’ll be needing a bunch of plugins on WP to accomplish the same things.
Having said that though, if you need lots of “special” functionality, WordPress can be a practical choice because of the sheer activity of the plugin development community.
For the next post, I’ll be evangelizing a certain plugin-architecture that I think may benefit a lot of WP plugin developers. I’ll also drop some code in to extend and make it more useful. In the meantime, I’ll go through my general opinions of the new system after the switch.
The Good
Speed
As I’ve mentioned before, I use Ecto to blog. I love it so much that I’ve purchased a license for it. I even crafted custom CSS preview templates for it to match my blog… so that when I’m drafting my stuff, I have a general idea of how the final thing would look like when posted on the blog.
Anways, with MovableType, I was setup using a static page-generation system (which looked like a good idea at the time). As such it takes quite a while to publish or revise a post as it waits for a confirmation if all processes involved (page generation, index rebuilds, etc.) have finished – this usually takes about half a minute.
With WP being all php, the posting/revisions, etc. all take about 3 seconds.
Footnotes
The footnotes plugin for WordPress is much more elegant than in MovableType. I used to make footnotes this way:
... a sentence#[fn1]
[fn1]: this is a footnote.Now I simply have to type in (without the spaces between the parentheses):
... a sentence ( (this is a footnote) )PHP driven
MovableType was mostly done in perl. While, I’m not going to claim one language is better than the other, I personally prefer WordPress being a php driven system because I know php. In fact, during the migration, I was able to hack a bunch of WordPress plugins to suit my specific needs easily… which made the transition easier (and much faster) as a whole.
Plug-ins
Just like I said earlier, WP has a very active development community and plugins are popping up left and right. You’ll notice that a plugin that wasn’t included in my old engine is the Twitter plugin, which displays my recent tweets right in the blog’s main page. I’ll actually have another post discussing some hacks I did which may be useful to other WordPress users.
The Bad
Low level design concepts
Like I said, MT had a superior way of “approaching” the way data was being processed. The move to WP frustrated me in a sense that a lot of the plugins are self-contained. It’s hard to explain, but I’ll try in the form of an example.
WP has what they call The Loop, which is basically the equivalent of the <MTEntries> tag. What happens here is that any other subcommands that are executed within that tag/loop is specific to the entries being pulled. Now the thing with MT, is the filtering plugins usually act like their own The Loops. Because of that, and because the MT developers approach things that certain way, it’s commonplace to be able to use plugins within plugins with minimal incindent.
To demonstrate: recall the archiving section on my old home page. The layout from that was done by using a bunch of plugins together.
The way I did it was something like do a “the loop” of the entries of a given year… then do another “the loop” through all those entries, this time grouping the months… then within that [monthly] loop, do another “the loop” of the entries to take the numbers of entries. etc. etc. It was basically a plugin made out of other plugins… but the difference is I didn’t have to modify any of the existing plugins to accomplish that output.
It’s damn near impossible to do that without making your own custom plugin script to format stuff the way you want to. So now you see the watered down archiving system I have in the main page – which is basically just a dropdown list 🙁
Post revisions
Talk about database clutter! All you WordPress users who have just been simply posting and never bothered looking at the actual database… now’s the time to check it out. See how much useless crap is generated just by saving a minor revision.
Luckily, WordPress has provided a killswitch for it, but it’s not an “option” you can toggle on and off. According to their stats, out of 200k installations, only 30-50 actually take issue of having such a useless feature. Hence they decided to do the whole: you can kill it if you really wanted to, but you’ll have to know what you’re doing approach. Here it is:
open wp-config.php and add the following code above or below the lone define clause:
define('WP_POST_REVISIONS', false);Problem solved!
Primary Categories
This is just stupid. I’m not quite certain what was going on the developers heads to exclude a simple way of setting a primary category. While there are plugins that can accomplish this, you’d have to use the web-interface to set everything.
Luckily I found out that through Ecto, if you post using one category initially, it sets that as a primary category. Given how quick it is to revise a post, then I just make an immediate edit and include the other categories.
Still, it’s quite baffling why this simple thing wouldn’t be included as a core feature… again, I attribute this to poor lower level design concepts.
The Ugly
Custom Permalinks require post slug or id to work properly
All my archive permalinks used to be stored in the format: http://nargalzius.com/blog/archives/YYYY/MM/YYYY_MM_DD_HHMM.php
Sure, not it’s hardly the most efficient folder/naming scheme. But it worked and it was unique enough (since it was impossible for me to post more than one post in a given minute. Simply put, that sort of URL is already unique enough to identify a post. Unfortunately this breaks with WordPress. I have to have a post ID or a title slug appended at the end for it to work properly.
This sucks because now ALL my old permalinks don’t work anymore even if they legitimately are unique enough not to confuse any rewrite rules setup by any system. As such, part of my transition phase is constantly adding redirects in my .htaccess file…
I’ve installed a plugin that gives me an RSS feeds of all 404 (file not found) errors. I strip out all the errors made by spiders and bots and take the “normal ones” which are probably made by normal surfers… and add them to the list. So the next time that particular url is entered, it will redirect to the new permalink… until the time when all search engine caches are updated with the new links (which is probably a long time from now.