Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Situation report for Textpattern 4.6 and beyond
This is a request for one or more of Robert, Jukka, Stef and Phil to consider.
This blog post was really useful. As someone outside of the development team, but involved with Textpattern most days, I am absolutely in favour of this kind of info sharing.
My request: can we have February 2014 situation report for Textpattern 4.6, and beyond if the scope goes that far?
There are chunks of info I glean from various forum threads, Google+ conversations and other social network stuff, but a State of the Union-style update on textpattern.com would be hugely beneficial to the demographic who don’t frequent forums and/or social networks, those who are passively interested in Textpattern and probably far more people than I care to think of.
If this is too much of a task — and I’m hyper-aware that time is precious — then I’ll volunteer to take bullet points and carve a post together for approval.
Thank you in advance.
respectfully yours;
Pete Cooper, Textpattern user since 2005.
Offline
Re: Situation report for Textpattern 4.6 and beyond
I agree, I think this would be of huge benefit to the Textpattern community, especially seeing as TXP Magazine, (which is sorely missed) is dormant at the moment.
Offline
#3 2014-02-10 19:17:53
- jelle
- Member
- Registered: 2006-06-07
- Posts: 165
Re: Situation report for Textpattern 4.6 and beyond
+1
…it’s been 4 days….any news?
Offline
#4 2014-02-10 19:53:13
- milosevic
- Member
- From: Madrid, Spain
- Registered: 2005-09-19
- Posts: 390
Re: Situation report for Textpattern 4.6 and beyond
+1
<txp:rocks/>
Offline
Re: Situation report for Textpattern 4.6 and beyond
Sorry for not replying sooner. While Phil and Jukka gear up for more of an onslaught on our domains .com, .org, and .net, I’ll just bring you up to speed on what I’ve been doing: working on unlimited custom fields. I have an implementation in the works which balances data storage needs against ease of use, by adopting conventions in the core where possible and allowing plugins to override the core decisions. Doing it entirely in MySQL — which is arguably the most flexible approach — makes the code utterly unwieldy. And that’s nothing to say of what it’d do to anyone’s sanity if they ever looked under the hood. So I’ve been trialling a halfway approach where data and part of the configuration is in the database but other parts (that don’t change much) are overridable at the PHP level.
The project has thrown up some “interesting” problems, not least of which is that with custom field data spread across multiple tables, queries are more awkward to construct. And I’ve yet to manage to return a result set directly from the database with ‘one row per record’ like existing Textpattern does. However, through cunning use of some MySQL features like COALESCE()
I have managed to limit the amount of data and, with a little post-processing in PHP, to present this unified “one row per record” view to the rest of the system. As far as I can make out, an actual MySQL “View” is untenable because the configuration can change arbitrarily which would result in the View having to be rebuilt every time the custom field config changes, which puts the database out of action during the process (I may be wrong here, but everything I’ve read so far about Views is that they need to be ‘static’ in terms of their definition).
Anyway, the tricky part is that I’m trying to allow custom fields to have the notion of ‘valid from’ and ‘expiry’ which means they can be in force for a period of time and then go away for all new content. But just because they are no longer available for new content doesn’t mean that they’re forgotten for old content: and that’s where the crux of the problem lies. An article list might have 15 custom fields this week, while the same section only had 12 the week before because three have expired. The varying number of rows makes counting and pagination “fun”, and translating those into a coherent set of faux columns, so the data looks like it did before (and is thus easier to handle and breaks fewer plugins), means that old columns appear in the result set even if only one ancient article contains data for it.
Technicalities aside, I’m confident I can get it working. The database structure permits custom fields to be defined for all content types — in fact, any types, which opens up things to plugins for offering custom content types — and I’ve allowed fields to be grouped arbitrarily. One of the conventions I may adopt is that this ‘group’ refers to a Section for article custom fields, which means that per-section CFs can be constructed if you wish right out of the gate.
At the moment I’m hand-inserting the data in the database and retooling the front-end interfaces (txp:article_custom, txp:custom_field tags, etc) to make sure that the data can be fetched, paginated and ordered reliably. When that bit works, I’ll turn my attention to the admin side (the slightly easier half of the equation) because the hardest thing there will be the Javascript and AJAX stuff to alter the custom fields on-the-fly in a sensible manner.
Once it’s bandaged together I’ll probably think about abstracting it away into classes and stuff, but I want to prove it can work first before even considering that. Before that, I might put some effort into writing a migration plugin for glz_custom_fields (the core will only cater for its own fields: varchar) and finally extend the fields out to images, files and links. Maybe users too, which might remove the necessity for smd_bio. For clarification, I doubt all this will be in the first drop. I’d like to get articles done for 4.6.0 and then roll support for the remaining content types out in subsequent releases.
I’ve also got an improved search facility underway in a separate branch which is (well, was) about 90% done before I got sidetracked.
Howzat for now?
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
#6 2014-02-10 21:30:00
- jelle
- Member
- Registered: 2006-06-07
- Posts: 165
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #278776:
Howzat for now?
Informative….and quite exciting actually!
Thanks for the update Stef!
Go team TXP!
Last edited by jelle (2014-02-10 21:30:26)
Offline
Re: Situation report for Textpattern 4.6 and beyond
I’ve been on hiatus for a few weeks finishing a massive client site (launches next week) and when I’m back I’ll be looking a improving the admin-side layouts more. Especially if Stef’s CF stuff is to be taken into consideration.
And of course the websites (including TXP mag) will be in my plans.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Stef, Phil – thank you, this is great info.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Thanks a lot Stef and Phil. You are the best!
Offline
Re: Situation report for Textpattern 4.6 and beyond
Thank you for the updates. Always useful.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Lots of hard work guys. Thanks!
Offline
Re: Situation report for Textpattern 4.6 and beyond
Bloke wrote #278776:
I’ll just bring you up to speed on what I’ve been doing: working on unlimited custom fields.
I’ve also got an improved search facility underway in a separate branch which is (well, was) about 90% done before I got sidetracked.
Howzat for now?
unlimited custom fields … w00t!
…. texted postive
Online