Articles tagged in rant

  1. 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 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.

  2. Not Good Enough, ANZ!

    What recently happened to me regarding getting my credit card renewed through ANZ has just proved that, it is just Not Good Enough!


    I have moved from Kingsford to Daceyville over 14 months ago. Moving sux. You have to get in touch with everyone you like, don't like or indifferent about, and forward your new address and contact details just in case you missed out anything important from them. So I called ANZ's customer service, and tell them on the phone about my new mailing address. Everything is fine. I have been receiving my statements, and have arranged automatic payments to always pay my credit card bill on time.

    Fast forward to June 2005 - my credit card is expiring this month, and I have not yet received my new replacement card. All the providers that I set up automatic payments for kept on "reminding" me to have my card detail updated. So I called up ANZ last night trying to find out what's going on. And it turned out - Aarrgghh!! they sent the replacement card to Kingsford, the place where I had not lived over the last 14 months!! I have no idea why their customer service department is using a different database than the card issuing department, and I don't know what else have I missed that got sent to the old address instead. Ridiculous...

    In order to re-issue my new cards, I was then handed to the lost card department, so that they can cancel previously issued cards and dispatch new cards to me. That immediately renders my current credit card, which still have 10 days left before it expires, a piece of useless plastic. What??!!! The new cards will not be here for another 5 business days, and meanwhile, I will have no Internet banking as my access account is linked to my credit card. Neither I nor Vivian with a supplement card can make purchase, pay bills, shop on-line, etc with our ANZ credit cards. And I also need to risk the possibility that scheduled payments would bounce due to invalid card numbers.

    How can this be acceptable? Having two separate database to keep customers' details, but only updating one when customer requests a change? Denying customers' access to his own money, before a new card can be issued? Especially with a credit card that actually charges annual fee - shouldn't I expect premium customer service?

    Not good enough.


    Alright. I sent in a complaint via their on-line form, in a more passive wording. Not sure whether anyone would see it, but if they stuff up again, I shall find someone else to keep my money.

    Update: Reading through some of my posts, and realised that it wasn't the first time ANZ stuffed up big time on the help desk.