Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Situation report for Textpattern 4.6 and beyond
Hi! Txp devs,
I am very happy with what I read here.
I have a question concerning the implementation of new custom fields :
Is it possible, as does glz_custom, fill a custom field (a select for example) with results coming from an sql querie (article list, image list, etc.). ?
If yes, what will be expected to write these queries? php (as glz_custom make) or Textpattern tags ?
I use it on multiple sites / projects to create relationships between items.
Second question :
Custom field work is available on a public branch?
Thank you for your work.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Tye, thanks for asking and Stef, thanks for the honest answer. I was also wondering what the state of play was for a large upcoming project. I can see you’ve all been busy pushing things forward for a while, but it sounds like 4.6 ist still a way off, then? Either way, I’m excited to see the way things are going.
TXP Builders – finely-crafted code, design and txp
Offline
Re: Situation report for Textpattern 4.6 and beyond
sacripant wrote #279463:
Custom field work is available on a public branch?
Not at present. I’ve not seen it myself yet (and I’ll need to amend the HTML of the admin pages quite a bit to allow it) – Stef is still beavering away on the underpinnings of it at the moment.
Offline
Re: Situation report for Textpattern 4.6 and beyond
sacripant wrote #279463:
Is it possible, as does glz_custom, fill a custom field (a select for example) with results coming from an sql querie (article list, image list, etc.). ?
Up ‘til now I’ve focused on the public side of things to make sure that it’s possible to get the data out in a reliable fashion when it’s spread across multiple tables. That’s working sweetly, even taking expired fields into account.
I’ve started work on the admin side now, which is, shall we say, ‘fun’ to do efficiently, especially given that:
- The UI element partials that were previously static (per article) I would like to become dynamic, when you change section, for example.
- The defined fields for the given article need to take the Posted date into account. Old articles might have a different set of fields than newer ones, for example. Though I think I’ve ruled out dynamically changing the fields on change of Posted date because it may cause too much confusion / data loss. Not sure yet.
- Data for each field needs populating for existing articles, default values may need populating otherwise.
- UI options for select lists and radio/checkbox sets need displaying. The lists themselves will be configured up-front when the field is set up, but there will probably be a callback per field at render time so if you want to dynamically populate the options or alter the field in any way, that’s the place to do it. The caveat of course is that if you change a set of options to include one that doesn’t exist any more, it won’t be selected. I hadn’t thought about using Txp tags to build the results. Allowing the data to be loaded from a Form might be a useful thing to do. This kind of thing does mean it’s up to you to make sure the admin side doesn’t break from a rogue option. Might have to put some safeguards in place, but I’ll see what can be done as this thing progresses.
- Saving data needs to be atomic/transaction-based because it’s not just in one table any more.
- As Phil says, it’ll need some markup alterations on the Write panel to make it effective. For now, I’ll just bung them all under the Custom Fields twisty until we can figure out a better solution.
Then there’s the screen to be able to actually administer the fields, names, properties, etc. But that’s relatively easy in comparison.
Fun fun fun.
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: Situation report for Textpattern 4.6 and beyond
I’ve got to put the new grid layout into the trunk soon, I’ve got it on my local development build at the moment.
That’ll allow us more flexibility in how fields are arranged on the various columns. Maybe we can work something out using jQuery UI sortable to allow users (with certain permission levels) to re-arrange fields and panels. I need to play around with some structural stuff once I’ve put the new grid in, and see if it’s feasible.
I’m snowboarding next week but it’s on my list of to-do stuff after that. There’s a substantial Hive theme update waiting to be rolled into the CMS too. Plus minor updates to Remora/Classic so they fit our latest design patterns.
I’ve had four months working solid on a Drupal site so I need a weeks break first to regain some sanity.
Offline
Re: Situation report for Textpattern 4.6 and beyond
A Titan work is going on here, you guys are bringing back txp early days excitement, huge thanks!
Bloke wrote #278776:
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.
IMO, Sections are already overcharged, wouldn’t introducing some Prototype entity be a better choice?
Online
Re: Situation report for Textpattern 4.6 and beyond
philwareham wrote #279469:
I’ve got to put the new grid layout into the trunk soon, I’ve got it on my local development build at the moment.
That’ll allow us more flexibility in how fields are arranged on the various columns. Maybe we can work something out using jQuery UI sortable to allow users (with certain permission levels) to re-arrange fields and panels. I need to play around with some structural stuff once I’ve put the new grid in, and see if it’s feasible.
I’m snowboarding next week but it’s on my list of to-do stuff after that. There’s a substantial Hive theme update waiting to be rolled into the CMS too. Plus minor updates to Remora/Classic so they fit our latest design patterns.
I’ve had four months working solid on a Drupal site so I need a weeks break first to regain some sanity.
Being able to allocate different custom fields to different sections and have order of fields on the Write page fully customisable would bring ExpressionEngine levels of flexibility to Textpattern which would be amazing.
It would make custom data modelling for more complex sites possible, as well as making the creation of properly marked up schemas much easier as each element of the schema could be separated out into it’s own custom field, without worrying about running out of CFs for more complex schemas.
It would make Textpattern a much more content focussed CMS and take it leaps and bounds above WordPress in terms of out-of-the-box core functionality.
Offline
Re: Situation report for Textpattern 4.6 and beyond
Yep. It’s gonna be hard work but that’s the hope I have.
Offline
Re: Situation report for Textpattern 4.6 and beyond
springworks wrote #279473:
Being able to allocate different custom fields to different sections and have order of fields on the Write page fully customisable would bring ExpressionEngine levels of flexibility to Textpattern which would be amazing.
wow!. sweet.
+1
…. texted postive
Offline
Re: Situation report for Textpattern 4.6 and beyond
etc wrote #279471:
Sections are already overcharged, wouldn’t introducing some
Prototypeentity be a better choice?
Please explain. I’m all ears.
My original, albeit sketchy, plan was to allow you to arbitrarily assign custom fields to a ‘group’ with a name of your choosing. It’s nothing more than a varchar field at the moment to avoid yet another join, albeit not very 4NF. That gives you the ability to decide to output the fields in any grouping you see fit. You could even make your own delimited names up if you like and put fields in some/arbitrary/hierarchy which you could split/play with, or put fields in more than one group. Again, not ‘proper’ database stuff with link tables and all that, but doing it properly could limit your creativity :-)
The thing I hadn’t quite figured was how to sensibly make use of it in core. One option is that if you give a CF a group name that matches a Section in your site, that field automatically gets displayed on the Write panel when that section is selected. Perhaps an option to turn that off, too. But I wonder if that’s a step too far. Especially given that a few lines of plugin code hooked into the article_ui.section callback will be able to do that and give you more flexibility (e.g. you might want to link them to categories too: a plugin would be able to do that far more effectively than adding a static option in the core Prefs). Plus, snice CFs are planed to work across content types, where does that leave File or Image CFs? Link them to category by default? Or not?
It starts to get a bit messy and, perhaps, limiting. So I’m wondering if there should just be a way to arrange/group the fields in some arbitrary way that core does not use but plugin authors could. A single group field achieves that, albeit inelegantly, and leaves implementation and imagination to plugin authors without tying us down to prescribed functionality that might not be to everyone’s tastes.
But, as I say, that was just a rough idea. If you have a better notion, then please share it.
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: Situation report for Textpattern 4.6 and beyond
Bloke wrote #279486:
One option is that if you give a CF a group name that matches a Section in your site, that field automatically gets displayed on the Write panel when that section is selected.
I like your ‘group’ idea very much, but wouldn’t use Sections for what you describe above, since they play already many other roles (page, style, front page, search, syndication, …). I would rather create another mandatory entity (call it Prototype) that would be assigned to each content unit (article, image, …). So, a typical article could be derived from a prototype containing Title, Body, Excerpt and so on. Another article could have another structure (prototype), for example no Excerpt, or multiple Titles (e.g. for multilingualism). An image has yet another prototype (source, dimensions, …), a video another one, and so on. Prototypes could be extended by the usual inheritance mechanism.
Of course, this is to much change for 4.6, but you could start with CF for articles. Actually, your CF ‘groups’ seem to be extensions of the default article (image, …) prototype, but I may tell nonsense as well. Great move, anyway!
Online
Re: Situation report for Textpattern 4.6 and beyond
I may not be understanding the issue (especially the more complex tech stuff). But in my simplistic experience I would want Custom Fields to be available at the Article publishing stage, and as part of a Section. So Home, About, Movies, Default etc could all have different custom fields or could share a default set.
Does this make sense? Is this the direction being planned?
…. texted postive
Offline