The direction of Textpattern 5

Bloke · 2011-01-20 09:24:05

As you may well be aware by now, Textpattern 5 is going to be the next version of TXP that is released. This topic is for discussion of the weblog post on our vision for TXP 5. More details on features will be posted once we — as a community — have ported the codebase to the new framework.

Please spread the word that anyone with PHP skills should consider jumping in and helping us with this mammoth task. The quicker we can do it the better and, as the saying goes, many hands make light work.

Sam will be posting details on where the new repo is and where to find the co-ordination information so we can all get stuck in to make it a reality. We’re looking forward to what we can do as a global team, so please dig out your coding trousers and get on board.

Many thanks in advance for any and all contributions.

thebombsite · 2011-01-20 11:37:21

Thanks for that Stef and a hearty welcome to Jeff. Well done that man.

All I really want to do is get my hands on an alpha or beta or whatever so I can start playing with it. I’m no PHP expert as you know but I can certainly test it out and report back, particularly as I have some innate ability do things in a way you hadn’t thought of. ;)

jsoo · 2011-01-20 12:36:55

In light of some concerns expressed about porting to a new framework, some thoughts:

[NB: I have been a Txp dev for all of a day and a half now, so was not involved in the decision to go SparkPlug, nor was I privy to the discussions leading up to that decision. That said, I support the decision fully.]

Why MVC? More particularly, why take a solid, well-functioning piece of software that happens to be based on PHP4-compatible procedural code, and port it to a PHP5-only, OOP, MVC framework? And why SparkPlug, a relatively new project currently maintained by a single developer, when there are umpteen better-known and better-established PHP frameworks out there? What about all my Txp 4 sites? And will Jeff ever stop writing interrogatively, and switch to declarative mode?

No question, Txp is an excellent CMS now, in version 4.3.0, and for many versions since. It’s a mature product with strong performance and security. But it has outgrown its codebase. Txp started life as one man’s blog, and many of the original design decisions, which made sense for a simple blog, are so ingrained in the code that they are seriously hindering further development in important directions that many of us want to see. We’re at the point where the payoff from a major code refactoring will be worth the pain. Pain, in this case, being extra work for devs and contributors, an interregnum with no new feature releases for a while, and extra work for plugin devs to port current plugins. Undoubtedly some orphaned plugins will be left behind.

Why MVC? Because it’s a well-understood pattern, suitable for Txp, and one that will help enforce separation of business logic from output. If you’ve ever written an admin-side plugin, you know how much separation there is currently — approximately zero.

Why OOP? Perhaps the strongest reason is to make it easier to set up a testing framework, so that new features can be tested systematically instead of haphazardly. With a good test suite we can have much better assurance that new features or fixes aren’t introducing new bugs. This is easier said than done: it takes disciplined effort to develop a meaningful test suite. The payoff will be increased development speed and confidence down the line.

Why a framework that requires PHP5? Because PHP5 has for some time now been so widely deployed that the price of maintaining PHP4-compatibility is no longer worth paying. Remember, PHP4 has been officially unsupported since the end of 2007.

Why SparkPlug? Because:

We have to pick something (this framework, that framework, custom framework)
SparkPlug’s principal developer happens to be a Txp developer: SparkPlug development will probably be influenced by Txp in a way we could not expect with any other existing framework
SparkPlug is a very lightweight framework that we can suit to our needs. Most of the well-known frameworks are more like pre-built applications that you have to bend your project to fit.
SparkPlug has some very cool extensibility features.

Legacy Txp: Undoubtedly there will be many existing sites that will not be upgraded, for various reasons. Frankly, I don’t yet know what are the long-range plans for Txp 4.3.0 support, but I rather expect that official support will continue for some time.

hcgtv · 2011-01-20 15:45:51

jsoo wrote:

No question, Txp is an excellent CMS now, in version 4.3.0, and for many versions since. It’s a mature product with strong performance and security. But it has outgrown its codebase. Txp started life as one man’s blog, and many of the original design decisions, which made sense for a simple blog, are so ingrained in the code that they are seriously hindering further development in important directions that many of us want to see.

First off, welcome Jeff to the dev team.

Onto my questions…

What are those important directions you want to head towards that the current code base hinders you?

Let’s say it’s just you, Stef and Sam working on this new refactoring, what is the time frame you guys have come up with that it will take to complete TxP5?

Why is Robert not joining in the fun?

jsoo · 2011-01-20 16:25:28

hcgtv wrote:

First off, welcome Jeff to the dev team.

Thanks Bert!

What are those important directions you want to head towards that the current code base hinders you?

Speaking for myself, a key issue is extensibility. There’s very broad agreement as to keeping to the lean core w/plugins philosophy. Obviously that makes extensibility crucial. To take one example, if you want to extend article list functionality in some way — unlimited categories/tagging, different selection attributes or settings, archives, etc. Now you end up having to duplicate big chunks of core functionality to do this, because article processing is essentially a black box — there are very few ways to hook into it. Then you have to maintain those chunks in parallel with core Txp.

Theming is not an issue I’ve looked into in depth, so I can’t honestly say whether the refactoring makes this easier or not. But I have to think that it will.

More flexible URL schemes, including better hooks for custom schemes.

From my experience with SparkPlug thus far, its most interesting feature is core classes that are dynamically extended at runtime. This creates some very powerful hooks for extending core functionality. I can even foresee plugins extending other plugins.

Let’s say it’s just you, Stef and Sam working on this new refactoring, what is the time frame you guys have come up with that it will take to complete TxP5?

I shall exercise my right to remain silent on that one. Seriously, I think it’d be counterproductive to put out estimates at this point.

Why is Robert not joining in the fun?

Someone’s got to hold the fort.

hcgtv · 2011-01-20 20:08:26

jsoo wrote:

From my experience with SparkPlug thus far, its most interesting feature is core classes that are dynamically extended at runtime. This creates some very powerful hooks for extending core functionality. I can even foresee plugins extending other plugins.

So what I foresee is that the core would shrink, with plugins adding most of the functionality?

I’d be interested to know, when the opportunity arises, what will comprise core, and what will be split out to plugins. I know we’ve touched on comments moving to a plugin, I’m just wondering what else would be better suited to be a plugin rather core code.

One of the best features of Textpattern is it’s speed, has anyone done tests as to what overhead SparkPlug adds to the rendering process?

johnstephens · 2011-01-20 20:19:38

hcgtv wrote:

One of the best features of Textpattern is it’s speed, has anyone done tests as to what overhead SparkPlug adds to the rendering process?

I’d like to hear this too. I know about Sam’s work on Escher, which might give some hints, and I know that Escher supports caching, which TXP can only do with a hack.

I wish I had PHP skills to offer— this sounds like a good path for TXP.

Bloke · 2011-01-20 20:27:24

hcgtv wrote:

has anyone done tests as to what overhead SparkPlug adds to the rendering process?

Sam has. I’ll let him explain it as he can do it better than me, but S/P itself will by its nature have a different set of overheads than the current code base. Some places it’ll do things faster, other places it might do things slower. But the key thing that S/P offers is built-in cacheing (when we get to that bit) and the results are impressive.

There are also things we can do with PHP 5 that we can’t do with PHP 4. For example, if we perhaps (hypothetially) forced native TXP 5 plugins to be built as Classes then we can take advantage of PHP 5’s on-demand class loader which means that only the plugins that are required to do the job of displaying the current page are loaded.

Compare that to TXP where every plugin (of a particular type: 0=public side, 1=public+admin, 3=admin) loads on every page request and you can see that it often adversely affects the rendering time of the page as you add plugins. Old-skool ‘compatible’ plugins would not be able to take advantage of the OD class loader — although I do have a vague notion of how to help such plugins do so without them having explicitly been written that way. I’ve no idea if it’ll work though, so don’t take this as a definite feature, it’s just a random musing at present.

Last edited by Bloke (2011-01-20 20:28:44)

johnstephens · 2011-01-20 21:11:38

What will be Textpattern 5’s relationship to Escher? Will TXP be a totally separate project built with S/P, or will it integrate significant parts of Escher? Will Escher continue as a separate project, or has it served its purpose as a demo of what would be possible for TXP?

artagesw · 2011-01-20 21:20:43

Escher will continue along its own trajectory. The relationship is simply that both Escher and Textpattern are Spark/Plug “clients.”

the_ghost · 2011-01-20 21:28:53

Some of my key ideas of desired future:

More and more callbacks – great nitro for new plugins development
More convenience in custom_fields – i don’t hesitate that i want to see EE-like custom_fields management
More convenient admin side (manage category’s trees at least)
Some web-based lib (textpattern.org?) that can allow to install desired plugin from admin-side after search at admin-side ( I know, something like this it going to happen yet). And upgrading, of course.
Sub-sections – it’s such a needed thing and it’s expected to be in core by every noob, that tries TXP at first time
…continue expected

Gocom · 2011-01-20 21:59:41

Spark, name that reminded me of Sparkle – one of the famous Cocoa frameworks (god this Obj-C takes time to get used to). Hope it sparkles like spark.

TXP5, as long as the code code is art, you don’t obfuscate it and you actually take the time to think on it, then bring it on. And umm, I hope it doesn’t take two long, two code bases and all.

Hopefully the code is going to take advantage of what PHP really can do, but w/o just going for the gimmicks, and gives the future plugin developers better stepping stone into the wep application biz.

Pretty great opportunity to renew Rah_; drop useless, go little less unprofessional with the model and such.

Textpattern CMS

Textpattern CMS support forum

#1 2011-01-20 09:24:05

The direction of Textpattern 5

#2 2011-01-20 11:37:21

Re: The direction of Textpattern 5

#3 2011-01-20 12:36:55

Re: The direction of Textpattern 5

#4 2011-01-20 15:45:51

Re: The direction of Textpattern 5

#5 2011-01-20 16:25:28

Re: The direction of Textpattern 5

#6 2011-01-20 20:08:26

Re: The direction of Textpattern 5

#7 2011-01-20 20:19:38

Re: The direction of Textpattern 5

#8 2011-01-20 20:27:24

Re: The direction of Textpattern 5

#9 2011-01-20 21:11:38

Re: The direction of Textpattern 5

#10 2011-01-20 21:20:43

Re: The direction of Textpattern 5

#11 2011-01-20 21:28:53

Re: The direction of Textpattern 5

#12 2011-01-20 21:59:41

Re: The direction of Textpattern 5

Board footer