In this review I’ll be comparing Textpattern vs WordPress. Textpattern is a content management system (CMS) that I’ve kept my eyes on for a number of years. I’ve yet to deploy it on any projects, however. Here are my thoughts about some of the aspects of Textpattern that makes it a good candidate to be your next linear publishing CMS.
Organizing content
Textpattern’s way of organizing content is pretty straight forward: You’ve got articles stored in sections. Article can be tagged into categories. When comparing this to WordPress, things can get a bit confusing.
Sections in Textpattern are like categories in WordPress but play a more significant role; whereas categories in Textpattern are like tags in WordPress. I’ll stick with the Textpattern terminology when talking about these two organizational structures.
Posts are the main content type in WordPress, but you also have another kind of content called pages. Pages are excluded from syndication feeds and the front page, and are meant for independent secondary content, e.g. privacy policy, about page, etc.
In Textpattern, there’s no differentiation between posts and pages: they’re both articles. The difference is whether an article is put into a section that’s included in syndication feeds and goes on the main stream on the front page or not.
You could have multiple sections in Textpattern that could be organized by broad categories like “video”, “sports”, and “tutorial”. Each of these gets their own syndication feeds, archives, and can have their own style and appearance.
The front page can easily be set up to display individual columns with the latest content from each section or use the default of having one main stream with all the newest content across sections set to publish to the front page. This is much more flexible than WordPress’ “everything goes in the same content bucket” approach.
This blog was previously organized like a Textpattern site where the section played a part in the URL. This was done by heavily customizing WordPress to behave more like Textpattern. I stopped doing this since the recent rebranding, but the idea and appeal of organizing things like this all came from Textpattern.
Textpattern doesn’t offer dated archives like WordPress does; there are no separate archive pages per month or year. This can make migrating from WordPress difficult as there’s no equivalent pages to redirect traffic to the old URLs to. Dated archives aren’t extremely useful, but based on this blog I can say that they do see a fair bit of traffic from search engines.
Textpattern has decent support for multiple authors with individual indexes for each author just like WordPress. However, there’s no support for author bios in articles or on the author archive pages which would be nice to have.
Writing content
The writing experience in Textpattern is put front and center; you’re put right in the editor after signing in rather than landing on a dashboard page like with most CMSes. WordPress especially falls short when it comes to providing a good writing environment, which you can clearly see in the comparison screenshots provided below:
Writing content in Textpattern (left) and WordPress (right) on mobile.
The above screenshot serves as a good representation of both Textpattern’s and WordPress’ administrative interfaces. There are more bells and whistles in WordPress, but Textpattern focuses on what is important.
WordPress provides a mobile app to compensate for the fairly bad mobile web experience of their administration interface, something Textpattern doesn’t do. Textpattern’s administration area is as well adapted to small screens as can be. It can be cumbersome to work with tall text areas in mobile web browsers, but that comes down to how poorly mobile browsers work with the soft keyboards in such situations.
I find it annoying that WordPress interferes with what I’m writing by substituting "dumb quotes" with “curly quotation marks” and substitutes smileyfaces and Unicode emoticons with its own emoticons. Textpattern doesn’t do any of that –in fact, it doesn’t touch your content at all except for properly wrapping paragraphs.
Textpattern can use Textile markup, paragraph-wrapping-only, or leave content untouched which can be set as options in the administrative interface. That is refreshing compared to WordPress which forces its defaults to be the only way to do things, unless you intercept and disable the functionality through plugins.
My one gripe with writing content in Textpattern is that the preview article button doesn’t show the article using the site’s design.
Templates
In WordPress, themes and assets (like stylesheets) are saved in a special directory on the file system. Textpattern stores templates and assets in the database. There’s only one template that can be installed at any time, as such there aren’t installable themes in Textpattern like there’s with WordPress. While there are themes you can install ontop of and replacing the default theme available, you can’t preview your website with a new theme before committing to it.
What you get instead with Textpattern, is a much more easily customized templating system. WordPress requires knowledge of PHP programming and a couple of dozen WordPress theming functions to get any theme going. Textpattern will let you get away with some knowledge of HTML and CSS, and will guide you through including any dynamic content using a tag builder.
The tag builder lets the user create txp elements which act as placeholders in the template for where dynamic content is inserted. The tag builder can create anything ranging from just the article title to lists of articles with the same tags to article titles. If you’d need anything more powerful, you could use the <txp:php>print("Hello press!");</txp:php> tag to execute custom PHP.
These tags also work inside articles. You could for example create an article called “Most commented articles” and construct a tag using the tag builder that would list out said articles.
WordPress publishes every entry on the front page in a chronological list. This is the default in Textpattern too, but using the tag builder you can quickly construct more elaborate content structures such as including several lists on the front page containing the latest articles from specific sections and categories. What takes a few minutes to set up in Textpattern using web standards plus the tag builder could take you an hour to reproduce in a WordPress theme.
Responsive images
Mobile devices want small images that are quick to download, and PCs want higher and higher resolution images to fill their steadily growing pixel counts. You can serve a mobile user a giant image and scale it down on the device, but this makes the download slow and possibly expensive.
You can’t serve a small image to a desktop user and scale it up as that would look like trash. The solution to this problem is called responsive images, and involves offering the browser lots of choice of different image sizes so they can get the one that best fits their screen size.
WordPress has decent support for responsive images, although it can be a bit difficult to configure with your theme. WordPress can resize and crop multiple image sizes and aspect ratios based on the desired image sizes specified in the active theme.
Textpattern on the other hand only has support for one thumbnail size and there’s no support for constructing the quite complex set of tags required for responsive images.
Manually rescaling, uploading, and constructing image responsive image tags would be very time-consuming. Getting away from that was one of my main reasons for doing away with a static site-generator in favor of WordPress.
I’ve looked into creating a plugin for Textpattern for adding responsive image support, but there’s little hope for doing that with the current plugin API limitations. I’d have to replace much of the image handling in Textpattern core before I could even start working on such a plugin. This would have been far too much work to commit to for the moment.
In my opinion, not having support for responsive images basically disqualifies Textpattern as an CMS option for any site that uses imagery to go with their regularly published content. It would create too much manual labor.
Plugins
The plugin architecture in Textpattern is underdeveloped and can be insecure.
Plugins are stored in the database and are installed by pasting a Base64-encoded text blob into a text field in the administration area. There’s no auto-update system for plugins, and plugins have to implement their own update checkers and notifiers if they want to deliver maintenance and security updates to their users.
WordPress stores plugins as individual files; which is probably better performance-wise than reading and decoding several potentially huge blobs of text out from the database on every page load. WordPress also provides a code hosting, revision control system, developer tools, and auto-update ecosystem to plugin authors.
WordPress is broadly extensible with some 610 filter and action API hooks throughout WordPress core. Textpattern has some 90 callbacks available for plugin authors, with an over-representation of admin-side callbacks compared to public ones.
WordPress is more extensible and more friendly to plugins. However, WordPress plugins are the most common way for security vulnerabilities to sneak in to the system. On the other hand, when a security vulnerability is noticed – it can be patched and users can quickly be informed of and deploy the updates on their systems. A Textpattern plugin author doesn’t have the same ability to correct mistakes and have their users apply the patches.
If I switched to Textpattern today, I could immediately let go of half the 30 or so plugins I currently use with WordPress if I switched to Textpattern. Some of the default behavior I’ve altered in WordPress just isn’t an issue with Textpattern.
Textpattern is more in line with how I organize my content, and it interferes less with what I write and how I publish too. However, I’ve tried recreating some of my must-have plugins from WordPress, but Textpattern doesn’t expose any APIs that would allow me to write the plugins in the first place. Plugins with Textpattern is a bit of a mixed bag, to say the least.
I also have some remaining technical concerns and some positive notes about Textpattern that didn’t fit in any of the above categories. Here they are in no particular order:
- Unusual set of MySQL query construction and custom escaping functions. Should be rewritten to use prepared PDO statements and drop the MySQL dialect requirement.
- Really not built to allow for database replication and load balancing.
- Storing PHP code blobs (templates and plugins) in the database prevents the use of OPcache and similar systems that improves PHP performance by storing precompiled scripts in shared memory.
- Built-in visitor logging system can be used to easily construct a “Top articles” list.
- Good cache handling by default and support for delta syndication feeds. I wrote a WordPress plugin for this if anyone is interested.
Conclusion
There are good ideas and good execution all throughout Textpattern. It’s a good CMS choice for anyone who just wants to write and don’t want to deal with maintenance. For many bloggers, it’s probably a far better choice than WordPress. However, Textpattern is starting to show its age and needs to step up on performance and scalability work. It needs to get on top of better image and multimedia management to stay on top of the needs of today’s creative publishers and the multitude of form factors site-visitors can be expected to use.
Textpattern has been around for more than a decade, but hasn’t seen the success of similar platforms like WordPress and Drupal. According to BuiltWith, only some 2800 websites currently deploy Textpattern; down from 4000 deployments just two years ago.
The development team is quite small, with some 16 people contributing any code in the period –. I’m currently the number ten top contributor on that list with just 9 small commits.
Before I finished writing this I thought the conclusion would be “Textpattern is nice, but I’m not going to use it.” After going through it again in more detail for this article, I’m not sure anymore.
Textpattern is to me in many ways what WordPress should have been. However, the plugin platform isn’t well enough developed and the multimedia management just isn’t there. Multimedia management in WordPress or Drupal isn’t great out of the box, but these platforms have plenty of plugins that provide more than adequate media file management and publishing.
In conclusion, WordPress is more extensible but Textpattern will get the job done [except for responsive images]. Textpattern is a better structural starting point than WordPress, but limitations in the plugin API limits how far you can go with it. I continue to find Textpattern quite alluring, but I’ll stick with WordPress for now.