What I'm expecting from Textpattern 5.0

I’ve been very impressed with the Textpattern CMS, especially its renewed development progress. Now that version 5.0 is within sight (not quite ante portas but one never knows) there has been quite a bit of activity around the subject, with feature requests and software philosophy both taking turns flinging themselves from the ceiling fan.

So far, here’s what I’m comfortable expecting from Textpattern 5.0:

Spark/Plug framework integration
A reasonable amount of plugin incompatibility
Remodeled admin panel, allowing for a nicer selection of features in admin themes, and improved usability
Possible new default admin panel and front end themes.

Framework

A new framework powering the thing is really cool. Sam Weiss, the creator of Spark/Plug, made it clear recently that many of the features of Escher CMS will be open for porting to Textpattern. Escher does do a lot of things right, and checks many of the feature-request boxes brought up in discussions about TXP 5.

Still, “new framework” does not mean all sorts of amazing new features arriving along with it. I’m OK with that. It seems more important to get TXP 5.0 out the door. I have a lot of trust in the Textpattern development team. Lately they’ve really done a great job releasing often and in the process continuing to attract new users and—in some ways more importantly—old ones as well.

Themes

I think new themes would be enough of a present to make most designers feel giddy. There’s a lot more going on behind a solid theme than design cues, as anybody using Phil Wareham’s “Hive” theme knows; still, it would be nice to see the old default themes moved forward both in appearance and ongoing maintenance. Phil really knows how to iterate and the developers seem very open to his informed suggestions. These all bode well for first impressions.

Plugins

Plugin incompatibilities are an important part of the process of moving forward. First, we can winnow out some old plugins and identify gaps easily. Some of these gaps will suggest changes to the Textpattern core.

Speaking of the core-plugin relationship, I tend to evaluate Textpattern plugins by three metrics: Codebase, features, and support. Changes in these metrics indicate a place along the scale between “core should have this feature” and “this is ridiculous to include in the core.”

My primary methods of evaluating the codebase: 1) taking a look at the code itself, 2) watching responses of other developers when they are asked to take a look at the code and 3) watching the response of the original developer when they are asked to make upgrades for TXP new release compatibility.

Features-wise, what kind of a gap does the plugin fill? Is this a plugin that I will use on almost every TXP project?

And for support: Does the plugin author respond to inquiries about a plugin in a timely manner, or is it orphaned? What kind of remarks does the plugin author make about the future of the plugin? Does the plugin author use the plugin these days?

The extreme corner case here suggesting some sort of intervention, then, is: 1) A difficult-to-maintain codebase, 2) A wonderfully powerful set of features that most can’t do without, and 3) signs of an orphaned state or a poor support outlook. In this case it makes sense to evaluate all options, among them the modification of the Textpattern core.

Users are known to beg for changes to the core of any software package, mainly because they see it as a form of insurance—they can put in the work to implement a Textpattern site with a reasonable guarantee that future upgrades will preserve features that use that functionality.

With plugins, even the 1-2 year time horizon is risky. There isn’t much incentive to develop a plugin beyond one’s own good intentions or scratching an itch for a beloved community. Even commercial software packages struggle to move forward when the management team realize that a large segment of their community rely on one or two outdated plugins.

My personal approach will be to examine every TXP 5-compatible plugin that I can, and attempt maintenance or upgrades when needed. I can ensure that at least I can work with the software I’m using, and attempt a fix, should I need to rely on plugins. But I enjoy coding and hope to get better at it in general, so I’m an outlier.

For regular “I just want to set up a blog/site/gallery” users though, it seems that the risk of venturing too far out of the core suggests a more thorough approach by the Textpattern development team. For example, a “Scripts and Plugins Manager,” or some other automated add-on management tools, may be appropriate. Other CMSes and software projects have adopted this approach, and it can be very comforting to end users, suggesting more of a shepherded flock and less of a herd of wild stallions rushing toward a 6-foot-wide canyon.

Back to reality

Of course, for TXP 5.0, enhanced plugin management tools just don’t matter. The point is to move forward, clear a new working space, and anchor the new framework.

As an end user, the smell of progress in the air seems most important now. Everything else—infinite taxonomies, custom item nirvana, and that talking virtual assistant—can wait.

Comments? I’m @circular on Twitter.