On being a Textpattern developer

c: | f: /

A recent addition to the Textpattern development crew, here’s a little personal insight into the mindset behind that Bloke on the forum.

With the imminent release of Textpattern 4.3.0 — the smartest CMS on the planet — I thought it would be interesting to let you into a little secret: I really enjoy developing for it.

While it’s tough to manage in my spare time between being husband, daddy, sound engineer, literary genius and eccentric — and heartbreaking to say “no, that’s probably better as a plugin” to seemingly worthy core feature requests — I hope the choices I’ve made so far aren’t to the detriment of the product.

It’s quite a balancing act to keep the core light and breezy and aim for the 80:20 rule, because in the back of my mind is always the mantra:

is this feature likely to appeal to 80% or more of the user base while allowing the remaining 20% of hardcore folk who are pushing the web to fabulous new places to do new things and twist the platform beyond its humble boundaries?

My only yardstick is my own experience as a very average site designer. Luckily, what I lack in design skills I can make up for in sheer hackery and bloody-mindedness; the combination of talented designers and coders at TxpBuilders keeps me fresh and always stretches what I thought possible in software.

Late for tea and medals

Unfortunately, Txp 4.3.0 was out much later than I’d hoped. And it was entirely my fault: as well as owning a fabulous pair of ears that can dissect the audio spectrum into the finest detail when mixing music, I’m a hacker and perfectionist by trade and just can’t leave things alone.

A huge part of the delay was due to rigorous testing of Textile 2.2 (more on this soon), and bringing the new admin side markup to the core in an effort to try and smooth the transition between Txp 4.3.0 and Txp 5. The latter involved a lot of discussions with TxpBuilders, forum members, standards advocates, the team looking at Txp5’s interface, and myself (yes, I talk to myself) to come up with something that was semantic, backwards- and forwards-compatible.

I reckon it took the best part of six months of to-and-fro until I finally settled on what is now the 4.3.0 admin side markup soup. And the worst part? It looks almost the same as 4.2.0 to the untrained eye! Rest assured it’s very different and I’ll be writing a detailed article about it in the Extending Textpattern section of the wiki at some point soon.

Developing this monolithic change involved keeping two separate branches running side by side; and a lot of the time I had to manually sync the commits that were going into the official 4.x branch because of code conflicts. Considering I’d never used version control software before, I’m now a command line Level 3 zen master, although I’ve heard that Mercurial and Git are far better at merging changes and branching than SVN.

Managing Txp 5

With 4.3.0 finally having its eyes on the cage door, the next milestone is Txp 5. First the good news: it will not fail where Crockery (Txp 4.1) did. Partly this is due to a planned split in the codebase instead of difficult concurrent branch development, with which I can now wholly sympathise. How the dev team at the time kept it up for as long as they did is beyond me.

Secondly: how do we, as a team of three, manage such a huge undertaking in a timely fashion? Given that my wish list of things to change in Txp 5 is as long as the road down Death Valley, it’s going to be a challenge.

Many proposals have been put forth with varying degrees of severity:

  • Phase the release into a series of drops
  • Invite other devs to bolster the team
  • Encourage more patch submissions: this would probably involve changing the out-dated domo-list subscription model because it feels very tired and unfriendly to me
  • Move to a different repo that is more fork-friendly to spawn more widespread community involvement: Github springs to mind
  • Organise a hack-a-thon where we invite a tonne of Txpers somewhere and see how much we can get done in a weekend
  • Ditch the codebase and use Rails / MVC

I’m sure there are more. At this point I can’t say which, if any, are going to help or hinder development of our beloved toolset; opinions are fiercely divided.

My crystal ball is foggy but I can assure you of one thing: while there is breath in my body and a fire inside me for doing things better in the CMS arena, I am going to continue pushing the Textpattern platform as the designers’ choice for the web.

2 vagabonds left a mark

    Julián Landerreche

    Hi Stef,

    thanks for blogging about your work and feelings toward our beloved CMS, and happy to read that you will be coding for it until the last day ;)

    There is currently an ongoing email exchange at txp-dev list, which seems to tackle similar topics.

    I’ve sent you this privately, but this could be a good place to drop it again, as other TXP tinkers/thinkers may want to discuss about it.
    If we can make our TXP-powered websites to spit highly customized/clean/OCD/desired HTML code, could it be possible to do the same for the TXP admin’s “front-end” code?
    This is not an OCD request, but a way to make the admin side cleaner, more reusable, more extensible, and more predictable.
    I know you have been working a lot on this, mainly trying to get rid of tables and having better semantics, classes/ids to hook JS/CSS, so TXP admin side’s underlying building blocks are probably on their way to get better and better.

    So, here are some resources/ideas that, I think, go in the right direction to make TXP admin side a better “framework” for core hackers & plugin authors to work with.

    TXP 6 (Dream version)

    * applying some best practices on front-end coding to TXP Admin side’s underlying code (or “How to fix some of the mess down there, even when Bloke has already been moving many steps forwards”)

    ** implementing Paul Irish’s markup based unobstrusive comprehensive DOM ready execution technique on TXP admin side, helping plugin developers to keep their JS code tidy and sandboxed, and letting other plugin developers trigger/reuse already existing JS non-anonymous function, by having a big, extensible object literal ($.TXP = {}),. Or something like that.1

    ** Achieving a de-facto code standards2 and a set of patterns3 for TXP backend, while trying to applying some concepts (not all) of the so-called OOCSS approach4, a good&simple grid system [5], a simple-but-reliable CSS reset-with-sensible-standards6, while progressively adding some bits of HTML5-friendly markup and throwing away any kind of support for IE6 (and probably IE7 too) on TXP backend.

    [1] http://paulirish.com/2009/markup-based-unobtrusive-comprehensive-dom-ready-execution/
    [2] http://molecularvoices.molecular.com/standards/
    [3] http://developer.fellowshipone.com/patterns/
    [4] http://wiki.github.com/stubbornella/oocss/
    [5] http://www.1kbgrid.com/
    [6] http://sencss.kilianvalkhof.com/

    Thorpe Obazee

    I sure hope you make that github repo and let people fork and contribute via github.

    I really think you’d get more contributors when you really move to github and not some mirror from a svn.

    Wow. That’s just what I wanted to post and it seems that I can’t press the submit button.

    Hmm… I needed to press the Preview first. :(

Your turn

(required)

(required, never made visible)

(optional, linked with rel="nofollow")

(required)