[RFC] Custom Fields: expirable?

towndock · 2022-01-27 12:31:24

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)

Bloke · 2022-03-24 10:46:18

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.

Bloke · 2022-03-24 11:32:00

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.

colak · 2022-03-24 15:35:21

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.

etc · 2022-03-24 21:01:09

UNIX epoch would be better than the creation date, imo, which I find confusing.

Bloke · 2022-03-25 00:11:26

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.

colak · 2022-03-25 07:33:28

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?

Bloke · 2022-03-25 10:44:57

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.

Myusername · 2022-03-25 10:47:57

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.

Bloke · 2022-03-25 11:12:25

Noted, thanks Myusername. If we can default to UNIX epoch (I started changing this yesterday) but give people the ability to override the custom field validity window, I think it offers the best of both worlds.

That’s why I love opening up discussions like this because it gets everyone thinking about neat ways of working I’d not considered. So thank you to everyone who’s contributing. Keep it coming…

phiw13 · 2022-03-25 11:35:26

1/ i had been thinking along similar lines as Yiannis, ref. grouping. Ideally this should be available on the custom field creation+management tab and the Write tab (or other content-type tabs (images, Files, …). Glad to hear or see this is a realistic option :-).

2/ still have a hard time wrapping my head around your concept of ‘date sensitive’ fields, though.

3/ organisation (on the Write tab, esp). On that particular tab I see the main column more as content creation oriented where as the secondary/side column is for meta data (date, organisation with the site – category/section/…, keywords, etc). If some customisation (via ‘drag&drop’?) is offered, I think it should be a/ site-wide, and then b/ per section. I see little benefit in user customisation.

BTW – will the custom field be a separate panel or a sub-tab of the preferences panel?
BTW 2 – is the Custom field branch already a little bit useable for us mere mortals to explore ?

Thanks for all your work on this.

Bloke · 2022-03-25 13:13:09

Grouping by default on the various panels is definitely doable. The only sticking point is translations. Language management is… tricky and I’m not sure I’ve quite got it sorted yet.

Traditionally for things like Sections, we offer two fields: Name and Title. This is fine but you’re then limited to one language for the Title. At the back of my mind is that we need to move away from storing the Title in the dedicated table (such as txp_section) and move it to the txp_lang table so we can forge ahead with work on better internationalisation.

To that end, when you create a custom field (yes, on a separate panel under the Admin menu) the ‘Title’ field doesn’t put stuff in the ‘meta’ (a.k.a. custom fields) table but diverts it to txp_lang with a prefix (to avoid clashes with core field names… but I’m still thinking about this) and a language group/owner (now we have them available as of 4.7.x).

This poses interesting challenges when you, say, rename a CF. If it was called price, your cf is (internally) referred to as cf_price and your txp_lang string key is also cf_price. If you decide to call this max_price, when you save, Txp needs to hunt down the cf_price language string(s) and re-key them to cf_max_price. Keeping the two tables in step is not pretty but it seems to work under rudimentary testing.

Doing it this way opens up the possibility of using something like smd_babel to give custom fields unique titles per language so when you switch front-end languages, your field labels change too. Now, quite what happens if you define a field and label in English, switch admin side languages and revisit the panel is not something I’ve tried. In theory it’ll leave the Title blank and you’ll need to type in the new label in the current language and save it again to set it. That should work, clunky as it is. Longer term there are plans for a much better interface experience for multi-lingual content to be defined without hopping from panel to panel, this is just a stepping stone.

The other option is to add a lang column to every table. But it’s not very normalised, and for things like txp_section that would mean duplicating records for a section, with the only difference being the language. That makes section counts and iteration more annoying. It works okay for the textpattern (articles) table – sort of – if we add a grouping capability so we know which articles are in a set. But for other stuff, it’s more hassle than it’s worth to store the language translations directly. A link table would be way better, though that brings its own baggage like referential integrity.

Anyway, it’s kind of off-topic for here. I only bring it up because it impacts custom fields and I don’t want to implement something and then find it’s more difficult to migrate to a fully-featured i18n environment later. So it’s important to discuss it on the fringes of this work to avoid causing us problems in future.

The CF branch should be usable as-is BUT it might throw a bunch of errors at first for missing this and that. I’ve no idea what will happen on upgrade or brand new installation as I’ve been iterating piecemeal. But once it’s going, it works okay. Article fields only for now.

Maybe wait until hopefully next week when I’ve ironed out the timestamps thing and fixed some more PHP 8 warnings. I’ll also have had time to test it on a brand new installation and I’d like to give it a whirl on the huge database that towndock kindly provided me. That’ll be… fun!

P.S. I agree that user customisation is perhaps overkill. But depending on how it’s implemented (e.g. if we’re allowing Publishers to do it via drag/drop) then there’s little technical impediment to allowing all users to do it. Bar storing the state per user instead of per panel.

Last edited by Bloke (2022-03-25 13:20:17)

colak · 2022-03-25 13:38:32

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?

One of the things that I read about 10 years ago was how the front/back end design of fb helped in its success and how MySpace’s flexibility lead it to failure. fb’s pages all looked similar but they functionally and aesthetically “worked.” MySpace front end pages were mostly customised by users who had little to no html/css experience.

Although, it goes without saying that I would not support fb, there is nevertheless something to be said about common experience. The web has individualised our experiences and I think that most of us here know where that has lead and where it is leading.

As such, I would urge for the common back-end interface. Drag and drop adjustments may sound good on paper but it will make supporting the back-end and any queries about it in the forum, much more difficult as we would not know what our users are looking at.

I really like the idea of TXP_MAIN which I think that it that could initially contain all existing CFs in the group.

Bloke · 2022-03-25 13:39:39

Date sensitive fields visual example…

----------------------------------- Time ------------------------------->
<--A1---A2------A3------A4----A5-A6----A7-A8--A9---A10----A11----> (article posted times)
<CF1-------------------------------------------------------------------> (custom field 1 defined from Epoch)
<CF2-------------------------------------------------------------------> (custom field 2 defined from Epoch)
<----------------------------CF3---------------------------------------> (custom field 3 defined from some date, no expiry)
<------------------CF4c------------------------CF4e--------------------> (custom field 4 defined earlier than CF3, but expires a little later)

Okay, so given the above scenario. There are two sets of dates at play:

The article posted dates.
The custom field validity ranges (created and expiry dates).

CF1 and CF2 are available to all articles when you click an article to edit. The CFs appear in the Custom Fields twisty.

However, if you click on articles A1 thru A4, you will not see CF3 because, as far as the articles are concerned, it doesn’t exist. The posted date stamp of the article is compared to the created stamp of the custom field and if it isn’t in range, you don’t see it. If you click to edit articles A5 thru A11, you will see CF1, 2, and 3 can take values.

Custom field 4 has a start date and an expiry. Articles A1 thru A3, and articles A9 thru A11 will not have CF4 in them because its datestamp is outside the article’s Posted date.

Articles A4 thru A8 inclusive will show all 4 custom fields for editing.

The same logic is (or will be) applied to the front end. Any field out of scope will not be rendered. So if your template has a <custom::field name="CF4" /> tag then it will only show its field content when viewing articles A4, 5, 6, 7, or 8. Similarly. <if::custom_field name="CF4"> will only be true for those five articles.

Is that any clearer?

Bloke · 2022-03-25 13:45:11

Good points, Yiannis. One of Textpattern’s guiding principles is “convention over configuration”. If we offer an option for something, it’s usually (well, should be) a last resort because if there’s something that can be decided via convention – be that a naming strategy or a logical way of working – we’ll take that first.

If we can get away with not allowing extensive customisation of the admin panels by users, that’s terrific. If some users want that, wonderful. As long as the system is flexible enough by providing all the data one needs on the page, a plugin can take over and add the whizzy stuff.

Textpattern CMS

Textpattern CMS support forum

#16 2022-01-27 12:31:24

Re: [RFC] Custom Fields: expirable?

Bloke wrote #332524:

#17 2022-03-24 10:46:18

Re: [RFC] Custom Fields: expirable?

#18 2022-03-24 11:32:00

Re: [RFC] Custom Fields: expirable?

#19 2022-03-24 15:35:21

Re: [RFC] Custom Fields: expirable?

#20 2022-03-24 21:01:09

Re: [RFC] Custom Fields: expirable?

#21 2022-03-25 00:11:26

Re: [RFC] Custom Fields: expirable?

colak wrote #332993:

etc wrote #332998:

#22 2022-03-25 07:33:28

Re: [RFC] Custom Fields: expirable?

Bloke wrote #332999:

#23 2022-03-25 10:44:57

Re: [RFC] Custom Fields: expirable?

#24 2022-03-25 10:47:57

Re: [RFC] Custom Fields: expirable?

#25 2022-03-25 11:12:25

Re: [RFC] Custom Fields: expirable?

#26 2022-03-25 11:35:26

Re: [RFC] Custom Fields: expirable?

#27 2022-03-25 13:13:09

Re: [RFC] Custom Fields: expirable?

#28 2022-03-25 13:38:32

Re: [RFC] Custom Fields: expirable?

#29 2022-03-25 13:39:39

Re: [RFC] Custom Fields: expirable?

#30 2022-03-25 13:45:11

Re: [RFC] Custom Fields: expirable?

Board footer