[RFC] TXP5 Custom Fields Management

Bloke · 2025-09-27 06:40:16

Yes, ProcessWire’s good. We’ve lost a few prominent Txp folk to them. I played with it a while ago. Might be worth a revisit in case anything’s improved

My only reservation was that it was very configuration-heavy and it felt a chore to set it up before I could even think about making the website do anything meaningful. But when I’d gone through the on-ramp pain, it did work very well.

Definitely a few ideas to steal, but also some to avoid. And sprinkle some Txp convention goodness to keep content the primary focus still.

colak · 2025-09-27 08:11:55

wet wrote #340684:

I wonder whether someone is aware of this exhibit of prior art, which I consider very up to the task of object oriented content classes?

Really like the multi-language part!

Vienuolis · 2025-09-27 09:02:00

Bloke wrote #340675:

I’ve put an absolute f-tonne of work into the under-the-hood management so we can store things efficiently, natively. That makes searches faster and more flexible without horrible casting kludges, and keeps the footprint down, which aids performance. Oleg has just taken this a step further by abstracting my initial work to push content types and flexibility to the next level. It’s all looking very exciting…

Textpattern always was the best WWW publishing loom, and is going even better, thank you both, dear Stef and Oleg.

I meant it’s a two step process

I’m afraid we’ll abandon the original principle: “Just write.” Switches to some section, categories, CF sets, media types, additional TxP forms, etc. will always remain in the Write panel, won’t they? After all, we can leave to each writer the right to decide on the appropriate starting options for themselves.

For an example, I managed to come up with a template for posting urgent short messages in a news section without any metadata, even without a title (the date and other necessary attributes are provided automatically in such cases): az.on.lt/naujenos/

Bloke · 2025-09-27 09:51:43

colak wrote #340686:

Really like the multi-language part!

Yes, I could see us, uhh, paying homage to that.

phiw13 · 2025-09-27 09:55:21

From a brief look at a local install, and wome post here:

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

It is kinda obscure atm.

(and yes,

phiw13 · 2025-09-27 10:50:53

phiw13 wrote #340690:

(and yes,

Finishing the sentence that apparently got cut off

(and yes, what Julian said at the start of the thread, mostly)

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.

Textpattern CMS

Textpattern CMS support forum

#25 2025-09-27 06:40:16

Re: [RFC] TXP5 Custom Fields Management

#26 2025-09-27 08:11:55

Re: [RFC] TXP5 Custom Fields Management

wet wrote #340684:

#27 2025-09-27 09:02:00

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340675:

#28 2025-09-27 09:51:43

Re: [RFC] TXP5 Custom Fields Management

colak wrote #340686:

#29 2025-09-27 09:55:21

Re: [RFC] TXP5 Custom Fields Management

#30 2025-09-27 10:50:53

Re: [RFC] TXP5 Custom Fields Management

phiw13 wrote #340690:

#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:

Board footer