Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [RFC] Custom Fields: expirable?
Okay. Thanks Stef.
Give me some time to test ;)
Patrick.
Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.
Offline
Re: [RFC] Custom Fields: expirable?
My sites use a custom fields extensively. Custom fields really make Textpattern the unique tool it is.
I’ll give it more thought, but initially I can’t imagine a use for expiring a custom field.
Offline
Re: [RFC] Custom Fields: expirable?
Thanks, towndock. If we can get away with a simpler concept without creation/expiration then that’s fine with me. One of the things we don’t have in the current implementation – although there’s built-in scope for it that I’m tentatively leaving for plugins to fill – is per-section fields.
Incidentally, since you use custom fields extensively, is there any chance you could let me have a test database – with data anonymised if necessary – from any site(s) that use them? I would really like to give the custom fields branch a thorough grilling with real world data to check that the upgrade goes smoothly and it rejigs all the table data appropriately.
I’m also on the lookout for anyone who uses glz_custom_fields because those fields WILL NOT be covered by the upgrade, so we’ll need to figure out some pre-upgrade migration system that allows the fields to be rehomed in the new table structure to avoid data loss.
Thank you!
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: [RFC] Custom Fields: expirable?
Bloke wrote #332524:
One of the things we don’t have in the current implementation – although there’s built-in scope for it that I’m tentatively leaving for plugins to fill – is per-section fields.
Incidentally, since you use custom fields extensively, is there any chance you could let me have a test database – with data anonymised if necessary – from any site(s) that use them?
I’m also on the lookout for anyone who uses glz_custom_fields because those fields WILL NOT be covered by the upgrade, so we’ll need to figure out some pre-upgrade migration system that allows the fields to be rehomed in the new table structure to avoid data loss.
In my two key sites, one has 32 custom fields, the other 23. Per section fields would be a HUGE benefit.
The way I currently make it all work is the additional fields come from glz_custom_fields, then that all gets managed with bot_write_tab_customize and some additional help from bot_cat_per_section_hide.
I would be happy to help with an example database.
Last edited by towndock (2022-01-27 12:32:17)
Offline
Re: [RFC] Custom Fields: expirable?
Okay, so to recap, we have one and a half people who think expirable custom fields is possibly a neat idea. Plus me. The rest think it’s potentially overkill. So it’s not looking good for the feature, and I’m not sure it’s possible to keep it there in the background, unused in core, in case plugins want to use it. A toggle is too complicated.
So I might kill it.
However, one other thought occurred: what if when you create the field, the default behaviour is to set the creation time to the UNIX epoch? 1970-1-1. That way, the ability to alter the field timestamps is retained for power users, but the default case would appear to work like it does now: all your fields would be universally available for all articles, and never expire.
Perhaps a checkbox ‘Reset timestamp to now’ (like on the Write panel) would be a handy addition to the custom field management panel? That gives you the option to quickly make fields from ‘now only’ when you create them, so older articles will still have the old custom content but newer ones will also take the new field(s). And if you ‘Set expiry to now’ on a field that’s in use, then it ceases to exist for all articles created after the moment you save the field.
Not sure. That sounds workable and retains a path for advanced custom field wrangling. But if the entire concept of date-based fields is too confusing, then I’ll axe it. Just don’t want to go through the pain of removing the facility and then find it’s actually useful!
To be clear, here’s a concrete example for a real estate site:
| Field | Created | Expires | Notes |
|---|---|---|---|
| Location | – | – | Field available for all articles |
| Price range | – | 2022-03-17 | Field is available for editing (on the Write panel) and viewing (on the public site) in all articles with their created timestamp prior to 17th March 2022. |
| Min price | 2022-03-18 | – | Field is NOT available on the Write panel (nor visible via public side tags) if article was created prior to 17th March 2022. It is only available in articles created from 18th onwards. |
| Max price | 2022-03-18 | – | Ditto |
Setting a custom field creation/expiry retains content in that field for articles created between the ‘created’ and ‘expires’ timestamps. But note that if you actually delete the field (from the Custom Fields management panel) then ALL content for that field is deleted, for all articles, regardless of timestamp.
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: [RFC] Custom Fields: expirable?
To answer towndock’s point more fully, per-section fields are a different beast.
The ability to group fields into a ‘family’ is built in BUT core does nothing with that information at present. A plugin could, fairly simply, match the family to the currently selected article Section and alter the available fields based on the selection, but there’s no intrinsic tie between the family (group) and section.
The reasons are:
- Selecting a section is an article-specific action. Custom fields are now going to be universal for all content types, so wiring them up to sections makes little sense from a global functionality standpoint. i.e. articles are the exception, not the rule. We could do it, but…
- … if you alter the Section and hit Save, what happens to any previous custom field content? Immediately obliterate it and replace it with the new field data (if any)? Keep it around “just in case” so if you switch back to the original section, your custom field data remains? It would take up database space. And could be confusing as it’s “not there” in the UI but “is there” in the database and thus visible via public site tags.
- You might not want per-section behaviour at all, and have all custom fields available for all sections.
Plugins can offer all the above, or something even more nuanced to suit individual cases. They could add section support to Images too, and tie them to custom fields, so you could make section-specific galleries.
So, since we can’t (easily) decide on the behaviour at the core level, support is available for grouping, but it’s not wired up to anything. You can use it for any devious purposes you can think of. Plugins will take over and provide the business logic, if required.
I hope that makes sense.
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: [RFC] Custom Fields: expirable?
The ability to group fields into a ‘family’ is built in BUT core does nothing with that information at present. A plugin could, fairly simply, match the family to the currently selected article Section and alter the available fields based on the selection, but there’s no intrinsic tie between the family (group) and section.
I can fully understand that1 What if these groups are loaded in a similar way that forms are? In that way, we can do our own taxonomies and not rely on plugins.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: [RFC] Custom Fields: expirable?
UNIX epoch would be better than the creation date, imo, which I find confusing.
Offline
Re: [RFC] Custom Fields: expirable?
colak wrote #332993:
What if these groups are loaded in a similar way that forms are? In that way, we can do our own taxonomies and not rely on plugins.
Not sure I grasp this. Do you have an example I could use to get my head round it please?
etc wrote #332998:
UNIX epoch would be better than the creation date, imo, which I find confusing.
I concur.
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: [RFC] Custom Fields: expirable?
Bloke wrote #332999:
Not sure I grasp this. Do you have an example I could use to get my head round it please?
The forms are categorised into expandable/retractable groups: Article, Miscellenious, Comment, File, Link, etc.
What if we can have that with cfs? That is, groups we can set and assign CFs to. In this way, we will be able to limit the amount of info visible in the page, and we will also be able to allocate, with some organisation, CFs to sections without the use of plugins. So, what I’m trying to describe here is not necessarily an optimum solution where a group of CFs are shown or hidden after the selection of a section, but a designer’s way, of grouping CFs, which could be expanded on click.
I realise that the problem here might be some duplicate CFs, ie Colour of a product could have 2 CFs (named slightly differently of course) depending on what grouping it is in. That is, if we have a section for cars and a section for vegetables (excuse the surreal connection), we could have colour-car under the CF_car group, and colour_veggies under the CF_veggies group.
Does that make sense?
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
Re: [RFC] Custom Fields: expirable?
Gotcha, thanks for the clarification. The grouping is available on the page (in global variables) so plugins could intervene here and group them or put them into twisties. Outputting them into groups in core is a great suggestions. I think I’ll do that by default.
Right now they just appear under a single “Custom Fields” twisty, which is not very informative for the casual user. That is the same for UCFs at present. Not great.
Whether we put some convention in place that textareas always get added to the ‘main’ area and anything else (checkboxes, text input, radios, etc) in the sidebar, well, maybe that’s a good enough start. Or perhaps we have a few ‘special’ names for the main blocks, so if you call your checkbox family ‘TXP_MAIN’ (or something) then it appears in that block. Otherwise it gets its own twisty group.
Ideally I’d like people to be able to drag n drop the Write panel to group/hide stuff and lay things out as they see fit. But we then hit another issue: is this done by admins? Per user group? Per section (if we find a way to link sections to fields in a meaningful manner)? Or can individual users change their own layout? Is there a suggested layout per user group by admins, but users can tweak it to hide stuff they don’t use often?
Lots of things to think about. And I don’t have an answer. Willing to be nudged in any direction people think is reasonably sane.
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
#24 2022-03-25 10:47:57
- Myusername
- Member
- Registered: 2019-12-12
- Posts: 165
Re: [RFC] Custom Fields: expirable?
I haven’t followed the discussion about date sensitive custom fields, but if I could vote, I would definitely vote YES. Unless of course there is some harmful point in all this that I didn’t understand, besides having a greater complexity. In that case, I don’t care how complex it is, if it really can do amazing things. And of course, with time, ideas around that will appear.
Offline