[RFC] TXP5 Custom Fields Management

etc · 2025-09-26 08:31:41

We expect that in Txp5 most entities (articles, images, etc) will have a configurable potentially unlimited set of custom fields of various types (text, date, etc). A working prototype already exists, but, before we go further, I’d like to be sure that the way it works suits most txp users.

So, how do you imagine new custom fields creation and adding/removing them to, say, articles? The subtlety here is that different articles might require different cf sets, unlike in txp4. For example, a ‘travel’ type article might need some ‘location’ cf set (country, city, etc), which is not necessarily pertinent to ‘food’ articles. Adding/removing custom fields one-by-one for each article looks tedious.

Please comment now or forever hold your peace :-)

jakob · 2025-09-26 09:10:10

Attaching custom fields to content types or article sections is, in my view, essential. Traditionally, this has been the realm of bot_write_tab_customize, but that just switches visibility according to the selected section.

I just had a look at what you and Stef have added to the custom fields branch, and you have the concept of meta (item) – a custom field – and meta entity – a content type … if I’ve understood them correctly. Will those entities eventually become separate panels in the Content area (and then perhaps with designable/arrangeable panels)? Or are the entities more a way of bracketing articles into types of articles with different custom field groups?

If, for example, these were separate entry panels, then you could attach custom fields/meta items to the respective content type (entity), via some kind of meta item chooser / drag-drop-orderable item on the meta_entity edit panel. An end user would then decide what content-type they’re adding from the Content area and the panel could/would remain static.

If, on the other hand, the custom fields / meta items are made dependent on the article being in a certain article section or article category, then the display of the meta items would need to respond to the chosen setting (as with bot_wtc at the moment).

I find that as sites get larger, the article panel starts to get unwieldy. A common scenario is that I’d like to isolate certain article types, for example events and ticker items, or some kind of item profile (a location, course, product, service), from the rest of the articles that concern the site’s main content areas, because they are updated at different frequencies.

——

One more general further comment on the notion of ad-hoc extendable custom fields that you raise:

It’d be great if some custom fields could be either scriptable, or made populable from other cms content. glz_custom_fields allows you to make custom scripts and I often use that to create relations between articles, e.g. dates that belong to an a course description or organisation persons that run a project, or some other kind of related article. With this setup, the article you want to cross-reference has to already exist to choose it, which leads to…
Sometimes it would be useful to attach one or more small pre-defined content blocks to an article without having to predefine them first. An example:
Think for example of a directory of places offering some kind of service: you might want to add a couple of contact persons, each with name, email and telephone number, and maybe also the availability times, to that article. Currently I define all these people in a separate pageless section, then use a multi-select custom field (powered by a custom script to grab those articles) to attach them to the article. Sometimes these are only used once in that article. Yes, I can write them in a textarea, but having a way of attaching a custom-field “pattern” to an article on an ad-hoc basis would be useful. EDIT: See, for example, the fields in Siteleaf, especially the repeatable list field.

Curious to hear what other people think…

Bloke · 2025-09-26 09:10:13

My take:

Define custom fields individually. Name, label, type, data storage requirements etc
Assign each a family name to group them. Comma-separated, so you can put the same field in multiple groups.
Attach the family name to the article type (which could be, but might not always be, its Section? Via plugin?). Not sure how to attach them for our other core types at present. Ideas welcome. Maybe everything should have a Section?
When you edit an article, great. It knows the family, grabs all the fields in that set and presents them for editing. Controlling screen location for each field TBD.
Content > Articles cannot then be a single table because columns vary. So split them by type. Either Content > Articles > Content Type gives you the table for all articles of that type, with the correct column headings. Or, perhaps better, but slightly less compartmentalised, flatten it to: Content > Content Type. It depends how far we go with unification of content.

So potentially, your Content menu might become:

Content
—> Travel blog
—> Food
—> Travel photos
—> Dishes
—> Links
—> Files
…

Where the first two are “article” style content types, the next two are “image” style content types (differentiated because they have assets and sizes and can auto-size based on the desired image dimensions you’ve defined in Prefs), etc. Those are attributes that regular articles don’t have.

I can’t see a sane way of treating all content equally. Files and Images (and potentially other custom types like Video and Audio) have different “usage patterns” that need special dispensation compared with text-only content.

Edit: e.g. There’s no automatic generation concept for ‘sizes’ of article. /travel/sunny-england?w=200 is nonsense when displaying a travel article. But if you include a gallery, each thumbnail might be 200px wide on the current device, so to display the grid the URL needs to fetch /travel-photos/england-london1?w=200 and /travel-photos/england-london2?w=200 and /travel-photos/england-manchester?w=200, and so on. Then, when the latter is clicked, fetch the full-size pic (and auto-generate/cache) /travel-photos/england-manchester?w=1600. Because the admin has defined that valid image widths for this design are 200 and 1600px.

Last edited by Bloke (2025-09-26 09:26:08)

etc · 2025-09-26 10:19:02

Wow, a Pandora box :-) Thank you!

jakob wrote #340658:

Attaching custom fields to content types or article sections is, in my view, essential. Traditionally, this has been the realm of bot_write_tab_customize, but that just switches visibility. Currently these are switched by section.

We should keep in mind that sections are proper to articles, so we need a different kind of selector to embrace all content types. So

I just had a look at what you’ve added to the custom fields branch, and you have the concept of meta (item) – a custom field – and meta entity – a content type … if I’ve understood them correctly.

Yes, what I loosely call ‘meta entities’ are user-definable content types based on ‘families’ (article, image, etc) which actually correspond to txp tables/columns, for technical reasons.

Will those entities eventually become separate panels in the Content area (and then perhaps with designable/arrangeable panels)? Or are the entities more a way of bracketing articles into types of articles with different custom field groups?

Both, I’d say. But images/files might be a special case, to discuss.

If, for example, these were separate entry panels, then you could attach custom fields/meta items to the respective content type (entity), via some kind of meta item chooser / drag-drop-orderable item on the meta_entity edit panel. An end user would then decide what content-type they’re adding from the Content area and the panel could/would remain static.

That’s the plan, indeed. Currently, cfs (metas) can be attached to entities via a multi-select box on the meta edit pane, but we will expose other mechanisms later when the structure is stable.

If, on the other hand, the custom fields / meta items are made dependent on the article being in a certain article section or article category, then the display of the meta items would need to respond to the chosen setting (as with bot_wtc at the moment).

Well, this looks family (article, image, …) related and pluginish atm.

I find that as sites get larger, the article panel starts to get unwieldy. A common scenario is that I’d like to isolate certain article types, for example events and ticker items, or some kind of item profile (a location, course, product, service), from the rest of the articles that concern the site’s main content areas, because they are updated at different frequencies.

It will be possible to filter items by entity, sure, again when the structure is stable.

It’d be great if some custom fields could be either scriptable, or made populable from other cms content. glz_custom_fields allows you to make custom scripts and I often use that to create relations between articles, e.g. dates that belong to an a course description or organisation persons that run a project, or some other kind of related article.

That’s very interesting, but what kind of scripting do you mean, txp, php, sql? We had an idea of ‘virtual’ custom fields, that would be sql queries (like select … from … where …), but it is not implemented yet. The difficulty with other types of scripting is that it is not trivial to inject them into an sql query, to be able, for example, to filter/sort <txp:article /> by this field.

Sometimes it would be useful to attach one or more small pre-defined content blocks to an article without having to predefine them first.

That’s probably doable, but might imply performance issues, to consider.

etc · 2025-09-26 10:41:53

Bloke wrote #340659:

Define custom fields individually. Name, label, type, data storage requirements etc

Yep, rudimentary done, as you know :-)

Assign each a family name to group them. Comma-separated, so you can put the same field in multiple groups.

That’s what I call ‘fieldsets’. Comma-separting is technically unpractical on fields creation/deletion, but the idea is the same.

Attach the family name to the article type (which could be, but might not always be, its Section?). Not sure how to attach them for our other core types at present. Ideas welcome. Maybe everything should have a Section?

Sections are already charged with features (frontpage, in search/rss), so a concept of entity is introduced instead. To discuss.

When you edit an article, great. It knows the family, grabs all the fields in that set and presents them for editing. Controlling screen location for each field TBD.

Yes, it works via the content entity. Re the screen location, I’m not sure. You might want to rearrange common ‘core’ fields too. Maybe, js and localstorage?

Content > Articles cannot then be a single table because columns vary. So split them by type. Either Content > Articles > Content Type gives you the table for all articles of that type, with the correct column headings. Or, perhaps better, but slightly less compartmentalised, flatten it to: Content > Content Type. It depends how far we go with unification of content.

So potentially, your Content menu might become:

Content
—> Travel blog
—> Food
—> Travel photos
—> Dishes
—> Links
—> Files
…

I’d rather group entities (like Travel blog and food) by their type (articles/images/etc), but that’s a detail.

I can’t see a sane way of treating all content equally. Files and Images (and potentially other custom types like Video and Audio) have different “usage patterns” that need special dispensation compared with text-only content.

I’m an image profane, so will leave it with you :-)

Bloke · 2025-09-26 10:57:31

etc wrote #340662:

I’d rather group entities (like Travel blog and food) by their type (articles/images/etc)

So would I.

I was conscious you were once advocating treating all content the same, and I didn’t want to squash your enthusiasm if I was just being too blinkered to understand how it could be done!

etc · 2025-09-26 11:18:15

Bloke wrote #340663:

I was conscious you were once advocating treating all content the same, and I didn’t want to squash your enthusiasm if I was just being too blinkered to understand how it could be done!

Oh, I’m still sure it could be done… without any chance to migrate an existing site to txp5 :-) But being able to store content in different db tables as in the current cf branch is great too plugin-wise.

Content > Articles cannot then be a single table because columns vary. So split them by type. Either Content > Articles > Content Type gives you the table for all articles of that type, with the correct column headings.

There is some ambiguity with cfs added ‘manually’ to articles, as Julian suggests (if I get it right). What is their content type?

Bloke · 2025-09-26 13:35:06

etc wrote #340664:

There is some ambiguity with cfs added ‘manually’ to articles, as Julian suggests (if I get it right). What is their content type?

How about people define custom fields and they are all “floating” until tethered to a content type by virtue of grouping them?

So you can’t “manually” assign a single custom field to a content type. You have to put it in a group, even if the group only contains one field, and attach that to the content type, so it is connected.

With that, we give people a way to essentially design a content type from core fields + CFs, which then becomes an entry in Content > Articles > {your content type}.

This does raise some questions over URLs.

At the moment, the section is a key component of the URL. An article can only appear in one section. But if you have multiple types, like a content type for houses, one for maisonettes, one for rentals, one for garages, etc, does each content type gets its own “section” by convention? /houses-for-sale and /rentals, etc?

Of course, your page template can handle display of multiple CFs from the different sections via conditionals. Categories and Authors can still connect content across sections.

Or are there situations where more than one content type of the same ilk (multiple article types) might be displayed in one physical section (like /for-sale/houses and /for-sale/rentals). In which case. How is that keyed from the URL to feed <txp:article>? Are content types subsections of a main ‘section’?

etc · 2025-09-26 15:18:47

Bloke wrote #340665:

How about people define custom fields and they are all “floating” until tethered to a content type by virtue of grouping them?

So you can’t “manually” assign a single custom field to a content type. You have to put it in a group, even if the group only contains one field, and attach that to the content type, so it is connected.

That’s indeed how it presently works, but adding an extra cf ‘manually’ to a single instance (article) can be useful too. Say, you have many properties to sale, but one of them is a floating house, so you might want to indicate the distance from the coast. Creating a custom type for just one item looks like overkill, as well as adding coast_distance cf to all properties.

At the moment, the section is a key component of the URL. An article can only appear in one section. But if you have multiple types, like a content type for houses, one for maisonettes, one for rentals, one for garages, etc, does each content type gets its own “section” by convention? /houses-for-sale and /rentals, etc?

Dunno. Filtering by content type will be technically possible, but whether this should be related to URLs in core is an open question. I’d rather investigate introducing custom URL schemes.

Bloke · 2025-09-26 15:52:38

etc wrote #340667:

Say, you have many properties to sale, but one of them is a floating house, so you might want to indicate the distance from the coast. Creating a custom type for just one item looks like overkill, as well as adding coast_distance cf to all properties.

Well, if you’re doing this kind of thing, your structured data needs a rethink :) Perhaps distance_to and a select list of places, then a distance_to_value wold be more appropriate. But I get your point.

That kind of application starts straying into NoSQL, MongoDB or Elastic territory, where data is just collections of ‘stuff’. Which is fine, but MySQL isn’t geared up for it. It’s too rigid. We’ll end up making a rod for our own backs when we try to a) render the fields, b) search them, c) draw the backend, d) …

I’d rather stick with using a convention than endless configuration, to reduce complexity. Adding a field to just one article in a set means rendering tabular data is tricky. You get ‘holes’ in it or ‘extra’ columns holding just one or two bits of data. So if we are indeed going this route with ad-hoc collections of fields tacked onto individual articles, we’ll need to devise a different way to represent data for ease of multi-edit/search/sort/filter.

Sticking with a pre-defined structure (where the definition is configured by the user) is preferable, imo. Happy to be convinced otherwise.

I’d rather investigate introducing custom URL schemes.

That would be marvellous.

Last edited by Bloke (2025-09-26 15:54:14)

colak · 2025-09-26 16:03:06

Thinking aloud. Somehow, on a functional level, I feel that CFs will have to be tied to sections. This would be a logical step to organise our data. CFs could show and hide using js on after selecting the section in the articles tab. The issue I’m is what happens to the data if one decides to change the section of an article. One approach would be to have a popup asking for the author to decide for the deletion or the transfer of the data to the relevant CFs of the section.

Bloke · 2025-09-26 16:27:00

Tying stuff to sections by default is not something I’d be keen to employ, because there are so many ways to implement it, that many people won’t be happy. Plus, as you say, data loss headaches.

This would firmly be plugin territory. But we should provide a simple way to connect them if desired (suitable callback hooks).

Alternatively, we have the opportunity to switch things around a bit. Remember Jukka’s plugin? I can’t remember its name but rah_wrach rings a bell. Essentially, when you start the editing process an intermediate step appears: choose section. That is then baked into the article because there’s no change of section drop-down in the Write panel any more.

After all, why would you write about a location or a recipe and then decide its section? Surely your writing process is “I’m going to write about N…” So you choose the appropriate content type up-front. That hardwires the section, the URL scheme, and the custom fields you’re going to see when you press Next. Then you fill in the rest and hit Publish.

And if you want to write another, a New Article button at that point creates a new record of the same content type.

If you want to create a post about a different content type, you go back to the main Write panel, choose the section/content type/etc from the splash screen and click Next to begin writing.

That intermediate step abstracts away many of the complexities of managing multiple content types. And sidesteps the difficulties inherent in the (very very unlikely) event you decide to write about something else halfway through writing an article.

Textpattern CMS

Textpattern CMS support forum

#1 2025-09-26 08:31:41