[RFC] TXP5 Custom Fields Management

Bloke · 2025-09-27 10:59:25

Vienuolis wrote #340687:

I’m afraid we’ll abandon the original principle: “Just write.”

No. It’s a central component of Textpattern’s ethos.

Switches to some section, categories, CF sets, media types, additional TxP forms, etc. will always remain in the Write panel, won’t they?

Yes, kind of. But maybe not Sections. It depends. At the moment, everything is the same.

Imagine you run a restaurant reviews site where you critique local hotspots. You write articles on actual restaurants, and within those you write about signature dishes too. That’s two types of content.

In Txp 4.x, you need to create custom fields like this:

Location
Area
Famous for
Rating
Dish type
Allergens

Every article has all fields, even though the last two only apply to Dishes and the first three only apply to Restaurants, with Rating perhaps shared (rate the place, and rate the dish).

With unlimited CFs, this becomes more nuanced because you can define “article” content type custom fields:

Location
- Family: restaurants
Area
- Family: restaurants
Famous for
- Family: restaurants
Rating
- Family: restaurants, dishes
Dish type
- Family: dishes
Allergens
- Family: dishes

(Along with other data like name/title, help text, options for multi selects or checkboxes and so forth. Even expiry if it only applies to a time-sensitive set of content like an event. And you could maybe specify that Location is an Image custom field too and use it to tag your photos with where they were taken).

When you come to create content, with the best will in the world, you’re not going to start writing about a restaurant and then halfway through the process switch to writing about a dish instead. But currently Textpattern allows you to do that by changing Section partway through the process. And plugins like bot_wtc and glz_cf have catered to this design decision by allowing fields to be switched / moved on the fly. But that creates issues. Primarily data losses if you change your mind mid-article because you didn’t notice that the Section was wrong when you started writing.

All we’re saying here is that when you Just Write, you may be given a splash screen or choice of some sort to decide the type of content you want to write about. You select one, and the Write panel then appears, with all the core fields and custom fields that are defined for that type of writing. Category, tags, override form, publish/expiry dates, and so on, are all the same. Even section, because different types of content can appear in the same section. It’s undecided at present if we’re going to permit admins to limit what content can go in what sections: that might be handy if you don’t want your Dish-writing freelancers to accidentally publish their content in the ‘restaurants’ section of the site.

The crucial factor is that once you start writing an article of a particular type, the UI doesn’t need to change at all. Far simpler. And a far more natural content creation process.

But you can already go further when defining the custom fields. Why use an Article and manually use the ‘family’ field to help you or a plugin decide what goes where? Leave Articles for blog posts, and instead create entirely new content types called ‘Restaurants’ and ‘Dishes’? We’re calling these things Entities at the moment. They’re just a dedicated version of the Article (or Image, Link, or whatever base content type you choose) with specific fields associated with them. And fields can be shared among entities.

So, when you define your custom fields, tie them to your custom content types and they appear on the Write panel.

As it stands, today, visit the Articles panel and look next to the New Article button. If you’ve defined a new content type (Entity), there’s a dropdown list next to the button. Choose Restaurant, click the button and you jump to the Write panel all ready for you, with the relevant custom fields available, plus all the regular article fields.

There’s still a way to go. This stuff only landed in the custom fields branch this week. But it has seriously awesome possibilities.

Last edited by Bloke (2025-09-27 11:37:13)

Bloke · 2025-09-27 11:09:00

P.S. Oleg, how about a ‘filter’ link next to the Entity selector on the Articles panel? So if you select one and click Filter, it only shows articles in the table that match that entity. Does that work? Or are we going to expose the entity as a table column so you can search/sort/hide as usual?

Just thinking that if the entity types are segregated by design, we can then alter the available columns based on the needs of the content type. And plugins could add columns to display CFs in the table for filtering purposes.

The only issue at present is how to persist the entity selection across pagination, because there’s no current way to select “all” which is the default view when you land on the Articles panel. Maybe the default view should be only Article entity types, so the selector acts as a dual purpose tool: allow filtering to see what articles have already been written in that entity type, and As a hint for the New Article button to create a new record.

Last edited by Bloke (2025-09-27 11:11:10)

etc · 2025-09-27 11:54:26

phiw13 wrote #340690:

Do I understand it correctly: that meta-entity id something again to a category in current (4.9) implementation – a way of grouping?

More or less, they group the content by custom fields collections proper to each group. But now that I’ve read users comments (thank you all), this might slightly change.

Bloke wrote #340692:

Choose Restaurant, click the button and you jump to the Write panel all ready for you, with the relevant custom fields available, plus all the regular article fields.

That’s what I thought, but it should actually be easy to switch the entity on Write tab too. What if we output all available cfs inputs, but hide those that do not belong to the currently chosen entity via some css magic? Then the switch is instantaneous, even if triggered via js, and we don’t loose already edited values. Of course, we would validate the data server-side on submit.

Same on the list page: we output all custom columns, up to users to choose which ones they want to display. The extra performance cost shouldn’t be enormous, to test.

Bloke · 2025-09-27 12:07:57

That works for me. By all means give that a whirl as long as it doesn’t make the page too heavy for many many content types.

Bloke · 2025-09-27 12:21:13

I know it’s early days for tags and CFs but a few observations using a multi-select named ‘region’ with options of north, south, east, west, midlands, london, scotland:

<custom::field name="region" />
london

<custom::field name="region" title />
Region
?? (expect 'London')

<custom::field name="region" wraptag="span" class="mywrap" />
<span class="mywrap">london</span>

<custom::field name="region" wraptag="span" class="mywrap" title />
<p class="mywrap">Region</p>
(wrong wraptag?)

<custom::field name="region" label="Location" />
Location<br>london

<custom::field name="region" label="Location" break="" />
Location<br>london
?? (Expect no break, maybe?)

<custom::field name="region" label="Location" break=": " />
Location<br>london
?? (Expect Location: london)

<custom::field name="region" label="Location" labeltag="h4" wraptag="span" class="mywrap" />
<h4>Location</h4><p class="mywrap">london</p>

<custom::field name="region" title />: <custom::field name="region" />
Region: london

<custom::field name="region, rating" />
Textpattern Notice: Field region, rating not found

and so forth…

Is there some scope to be more clever here? E.g.

Empty title attribute displays the field content’s title from its name => Title pairing (if a multi-select/checkbox/compatible field, otherwise it spits out the same as name).
Empty label displays the field’s label. Otherwise uses the given label="Some label".
Both an empty label and a specific label="Some label" honour the labeltag attribute.
Make wraptag/break work consistently.
Permit multiple fields to be comma-separated, and combined with break/wraptag/class/breakclass etc
Somehow permit label and value to be output with a single tag, with perhaps a separator/break/wraptag between/around them?

jakob · 2025-09-27 14:23:27

Vienuolis wrote #340671:

Now I am faced with the question of how to adapt Textpattern for multilingual publishing. Could CF be of any help in this matter?

While there are still few versions of foreign-language webpages, I intend to keep them in the same database, the same domain, but create separate sections and categories for each language and link them together manually.

This is not strictly related to txp5, but maybe this thread is of interest to you. It outlines a way of doing a multilingual site with differently named sections (i.e. clothes, kleidung, vetements) using custom fields and/or a form with a set of named variables to reciprocally interlink articles and sections (and categories if you want). Demoncleaner has a little plugin that helps make the manual interlinking a little more comfortable, as well as a related / alternative concept for multilingual sites. If you prefer having the language prefix in the url, e.g. /en/…, /lt/…, /fi/…, I also have a little unpublished plugin for stashing the prefix in a variable and letting Textpattern deal with the rest of url as usual.

If you’re interested or want to outline your suggestion, please open a separate thread so that this one stays on-topic.

jakob · 2025-09-27 15:18:36

Woah, a lot has happened in this thread, and I’m not sure if I’ve followed all its meanders and implications, but …

… if the concept of the entity were to represent more than merely a custom-field grouping (i.e. more than Stef’s illustration with restaurants and dishes) but could become an own content-type representing an admin-definable collection of core + custom fields (optionally?) with its own Contents › Entity menu item, then you bypass the whole issue of having two steps before writing / New article buttons with type-dropdowns / field-switching in the UI based on dropdown choices, or extra filters in the article list view, because the list and edit panels would be separate for each content-type, just as they are now for articles, images, files and links. I suppose that does mean there is still a “choice” of content-type to be made before starting to write, but we already do that quite naturally for images, files and links. And admin users could choose their start panel, so that you could still have that “Just write” experience if you want it.

The existing articles, images, files, links would simply be the basis/standard configuration for each type. People upgrading to txp5 would get this when upgrading, so there would be continuity. You could continue to use Textpattern just as you do now, but people who, for example, would like a WP-style distinction between pages and posts could make two text-type entries just to separate concerns even if in terms of content they are mostly identical, while others could split out field collections into tailored entry panels, e.g. with simpler subsets of fields, e.g. sliders, tickers, testimonials, galleries, while others could go all out and make detailed panels for more complex entities such as events, or item profiles with their own specific datasets.

I’m not sure how these tie to url schemes. Maybe, if content types have section and category fields, then they adhere to those, and if they don’t they either have a custom url-scheme (as Oleg hinted at) or are pageless and you bring them in them via your page templates and forms – as we do now with images, file_list and linklist.

The other thing that I imagine follows from this is that there may be a need for a more universal tag, for arguments sake perhaps txp:items and txp:items_custom where article_custom is just items_custom type="article" (or entity="article").

jakob · 2025-09-27 15:30:08

etc wrote #340661:

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.

I’m (personally) most interested in fields whose options are dynamically populated by articles from another section (or content-type), or a subset thereof. The intention is to create relationships between articles. In glz_cf you can specify a script filename (a simple standalone php file) that you can use to make your own form input populated by an SQL query. This could be a multi-select, a text-input, a collection of checkboxes, etc. You can optionally beef these up yourself using javascript into tag choosers, sortable multi-select choosers, etc, input/search comboboxes etc.

In short, that sounds like it would be covered by your SQL query option combined with the choice of input field type … but maybe other people have done other clever stuff with glz_cf’s script option.

Bloke · 2025-09-27 17:02:50

jakob wrote #340702:

could become an own content-type representing an admin-definable collection of core + custom fields (optionally?) with its own Contents › Entity menu item

This, yes.

Adi_matrix adds new content grids to the Content menu so there’s no reason we couldn’t do that. Depends on the number of types, I guess.

I can see a scenario where the Entity panel is either a separate panel or a pair of tabs on the CF panel. And it has extra options like:

Include on Content menu
URL scheme

That gives you the option to bring some or all of your types unto 1st class citizens for 1-ckixk access from the menu. And I feel a natural use of URL scheme might be to insert the content type URL between section and article title. Other permlink schemes, not sure…

Bloke · 2025-09-27 17:34:45

Pretty sure all of the UI class elements have callbacks on them so that helps to tweak stuff at the last minute, and panel level callbacks allow things to hook in at content creation time to offer different workflows. The Write panel is going to be the last to get this because it’s more complicated than the tablular view panels.

Can’t recall if there’s a callback per CF. Pretty sure I added a few, but if there needs to be more, we can add them to allow programmatic manipulation by plugins before each field is rendered.

etc · 2025-09-27 20:08:05

Bloke wrote #340696:

I know it’s early days for tags …

Yep, we don’t even know yet what all possible cfs types (scalar, array, object) will be.

Re label, it is married with labeltag, so use, for example, labeltag="<+>:" to output Location: london.

etc · 2025-09-27 20:14:22

jakob wrote #340704:

I’m (personally) most interested in fields whose options are dynamically populated by articles from another section (or content-type), or a subset thereof.
…
In short, that sounds like it would be covered by your SQL query option combined with the choice of input field type … but maybe other people have done other clever stuff with glz_cf’s script option.

Ah, ok, that corresponds to options in the current cf model. Well, allowing sql queries here sounds interesting, but I would avoid injecting php via eval(). As Stef says, we’d rather leave it with plugins via callbacks.

etc · 2025-09-27 20:29:46

etc wrote #340694:

it should actually be easy to switch the entity on Write tab too. What if we output all available cfs inputs, but hide those that do not belong to the currently chosen entity via some css magic?

Tested, it works, but my css-fu does not go beyond generating a rule per cf:

#article-type-select:has(option[data-fs~="1"]:checked) ~ div.edit-custom-1,
#article-type-select:has(option[data-fs~="2"]:checked) ~ div.edit-custom-2
/* and so on */ {
    display: initial;
}

Can one of our css gurus imagine a markup that reveals all div.edit-custom-n where n belong to some attribute of the currently selected option?

Bloke · 2025-09-27 20:40:20

Are there any downsides to adding a section column to all our remaining base content types? That promotes them all to be able to use the URL, and aligns everything neatly. Some disambiguation may be required for ?id, perhaps.

And while we’re at it, how about we add an auto_increment id to the txp_section table so we can, somewhat paradoxically, add custom fields to sections.

Bloke · 2025-09-27 21:52:47

etc wrote #340720:

Tested, it works… Can one of our css gurus imagine a markup that reveals all div.edit-custom-n where n belong to some attribute of the currently selected option?

Nice! Will it work if the fields are dotted around the page, i.e. not in a contiguous ‘custom fields’ block?

Textpattern CMS support forum

#31 2025-09-27 10:59:25

Re: [RFC] TXP5 Custom Fields Management

Vienuolis wrote #340687:

#32 2025-09-27 11:09:00

Re: [RFC] TXP5 Custom Fields Management

#33 2025-09-27 11:54:26

Re: [RFC] TXP5 Custom Fields Management

phiw13 wrote #340690:

Bloke wrote #340692:

#34 2025-09-27 12:07:57

Re: [RFC] TXP5 Custom Fields Management

#35 2025-09-27 12:21:13

Re: [RFC] TXP5 Custom Fields Management

#36 2025-09-27 14:23:27

Re: [RFC] TXP5 Custom Fields Management

Vienuolis wrote #340671:

#37 2025-09-27 15:18:36

Re: [RFC] TXP5 Custom Fields Management

#38 2025-09-27 15:30:08

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340661:

#39 2025-09-27 17:02:50

Re: [RFC] TXP5 Custom Fields Management

jakob wrote #340702:

#40 2025-09-27 17:34:45

Re: [RFC] TXP5 Custom Fields Management

#41 2025-09-27 20:08:05

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340696:

#42 2025-09-27 20:14:22

Re: [RFC] TXP5 Custom Fields Management

jakob wrote #340704:

#43 2025-09-27 20:29:46

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340694:

#44 2025-09-27 20:40:20

Re: [RFC] TXP5 Custom Fields Management

#45 2025-09-27 21:52:47

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340720:

Board footer