From my Notebook >

Why I've run with the Textpattern-using-ProcessWire idea

Update: This idea probably won’t become reality, but I’m leaving the article here for those who are interested in ProcessWire and what it can do.

A short while ago, I sent off an email to Stef Dawson, lead developer of Textpattern 5, the next-generation Textpattern publishing platform. I wanted to let him know that I appreciated his work and understood that developing from scratch with a new code framework isn’t an easy undertaking.

As I read his reply and thought about the project, I had a crazy idea: I use the ProcessWire CMF (Content Management Framework) all the time. I use Textpattern all the time. Since ProcessWire is a framework meant for content management, what if Textpattern 5 could be built on that framework?

The advantages seemed immediately clear: Direct access to custom taxonomies, built-in custom fields of different types (allowing for custom content types out of the box (not just “article”), multi-language capabilities, complete user authentication and ACLs (Access Control Lists), all right out of the box. A TXP5 with all those features would be just what end users have requested for a long time.

On top of this, the developers would need to know how to work with…variables. Basic PHP. Maybe some object-oriented coding concepts. There’s no framework to learn, just an API. Code can be organized however the developers decide.

Oh, and Textpattern could keep its own control panel. TXP5 could (and should) still use Textpattern tags. It could look and work just like Textpattern always has, which I think is a great advantage in many ways, even though I also use ProcessWire’s CMS control panel quite a bit. Textpattern has its own flavor, and I think it should stay that way. Using ProcessWire as a back-end would allow it to do so.

Ryan Cramer, the developer of ProcessWire, has been very encouraging as I’ve asked him for his opinion. This is the sort of thing that ProcessWire was made to do, he says.

With so many requested features available via an easy-to-use API, with an extremely responsive and helpful developer available for consultation, and with a user community that is excited to start using TXP5, I think ProcessWire and Textpattern are an excellent match.

And that is why I’m still pursuing the idea, even though it may meet some resistance. After all, TXP5 has already been in development for about a year, and Stef has spent a lot of time documenting the new Sparkplug framework. But even considering what could be lost time, I still think a move to the ProcessWire content management framework could be most beneficial.

Note: I make a living off of both Textpattern and ProcessWire, support many websites on both platforms, and it is in my best interest to see both projects continue to thrive. I risk sounding like a rabid zealot at this stage, but why not pursue a great idea when it fits so well?

What do you think? I’m @Circular on Twitter.