What's Wrong with TextPattern?

TextPattern Logo Planned to start a new site. Topic? All set. Hosting? Will be at my new VPS. It is going to be a light traffic site on a specific topic updated maybe once or twice a week, so I think a simple blogging app will suffice, i.e. no complicated CMS system.

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?


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.