[RFC] Custom Fields: expirable?

Pat64 · 2023-09-03 12:51:14

Your concept based on the expiry date of CFs is very interesting.
However, because future CFs creation will be unlimited, it could be confusing for users (writers)– the current case with the well known plugin– to see an interminable list of different CFs. For a better user experience, I think the most valuable feature will be based on sections, depending on CFs if they are relevant to the context (that’s your initial approach with the expiration dates, in part).

Bloke · 2025-01-06 02:12:02

And a short while later… (ahem, a yearish)… this commit marks the move towards unlimited custom fields for Txp 5.0.0.

Since the discussion above took place, a few changes have been implemented:

Custom field creation and expiry now mimic the current 4.9.0 and below behaviour: by default, all custom fields are universally applicable to all content for all time.
Two new checkboxes on the custom field management panel have appeared:
1. Reset time to now: will set the publication date of the selected field to NOW when you save the changes. This permits a shortcut if you want to introduce a new custom field only available from this moment forward. Any other timestamp may be manually specified if you prefer.
2. Set expiry now: will set the expiry date of the selected field to NOW when you save the changes. This permits a shortcut if you want to phase out a custom field and prevent people from using it in new assets created from this moment forward. Any other timestamp may be manually specified if you prefer.
Front-end custom fields are wired up so you can display the stored custom field values. Access to more metadata (e.g. data type, default value, display order, family, etc) is possble but not yet wired up to the tags.
Per-language custom field titles keep step with the changes to field names (in theory: needs more testing).
Per-language custom field titles can be displayed on the public site by using the new title attribute to the <txp:custom_field /> tag. Note that the language string displayed will always be in the current site language. There’s currently no provision for you to, for example, be showing a German site page and to grab English custom field titles from the database.
Varchars are now 7500 instead of 255 chars by default. That’s 7500 4-byte chars in utf8mb4, so potentially about 30KB if you’re storing mainly ASCII.

Next steps are to probably start rolling this out to other content types, panel by panel, and see how it holds up. And introduce a custom field iterator tag so you can loop over them instead of doing each one by hand. Watch this space.

Last edited by Bloke (2025-01-06 11:19:53)

Dragondz · 2025-01-06 08:59:09

Nice Stef ;)

phiw13 · 2025-01-06 09:21:11

Oh? Nice… Time to have a look again :-)

Does it already work with existing sites/databases or is that upgrading still on the todo list ?
Last time I tried, when accessing the login panel it still ran into a fatal mysqli error about missing tables or something (from memory).

Anyway, looking forward to this.

Bloke · 2025-01-06 09:29:42

I don’t know how it handles upgrades right now. I’ve added a _to_5.0.0 file and moved all the table creation and field migration code there, but it probably won’t be triggered unless thisversion is increased. It won’t know we’re on the dev path towards it at the moment. Might be better to wait till 4.9.0 officially drops and we bump the version.

phiw13 · 2025-01-06 09:32:49

Bloke wrote #338680:

I don’t know how it handles upgrades right now. I’ve added a _to_5.0.0 file and moved all the table creation and field migration code there, but it probably won’t be triggered unless thisversion is increased. It won’t know we’re on the dev path towards it at the moment. Might be better to wait till 4.9.0 officially drops and we bump the version.

That sounds good, we (I) can already play a little with a default install. Later this week when back home .

etc · 2025-01-06 10:55:03

Bloke wrote #338680:

I don’t know how it handles upgrades right now.

I’m not sure we’ll know it before txp 5 takes a more definitive shape. Meanwhile it might be necessary to install it anew.

Bloke · 2025-01-06 11:25:25

I’ve just boosted the varchar storage limit to 7500. That’s about the maximum comfortable range given we need two columns (one raw, one textiled) per row, and is a worst-case limit if you entirely use 4-byte characters. Lesser character sets will be able to squeeze up to about 30KB in a field.

Bloke · 2025-01-06 14:07:30

My goodness, that was easy. The system works! Image custom fields have landed

Just need to retrofit the tags so they can read the values.

Enjoy :)

colak · 2025-01-07 06:23:38

Bloke wrote #338689:

My goodness, that was easy. The system works! Image custom fields have landed

Just need to retrofit the tags so they can read the values.

Enjoy :)

!!!!!!

phiw13 · 2025-01-14 07:48:30

So far in some simple testing (creating & assigning CFs to Article and Image Content-type) this seems to work nicely.

Do I understand this correctly: A CF (any render type) with a created field filled cannot be used for content-type nodes created (or uploaded in case of an image) before the date set in the created field ?

Example: article created on 1/1/2025, the CF has the created field filled with 5/1/2025.

Still need to wrap my around the family field: that establishes some kind of grouping, I think and the default field (initial value, used if no value is specified when editing an article, or image ?).

Also, a thought: if the Help field is left blank (no help provided for that CF), does the pophelplink appear next to the CF? Currently it does, that sounds a little odd and confusing to me.

(I spent more or most time so far creating some content on that site)

Bloke · 2025-01-14 08:10:24

phiw13 wrote #338764:

So far in some simple testing (creating & assigning CFs to Article and Image Content-type) this seems to work nicely.

Excellent.

Do I understand this correctly: A CF (any render type) with a created field filled cannot be used for content-type nodes created (or uploaded in case of an image) before the date set in the created field ?

Correct. And likewise the field will not appear if its CF expiry is set to a date after the content was created.

Still need to wrap my around the family field: that establishes some kind of grouping, I think

You can use it for that, yes. But it’s not wired up to anything by default. Still deciding what (if anything) would make sense. At the moment the only way it can be used is via a plugin/theme.

the default field (initial value, used if no value is specified when editing an article, or image ?).

Correct. In the case of (multi-)select lists and check boxes etc, it uses the name not title to match. So if you defined a bunch of Options like this:

orange => Orange
sky-blue-pink => Sky-Blue Pink
mauve => Mauve
red => Red
greenish => Green(ish)

then setting ‘default’ to greenish, sky-blue-pink would preselect those two options on page load.

if the Help field is left blank (no help provided for that CF), does the pophelplink appear next to the CF? Currently it does, that sounds a little odd and confusing to me.

Good call. I did spot that but forgot to fix it. There’s a bug insofar as if you don’t specify a value, it renders the raw help string name, which makes the help field think it’s populated. I’ll see if I can fix that. Thanks for the nudge.

phiw13 · 2025-01-15 00:26:43

Thanks for confirming and explaining my observations.

BTW, right now it is impossible to delete a CF from the multi-edit widget: select the CF, from the widget select “delete”. Result: all CF are deleted… reload the panel (or wander around to another panel and come back to the CF panel): all fields, incl. the deleted one are there.

Bloke · 2025-01-15 00:31:41

Urk. I’ll fix the deletion code. It definitely used to work cos I was deleting fields a week or so ago.

Thanks for spotting it.

phiw13 · 2025-01-15 07:31:36

Bloke wrote #338792:

Urk. I’ll fix the deletion code. It definitely used to work cos I was deleting fields a week or so ago.

When / while you are looking at that, check the other 2 items – change content / render type. those are doing nothing atm, as far as I can see.

Thanks.

Textpattern CMS

Textpattern CMS support forum

#31 2023-09-03 12:51:14

Re: [RFC] Custom Fields: expirable?

#32 2025-01-06 02:12:02

Re: [RFC] Custom Fields: expirable?

#33 2025-01-06 08:59:09

Re: [RFC] Custom Fields: expirable?

#34 2025-01-06 09:21:11

Re: [RFC] Custom Fields: expirable?

#35 2025-01-06 09:29:42

Re: [RFC] Custom Fields: expirable?

#36 2025-01-06 09:32:49

Re: [RFC] Custom Fields: expirable?

Bloke wrote #338680:

#37 2025-01-06 10:55:03

Re: [RFC] Custom Fields: expirable?

Bloke wrote #338680:

#38 2025-01-06 11:25:25

Re: [RFC] Custom Fields: expirable?

#39 2025-01-06 14:07:30

Re: [RFC] Custom Fields: expirable?

#40 2025-01-07 06:23:38

Re: [RFC] Custom Fields: expirable?

Bloke wrote #338689:

#41 2025-01-14 07:48:30

Re: [RFC] Custom Fields: expirable?

#42 2025-01-14 08:10:24

Re: [RFC] Custom Fields: expirable?

phiw13 wrote #338764:

#43 2025-01-15 00:26:43

Re: [RFC] Custom Fields: expirable?

#44 2025-01-15 00:31:41

Re: [RFC] Custom Fields: expirable?

#45 2025-01-15 07:31:36

Re: [RFC] Custom Fields: expirable?

Bloke wrote #338792:

Board footer