[RFC] Custom Fields: expirable?

Bloke · 2022-01-26 16:32:15

Currently, the unlimited CF concept includes three fields, for Created, Modified and Expires. This allows you to phase in (and out) custom fields as your data needs change, in a sort of structured fashion.

The basic idea is that each custom field definition has a ‘creation’ timestamp. So if you decide to add a field to represent “Price range” for your real estate website, it will only be available on articles created after the moment you create the custom field, because its timestamp defaults to “now”.

If you open an older article, you won’t see the Price Range field on those articles. If you want the field to appear on older articles so you can go back and retroactively add content, you’ll need to tweak the Created date for the field and set it some time in the distant past – earlier than your earliest article.

Maybe one day, your needs change. Your site is overhauled perhaps and you decide you need Min Price and Max Price fields, instead of a single Price Range. What to do? Set the Price Range to Expire from some date, and set the Min + Max Price fields to take over by setting their Created date appropriately.

If you did that and went back to an article created the week before the change, you’ll still see the Price Range field on that article because it was “in force” at that time. But if you create any new articles, after the creation of your pair of Min/Max fields, you’ll be able to populate those two fields instead, and the Price Range field won’t show up (because it’s ‘expired’ according to the date stamp of the article to which it’s applied).

Of course, you might decide that you no longer want the Price Range field at all, so you could alter the Creation date of your twin Min/Max Price fields to exist from the year dot. Then you could go and perhaps do some database wrangling to migrate all the price range data and split it into two, and populate the field data for all articles. Then you could actually delete the Price Range field – which would delete all data stored in all articles that contain that field. Your pair of fields would take over.

You might also want to migrate data from one type of field to another. Although the admin side tools won’t help you do that specifically (you’ll need to do some database wrangling) the fact you can phase out old fields and phase new ones in might be helpful as an interim step towards data nirvana. If you alter the data type, Textpattern will do its best to retain as much data as it can, but there’s only so much it can do. If you had a text field and you change it to a radio set, well, you’re going to lose data anyway, regardless of whether we implement date-based custom fields.

So, given all that background info, the question is simple:

Do we want a time-bound facility for our unlimited custom fields in Textpattern?

It’s built that way at the moment in the custom-fields branch. But on reflection, maybe that’s too complicated. Or overkill?

The alternative is to ditch the concept of creation/expiry for custom fields, so they work exactly like they do now: you make one, it becomes available to all articles, forever. If you delete it or rename it or change its data type, you’ll probably lose information when the data is modged into a different field type.

What do you think?

Dragondz · 2022-01-26 16:45:17

Hi, Stef

I think the date based custom firld is overkill for most of use but it can be useful for some people.

I dont know if it s not too complicated to put a on/off switch that is off by default that make the custom field work the old fashion and when it is on to use the new feature ?

If not l vote to let things the old fashion it is sufficiant.

Cheers.

Bloke · 2022-01-26 16:49:56

Thanks for the feedback, Dragondz. I revisited the branch recently and it is potentially confusing to have custom fields show up on some articles but not others, based on the way the field’s date interacts with the article’s publication date.

That’s kind of what sparked the question: I can definitely see an application for date-based custom field management so you can tweak things more easily over time. Data is rarely static for the life of a website. But if it’s too complicated and, potentially, will only be used by a small subset of users, well, maybe a simpler approach is better.

I’m not really sure if a pref/switch is feasible. I’ll give it some thought but my initial reaction is that it’ll make queries and tag wrangling complex to choose between the two systems.

colak · 2022-01-26 17:03:31

I can understand how date based CFs can be very useful, not only for prices, but also for events or other time sensitive articles.

At the same time, I’m wondering, what would replace the CF content once its time expires. I think that this may be a function which will be required.

You might also want to migrate data from one type of field to another. Although the admin side tools won’t help you do that specifically (you’ll need to do some database wrangling) the fact you can phase out old fields and phase new ones in might be helpful as an interim step towards data nirvana. If you alter the data type, Textpattern will do its best to retain as much data as it can, but there’s only so much it can do. If you had a text field and you change it to a radio set, well, you’re going to lose data anyway, regardless of whether we implement date-based custom fields.

Regarding changing CFs to radio buttons/etc. A way around this is to have the unlimited CFs so as to allow users to gradually manually migrate the data.

Bloke · 2022-01-26 17:23:23

Once content is assigned to a CF on an article, it’s stored. Even if a CF expires, when you go back and edit an article that used that field, you see the data in the old field, and can edit it and save it. The fields are time bound to the content.

You would be able to detect this situation in your article forms via conditional tags. <if::custom_field name="whatever">... would only trigger the contained content IF the field is in use for the current article. So you won’t need complicated logic to migrate stuff. Just wrap all your custom field data in your forms in a corresponding conditional and it’ll only show up if it’s assigned.

colak · 2022-01-27 08:26:52

Hi Stef, the way you are describing it, we have this already on the article level.

<txp:article time="any">
<txp:if_expired>
This offer has expired.
<txp:else />
Buy now! 50% discount! This offer expires on <txp:expires format="%b %d, %Y" />.
</txp:if_expired>
</txp:article>

I cannot think of how the above may be different if a timestamp is assigned to CFs.

Bloke · 2022-01-27 08:50:00

Not quite. That detects if the entire article has expired. I’m talking about field content within the article that could expire because you no longer need it or have changed the way that something is stored.

The custom field date information isn’t directly available to the front-end tags (as a value), but <txp:if_custom_field> will check to see if the current article not only has some content assigned to that field but also if that field is even in use at all in the article. If it isn’t, the contained content is skipped.

phiw13 · 2022-01-27 08:51:22

Dragondz wrote #332507:

I think the date based custom firld is overkill for most of use but it can be useful for some people.
[…]
If not l vote to let things the old fashion it is sufficiant.

Tentatively agreeing with this. Time-limited (or whatever way you want to describe them) seems a niche feature.

I might change my mind if I dig more in your proposal above.

jakob · 2022-01-27 09:17:49

phiw13 wrote #332516:

Tentatively agreeing with this. Time-limited (or whatever way you want to describe them) seems a niche feature.

I might change my mind if I dig more in your proposal above.

That’s my sentiment too, but like Philippe says, it may be just that I lack the perspective to see a common use case.

Maybe plugins can piggy-back on the new custom-field setup to add additional functionality such as this. If that would entail pre-preparing custom fields to support all kinds of as yet unenvisaged facility, maybe there just needs to be a method for plugins to insert their own custom functionality to the UI.

Bloke · 2022-01-27 10:09:56

Custom UI functionality has already tentatively been rolled out to a few panels (Diagnostics and Users so far). That trend will continue as we revisit each panel because it allows far more fine-grained control over tables – new columns, filters and so forth – using custom steps to process additional content. Nothing to stop us adding this to the custom field definition panel too.

How that concept shapes up on a panel such as the Write panel, well, I’m not sure yet. I would love plugins to be able to play. When the custom field renderer is migrated over to use the UI library, we’ll get callbacks for free on all UI controls, which is handy. The custom field set that’s exposed to the front-end is also extensible via plugin.

Just trying to decide how much functionality to bake in. Part of me loves the flexibility that expirable custom fields provides. Another part thinks it’s adding everyday complexity for very little real world gain, except in a few edge cases.

Pat64 · 2022-01-27 10:57:00

That new feature could be useful (in some cases, as commented above). I’m very excited about this. For example into a latest project we need to display some dates of courses (starting and expired) but with the pandemic times, some are in waiting list. So, my client choose to affect these courses within large time ranges (from 1st January to 31st December). And I display an according message that way:

Dates: <txp:evaluate query='<txp:posted format="%m" escape="integer" /> = 1 and <txp:expires format="%m" escape="integer" /> = 12'><strong>to be confirmed</strong><txp:else /><txp:posted format="%e %B %Y" /> to <txp:expired format="%e %B %Y" /></txp:evaluate>.

Before answer to you, could we test the actual feature? Is it present into the 4.9-dev branch?

Last edited by Pat64 (2022-01-27 11:00:36)

Bloke · 2022-01-27 11:36:48

Yes it’s present in the custom-fields branch. The front-end tags need wiring up better so they might not work very well, but the ability to create custom fields and see which ones appear on which articles is all there.

Textpattern CMS

Textpattern CMS support forum

#1 2022-01-26 16:32:15