Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Is the development of Textpattern at the end?
Yes, exactly. Thank you, douglgm!
Offline
Re: Is the development of Textpattern at the end?
Btw, Bloke… I hope that comment about “health” isn’t something I need to be overly concerned about.
Offline
Re: Is the development of Textpattern at the end?
“TXP 4.5” 2 years old.
And during those two years, the dev team has not taken much time to inform the user community in the development of the next release.
It took some members regularly ask questions to the devs via this forum to have some information about the future of their favorite CMS.
The official weblog is underexploited.
I understand that communication takes time and our volunteer team has more pressing things to deal with.
I think it’s a negative factor for TXP.
I feel TXP is now used primarily by amateurs or freelance web designer.
Our CMS does not have to be supported by web agencies sufficiently.
For an agency chooses a tool, it must have a secure medium / long-term vision of its evolution. TXP, by his lack of communication, does not inspire confidence.
It is a pity, because a stronger support of the profession would probably recruit more developer in the project and create a better dynamic.
I’d like to see better communication to the Textpattern roadmap.
Offline
Re: Is the development of Textpattern at the end?
I hope blokes health is in tip top condition too
Offline
Re: Is the development of Textpattern at the end?
Bloke’s health is fine. Nothing a little sleep can’t fix :-)
OctoberCMS looks interesting. Anything sensible we can pilfer pay homage to in Textpattern? Or is it, as michaelkpate says, a very different workflow? Twig is good, although not as familiar to Txp users as employing tags to do the same thing (e.g. plugins for conditionals and loops, via Forms).
Regarding communication, yes I’m crap. I know this and have to accept it. All I can do is apologise (again). If anyone wants to step up and be communications secretary in charge of content, raise your hand and we’ll fold you into the loop no problem.
An intermediate release is awaiting a couple of security updates which I might be able to do if I can dig out my login to access the disclosures, but everyone here knows I suck at security so unless it’s a simple patch, we’ll need someone cleverer than me on the case.
Roadmap roadmap roadmap. I don’t have one, nobody does afaik. The internals of Txp have changed fundamentally (for the better) but we’re not there yet. We could release 4.6 without it being fully migrated under the hood. It already has a lot of new stuff in there and it’s stable enough for production use, imo. The Issues list is a good place to start if you want to see what’s still left to do.
However, one of the major stumbling blocks is the fact we’re using MySQL exclusively and PHP has deprecated the mysql_* calls (see Issue 426). That means we’re on borrowed time. Moving to PDO is the way forward, imo, and some of the work is swapping out the calls to use the newer syntax in txplib_db.php.
But there are other things such as the way we build queries. When calling our getRows() function, for example, an entire query is submitted (e.g. "SELECT col1, col2 FROM table WHERE col3='".doSlash(squid)."'"). PDO does things differently for better security, so all such calls need to be refactored to use parameterized attributes: these don’t require escaping with doSlash() because PDO does that for us. That’s quite a bit of work on its own, but alongside this we could do with some newer aggregate methods to help us build such queries better.
A lot of this work has been done in ORM wrappers and there are many available for free which we could adopt. But they all come with a price: size/speed, and therefore bloat. And also having to keep up with the fact that at every major revision of the ORM they change the damn API and we’d have to rewrite everything (anyone who’s tried to upgrade Foundation knows the hoops to jump through with every major release). Since we try to be anti-bloat, incorporating a heavy database framework seems like a bad move, even though it’d largely be a drop-in-and-go solution at first.
So we’re faced with either reinventing a wheel (albeit a lightweight one) for our own purposes, or using a heavy off-the-shelf articulated truck wheel. Or, perhaps, find a good lightweight one – though these often start out with good intentions and evolve into heavy behemoths over time. The exception to date is my favourite Fat Free Framework which has an excellent and lightweight ORM built in. Txp could probably be rewritten in F3 with about 20 lines of code :-p But adopting F3, or similar, means more widespread changes would need to be made to Txp’s codebase and it’s probably overkill just to get access to the ORM.
Hopefully that small example shows the complexity of what we’re facing. And it’s not the only thing we need to address fairly soon. Nobody’s really focusing on that side of things at the moment (Nate Nolting did start a patch for us, but I don’t know how far he got with it). We probably should stop burying our heads in the sand and hoping it’ll go away, because it won’t. Someone needs to make a decision one way or the other and it needs some coding effort (uhhh, anyone?) That sort of thing is not my core competence so if I code it, it’ll work but it’ll be cack to maintain. And it’ll probably take me fifteen years at my current rate of working.
Anyway, once that and a few other bits and bobs are out of the way, we can probably release 4.6.0 and then maybe roll unlimited CFs into a point release, or into a much shorter 4.7.x release cycle. Or if I can lick it soon and it coincides with the PDO stuff, it can go in 4.6.0. It’ll depend on how many people are willing to test it.
In summary, I know things look quiet. But please don’t equate silence with death.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Is the development of Textpattern at the end?
I’d like to get a 4.6 release out sooner rather than later – there’s really nice stuff in there that’s been written for years and would benefit our users. In fact I’d rather release ongoing updates more often instead of major releases years apart (but not often enough to be irritating to devs/users).
That being said, I’ve started moving admin UI around recently so it can’t happen right now anyway (I’m doing that on GitHub though, because Google Code is dead to me). There’s no reason I can think of why the 4.5.7 release can’t happen in the interim, I thought we’d signed that one of to go out?
As for under the-hood stuff, that’s not my area – I understand we are halfway through a major refactor of the underlying code and Jukka wanted it all further along before a release, but I haven’t heard from Jukka in quite a while.
Offline
Re: Is the development of Textpattern at the end?
philwareham wrote #283594:
I’m doing that on GitHub though, because Google Code is dead to me
Perhaps I should contribute to that codebase then. I’d prefer to work in Git over SVN any day. Is it possible to migrate the issue tracker over?
There’s no reason I can think of why the 4.5.7 release can’t happen in the interim, I thought we’d signed that one of to go out?
Yeah, just those security things to deal with, then it’s good to go I think.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Is the development of Textpattern at the end?
Bloke wrote #283595:
Is it possible to migrate the issue tracker over?
Phil had mailed some pointers just today. Skipped your inbox perhaps?
Offline
Re: Is the development of Textpattern at the end?
Bloke wrote #283595:
Perhaps I should contribute to that codebase then. I’d prefer to work in Git over SVN any day. Is it possible to migrate the issue tracker over?
Hi Bloke. All I’ve done is fork then GitHub mirror and then branch off
I’ve got the new CSS grid system in that branch, which means I can start improving the admin layout quite rapidly – the prefs area in particular needs a new layout, and the categories page needs the proposal I sent you a while back (which I’ve already made a start on), plus lots of other UI changes and improvements I have in mind.
There’s also the hive theme and classic themes in my own repo list, which I’m developing independently of the SVN (which may be why people think Textpattern is dead, because they don’t see this work in SVN).
I’m currently talking with Robert about properly moving the SVN to GitHub along with it’s issue list and any release tags. I might attempt a test migrate at the weekend.
Yes, I’ve been slack in communicating and committing, sorry – lots changed in life recently. I’ll post a kind of roadmap of my dev plans soon so people can see what’s planned from my side.
Offline
Re: Is the development of Textpattern at the end?
wet wrote #283596:
Phil had mailed some pointers just today. Skipped your inbox perhaps?
Noticed it about 10 minutes after I posted, d’oh.
Incidentally, just stumbled across NotORM which is uber-lightweight and not a classic ORM as such, but with some powerful ORM-like features. On the surface it seems like a good fit, although our lack of discipline in column name conventions might scupper some of the automagic-ness of using it.
Anyone any thoughts on this?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Is the development of Textpattern at the end?
Thanks for the update guys. All over my head but it’s nice to know there are some issues being tackled and you’re working on unpainting TXP out of a corner.
Offline
Re: Is the development of Textpattern at the end?
Very informative read. Thanks to all of you, especially Bloke.
I feel like I know where things are headed for the first time in quite a while.
Offline