Recently I've been asked a few times about my choice in content management systems: I was previously the creator and maintainer of quite a few prominent Texpattern plugins and a few high-traffic Texpattern-driven sites. Textpattern was, in its heyday, an alternative to Wordpress which made the latter look like a script-kiddy's mess. However, times have changed, and the state of content management systems has, oddly, not become a whole lot better. Here are a few points that might be interesting to the reader.
Textpattern was written by Dean Allen and for the most part, it was written very well. He was ahead of the times in prevent comment spam: forcing users to preview a comment was clever and highly effective, unlike the approach that Wordpress took with various bayesian algorithms and blacklists. Furthermore, the code style was, in short, actually a code style - much unlike Wordpress, which barely attempted modularity and consistency. Also, the fact that the templates were almost totally complete - only comment forms and a few other elements were not themable - was a breath of fresh air from Wordpress. The ability to write a plugin which provides a custom tag by writing a single PHP function was unmatched and still is quite impressive.
However, like many maintainers, Allen decided that he couldn't keep up with development, so he enlisted a team of developers who have since maintained the core of Textpattern. What has resulted? Not much. First, renaming version 1.x to Texpattern 4, then gradual improvements to a fairly stable codebase. Slight additions of AJAX to appease switchers, a few security fixes, and small additions to the page templates.
One should not hope for a constant stream of whiz-bang features, but the expectations for content management systems have changed while Textpattern has remained somewhat 'stable.' Some of the largest users have noted that the team's willingness to ask for monetary contributions dwarfs their willingness to accept patches and make any substantial changes to the codebase. A fragment of users split on those grounds, founding xPattern, a (more) community-sponsored fork that oddly hasn't released any code yet.
Remaining problems with Textpattern
The first thing that comes to mind as far as Textpattern's ineffectiveness for serious websites is its style of managing plugins and templates. Texpattern keeps an enormous amount of code in the database - PHP code for plugins and pseudo-XML code for templates. This made sense before: users on shared hosting shouldn't have to open up FTP to install a plugin or change a little bit in a template. But the intelligence of this strategy fades on further thought: why keep this semi-XML code in a textfield when it's entire XML-ness seems to be tailored so that users can use nice text editors? Why keep using eval() to run PHP code: the ability to sandbox that code is far outweighted by the pain of updating it and the inability to debug efficiently? On top of this mess is the killer problem with keeping code in the database: any development team worth its rates keeps code in version control. Almost no normal development teams keep database changes versioned. Furthermore, the code and content are entwined in the database: you'll need to keep three backups: complete, content, and code, in order to do any kind of 'simple' versioning and backup, or you'll need to write a lot of custom code to only insert certain parts of a database dump.
Another problem is that the authors have been reluctant to change inconsistencies introduced by Allen seven years ago: for instance, the database schema. In the textpattern table, ID is named 'ID'. In txp_category, 'id'. In txp_prefs, 'prefs_id'. In users 'user_id'. In txp_discuss, 'discussid'. Why? Certainly it isn't for join statments, given MySQL's case insensitivity.
Also: the distinction between categories and sections is simply impossible to parse. Their official explanation still leaves some wondering, and another explanation makes me go 'huh.' The problem is that categories and sections will always be entwined far more than the Texpattern team hopes: and the continued reluctance to add subsections means that many will use categories as sections, thus messing up their grasping towards a real content hierarchy.
What's Wrong
The hooks that plugins, modules, extensions, etc, use are an API. They are not a minor detail in the architecture of the sytem: they are the system. Consistency in this API should be a top concern, and it clearly has not been. Textpattern has not broken many plugins because development has been exceptionally detail-oriented. However, Wordpress and Drupal essentially break every plugin every version change: because they were not designed to build on an API, but to 'offer an API.' Drupal, at least, continues to move towards having a grown-up API, and does so by making sweeping changes every version number. One can only hope that this strife for module developers will yield a better environment: especially because Drupal is utterly useless until 4-10 essential modules are installed.
Core developers need to be more aware of the ecosystem. Textpattern and Wordpress were both late to the game in this area: both offered only forums for plugin releases. This led to disorganization and plenty of inconsistency in plugin versions, etc. Drupal has provided a CVS repository to developers and drupal.org hosts essentially every useful module created for the system.
Note: I only refer to PHP-based content management systems in this post: not PHP frameworks or non-PHP CMSes. This website is powered by Django, but I am not writing here for an audience of developers. Additionally, non-PHP languages have serious advantages over the almalgamation of PHP, but hosting for them is still a statistical rarity.