My Last.fm username is scottyang btw, and no, I haven’t listened to U2′s latest album :)

Yes. Please call all your friends who have a self-hosted WordPress blogs and get them to upgrade to the very latest version.

To see what has been changed from WordPress 2.3.2 to 2.3.3, you can use the following Subversion commands:

$ svn diff --old=http://svn.automattic.com/wordpress/tags/2.3.2 \
           --new=http://svn.automattic.com/wordpress/tags/2.3.3

Which includes the diff of the five files that have been changed. The biggest change came from xmlrpc.php, in change set 6715, where Ryan tries to fix this security issue (yes the ticket was opened in November last year and only managed to get fixed yesterday, 3 months later). Basically, capability checking is done before determining whether the operation is editing a post — if post type is “post”. So any account can edit posts and pages via XML-RPC by faking post type as “page”. For more detail on this exploit, see The Seeker Blog, and it appears to be “going wild” at the moment.

The fix also only comes in 2.3 flavour, whereas the concept of “page” has been there in WordPress since 2.0. That also means, all you 2.0/2.1/2.2 users are still vulnerable. You have to upgrade to the latest stable branch, although not all existing plugins and themes work with 2.3…

I think I am starting to agree with Mark…

There are quite a lot of new features in this new release. Most useful to me must have been message tags, i.e. you press 1 to mark the mail as important, 2 to mark it as work related, etc. It is a feature that has been available on Outlook for ages, and is extremely useful if you receive hundreds of emails a day. We’ll usually just skimp through them, and mark the important one for immediate actions later. Now you can finally do that in Thunderbird!

Go back to clean up my inbox now…

$ cd /var/www/scott.yang.id.au/htdocs
$ svn switch http://svn.automattic.com/wordpress/tags/2.1/
$ curl http://scott.yang.id.au/wp-admin/upgrade.php?step=1 > /dev/null 2>&1

And that’s it! Don’t let the detailed step-through scare you, it is actually quite simple provided that you use Subversion to manage your WordPress installations and you don’t have lots of out-dated plugins.

I just briefly checked the WordPress plugins that I have written, and all of them seem to work fine. Maybe there are more efficient ways to achieve the same thing as WP2.1 has more hooks for developers. Time to investigate on that.

The next release, WordPress 2.2, has also been scheduled to 23^rd of April, 3 months from now. But don’t be scared, my fellow webmasters and system integrators, by the shortened release cycle. WordPress has also committed to have 2.0 product line alive, i.e. maintained and patched when security threats arise, until 2010. Web 3.0 would be out by then I am sure :)

• Vim script enhancements — now you can have List, Dictionary and Funcref inside Vim scripts. One step towards becoming Emacs?
• Spell checking built in — use :set spell to underline the mis-spelt words, and z= to list suggestions. For myself it has to be the most useful feature. No more excuse to misspell words now.
• Omni completion — type Ctrl-X Ctrl-O in insert mode and a popup will appear with suggestions to let you select for completions. Many programming languages are supported.
• Tab pages — everyone loves tabs, and now even Vim has one! You can use GUI tab or just a simple label at top.
• Undo branches — now you can redo the changes that you have previously undone and made further change over it. You can undo/redo by timestamping the changes.
• Internal grep — use :vimgrep <pattern> <files> and it will find the matches. Use :cnext and :cprev to go to the next/previous match.
• Remote file explorer — using the netrw plugin, which supports remote editing using WebDAV, FTP, SCP, SFTP, etc.

… and many more. Just go, download and install it. Type in :help version7 for the comprehensive list of changes.

Like all trades person who has his/her favourite toolbox, Vim has been my “tool of choice” over the last 8 years. It is available on almost all platforms, and is also installed by default on almost all platforms (not talking about some inferior operating system here). It is fast — fires up pretty quickly. It is fast — a few key strokes can get all your mass editing done. It might have a high learning curve, but once you get over it, you just can’t live without it.

I came from a PC/MS-DOS background (from the mid-80′s) and “vi” has never been my cup of tea. I am more familiar with text editors like the ones came with Borland’s Turbo C/Turbo Pascal (based on their text-based TurboVision if I remembered correctly). Editor that only has one “mode”, press shift to select, has a menu bar, etc.

So when I started uni and has to get myself familiar with the un*x operating systems, “vi” is not my obvious choice. I have used NEdit for a while, felt that it wasn’t powerful enough, and then switched to Emacs and XEmacs. I was happy, as it is very configurable (I spent way too much time hacking my lisp), easy enough to use and came with a kitchen sink.

Fast forward to end of 1997. I got a junior developer/apprentice role at Creative Computing, which at that stage runs all their development on a single Pentium server running SCO OpenServer. Everyone has their low-end workstation connected to that server via telnet, and everyone — including sales and support — uses a vanilla “vi” to get their editing done. I don’t have the luxury to use other text editors so I ended up having a crash course on “vi” as well.

It turns out “vi” is actually not bad. At least inside a dodgy terminal (can’t remember what term emu we were using but it was really dodgy) it performs well, and allows me to edit files efficiently. Pretty soon Vim 5 got released with syntax highlighting, and got it “sort-of” working on that old OpenServer…

The rest is history.

I only stayed in Creative Computing for 7 months, as I had to go back to uni to finish my thesis. But this “vim” bug stuck with me ’til today. For the next few jobs I had, regardless whatever environment they have already provided, I feel that I cannot edit effectively without Vim.

There are many “habits” that just stuck with me because of a certain circumstances I was in. I’ll leave that in other entries…

1. Interface looks sleek. Nice shades. No more menu bar (unless you want to be called a classic).
2. Now you can manage IE Add-ons just like how you can manage extensions in Firefox. Except most 3^rd party add-ons are commercial with a price tag.
3. Rendering, as far as I can tell, is very close to IE6. Actually, the better way to say it is, when you look at the rendered result, you can tell that it is Internet Explorer. It might have better CSS support, but I still found exactly the same glitch when rendering certain pages.
4. Tabs, oh tabs! Middle-click to open a link, Ctrl-W to close the tab — just like the others. Now all the modern browsers have tabs. Welcome to the team, IE.
5. RSS/Atom feed support. Nice feed rendering, but it seems to ignore any stylehseet declared in the feed, i.e. FeedBurner’s feeds still show up in IE’s own style. IE7 also lets you subscribe to feeds — just like all the other modern browsers.
6. Toolbar search box. Surprisingly default to Google (hmmm, just like all other browsers). It uses OpenSearch format to define providers, which is nice.
7. Extra security features, i.e. phishing detection. Good stuff. Not much use to me, but I am sure it would save grief of many when it is released.
8. Favourite/bookmark management still sucks. They probably intended to keep them hard to use so users will stick to the preset list of links
9. Memory leaks like crazy. I think the days is numbered where Firefox 1.5 as the memory leak leader. I have to literally close down the browser every hour to keep memory usage sane. I guess that what “beta” is for.

Fortunately due to limited rendering change our web application still works flawlessly on IE7. Now, how do I revert mine back to IE6?

Update: Just killed IE7 again. Closing multiple tags with Developer Toolbar running — hangs. Oh well.

Ajaxterm is a web based terminal. It was totally inspired and works almost exactly like Anyterm except it’s much more easy to install.

It is easy to install (download, untar, run!) and its terminal support looks pretty good to me. Unlike Anyterm, nothing to compile, no external library to install (except Python), no Apache to mess up with (none of my servers are running Apache) and it is far easier to deploy. To hide behind a “proper” HTTP server, just proxy it with appropriate authentication.

It can provide you a shell over HTTP/HTTPS, bypassing draconian firewall rules (like most corporate firewalls). The terminal emulation is actually quite good, and I have no issue running many terminal apps that I frequently used (w3m, vim, mutt, etc).

I am surfing Slashdot in w3m, running inside AjaxTerm inside Firefox 1.5 :)

So far I have two choices — WordPress or TextPattern. I have experiences with both pieces of software, although far more exposure with WP. Since I already have quite a few sites running WP, and only one with TextPattern (and it’s off-line at the moment Update: and it has been converted to WordPress), I said to myself why not give TextPattern another try? Last time I looked at it was 18+ months ago when it was g19. The latest official release is currently at 4.0.3. Maybe things are different now.

So I downloaded the tarball, installed it and had a play. Not completely happy.

The Bad and Ugly from my previous review still stands (somehow my post got pretty good ranking on Google for “textpattern review“), and there are a few new aargh!! about TextPattern after getting myself familiar with WordPress.

The old warts:

• Still no XML-RPC support — Although it appears to be coming. Fortunately XML-RPC support is not that important to me anymore.
• Still no trackback support — Because the dev’s think it is an invitation to the spams. Doesn’t it apply to comments as well? There are third party support however.
• parse() is still here — Can’t do much as it is really the heart of publish.php. It is heavily regular expression based and can be hard on the memory usage (which is what makes WordPress so slow as Texturize runs on every page view).

And these are the new ones…

Theme Support

Or is there theme support in TextPattern at all?? I found WordPress (and Drupal and other CMS) has got it right. To change into a pre-made theme on WordPress, you just need to (1) download the theme file (2) unzipped into wp-content/themes directory (3) activate that them from the admin page. That’s it!

However for TextPattern, so far I have failed to download a theme from TextGarden.org that doesn’t include a readme.html detailing 5-step instructions on copying images, copying CSS, copying pages and forms, etc. Don’t like the new theme and want to switch back? You need to find the old theme file, and follow the 5 step instructions to copy and paste various files. Repeat the process until finding a theme that is satisfactory.

Theme page on Textbook seems to be addressing that. There are quite a few discussion in the forum on the topic of “theme manager” (for example this one). Hopefully this issue will be resolved soon.

I actually feel bad for those who work on TXP themes and contribute to TextGarden. These are great themes and wonderful art work, however I guess they would have received less distribution and less wide-spread usage because TXP themes are just so hard to use.

Database Stored Theme Files

It is closely related to my previous issue. TextPattern stores all presentation data (page, form and stylesheet) inside the database, alongside with your site contents. It might sound neat — just do a mysqldump and you have your entire TextPattern site.

Which is completely not true.

What about other media files, like graphics, pictures and MP3s of your podcast? They don’t store inside the database, and you still have to zip them up using the “traditional method”. There are also images that are referenced by specific themes, and it is really difficult to manage them when the templates are stored inside DB yet others are stored on the file system.

TXP might argue that by putting pages and forms inside the DB, it makes updating the site much easier, as no FTP is required. However, as TXP presents itself as a professional publishing platform, I do not think using FTP and working around file/directory permission is an issue here, moreover

• No one should update a live site. I have made numerous mistakes in WordPress when updating a live site without making sure every section works, so I always tweak my designs on a testing site before applying it live. Having templates in DB with a web-based editing interface really tempts you to edit design live.
• No easy way to synchronise changes between installations. I usually make changes to templates on my test WordPress sites, which is an exact replica to live sites on the file system level. After changes are tested, I just run unison (a 2-way version of rsync) to copy all my changes across. Nice and easy. But it is difficult to implement in TextPattern. Of course I can run mysqldump on txp_page and txp_form, scp it onto live site, then import into the database, and wrap all that into a script. It still does not provide two way synchronisation (in rare cases where I manually modify the live site instead).
• Presentation should really be separated from content. It is interesting to read Natelie’s convert to TextPattern. In her incident where she deleted the database of her WordPress installation — if it was a TextPattern instead, not only all posts and comments are gone, so are the templates, stylesheets and the whole design as they are stored in the database. Also separation of presentation and content makes it easier for designers and content publishers to work together.
• <textarea/> != text editor. Editing HTML file inside textarea sucks. There is no syntax highlighting. No familiar key binding. Not available when site is off-line. Give me ViM please! (Actually I just edit the page/form inside ViM invoked by w3m browsing the TXP admin interface). I know you can do all that inside a proper text editor and then copy’n'paste into the textarea, but why an extra step?

It appears theme-in-DB is a major show stopper for me. It should have done what many other CMS/blog software are doing, by having the presentation-related customisation stored on plain text files.

Base 64 Encoded Plain Text?

Talking about plain text files, one thing that still puzzles me is why TextPattern stores certain plain text content in base64 encoding??

Why plugin content needs to be compiled encoded into base64 before importing into the database? According to Alex:

They’re not stored as plain PHP source files; rather, they’re “compiled” into a chunk of base64-encoded text, to allow for easy installation and minimize corruption problems.

WTF?! Easy installation? Not quite — copy and paste is the same regardless plain text or base64. Minimize corruption problems? There is md5 check sum in the dump, but I don’t see how corruption is an issue unless you try to copy it over a 300baud analogue modem that has its CRC broken.

All it does is making plugin developers’ lives more miserable. I am happy that plugin_cache_dir was introduced in 4.0.1.

While plugins need to be encoded in base64 to import, it is stored in plain text inside the database. However the CSS can be imported in plain text, but stored in base64 encoded in the database. What?! There’s no md5 check sum, no meta data — just plain text encoded in base64. It actually makes the text size 25% larger and even harder to compress. Plus wasted CPU time to decode them on every CSS access. Can somebody tell me why?

Conclusion

TXP Magazine worded this way (quoting Natelie’s comparison report):

If you’re a serious blogger with a professional blog, or a company who wants a professional content management system, use Textpattern. If you’re a new to moderate blogger or you’re just the type that likes things easy and comfortable, stick with WordPress.

In another word, a newly converted TXP user proclaimed that TXP is for professionals and WP is for blogging newbies. I don’t think it is true, and personally I found there are serious issues with how presentation-related files are stored. Currently the only redeeming value for TXP to me are:

1. Speed — WP is slow due to layers and layers of flexible filters and insufficient cache of intermediate result, which makes TXP fast in comparison.
2. Sections — effectively having multiple independent blogs inside one installation. It would require a big hack on WP to do it.

Will I still use TextPattern for my new site? I think I will at least give it a try, but with patches to solve my theme-in-DB issue.