[RFC] TXP5 Custom Fields Management

Bloke · 2025-09-29 11:21:49

A content type builder works for me, if it can be made usable and fast.

Nothing to stop it being part of the Entity definition panel, maybe. Although we don’t necessarily know the fields at that point, so it mght be better done separately.

In terms of output format, can I tentatively make a suggestion to store layouts as *whispers* XML? Makes it easier to offer import / export of layouts in a semi-human and machine usable format.

etc · 2025-09-29 11:31:59

Unless I misunderstand the idea, having to create a layout for every entity is not what I’d call “just write”. And what if you need to add/remove a cf to/from multiple entities via some multi-edit widget? And good luck for the builder implementation.

There will be an entity definition panel, but going beyond the sort order makes me think of.. other cms.

Bloke · 2025-09-29 12:37:59

etc wrote #340759:

There will be an entity definition panel, but going beyond the sort order makes me think of.. other cms.

Haha yeah. If it’s too much of an overhead then I’m of the same opinion.

Bloke · 2025-09-29 15:13:40

How about we leave designing panel layouts to plugin/admin theme authors? Core will make a best attempt at putting the controls in the most relevant position – and perhaps we can provide some simple mechanisms or naming conventions to nudge it one way or another, but that’s it.

We provide hooks, and any fine-grained control is down to an external entity to massage the layout.

giz · 2025-09-29 16:17:09

Bloke wrote #340762:

How about we leave designing panel layouts to plugin/admin theme authors?

👍

Bloke · Yesterday 22:13:57

So I’ve had a stab at realigning the _update scripts in the _to_5.0.0.php with Oleg’s latest table changes. Removed a few columns and whatnot, added the missing tables, and populated what I could.

I haven’t quite got my head round what the txp_entity_delta table is yet, so it’s currently unpopulated on upgrade. Any info to guide me would be most welcome. I suspect it links to the values table so we may need to split that info when migrating data from the textpattern custom_N columns to the new tables on initial upgrade.

If I’ve screwed up the data transfer, please feel free to alter what I’ve done.

I’ve created an entity type for all base types by reading the data from ContentType->getTableColumnMap(). That way, we know the IDs of the “core” content types and anything higher is custom-defined. Using the magic number in the code for the entity ID feels kind of kludgy, imo. I think it’d be more readable to use the name, and that also guards against those siutations where someone might start with a ‘zero’ theme that only has custom entity types in it, or only populates one or two of the core types.

Happy to revisit this and only create ‘article’ out of the box.

Last edited by Bloke (Yesterday 22:17:47)

Bloke · Yesterday 22:41:25

Now we have core panels for entity type definitions, we have the opportunity to register “Entity shortcuts” that feed into Textpattern’s Just Write philosophy. Currently, we have one entity shortcut built in: Write which is very, very hard-coded into core.

What we could do is add a database field (similar to the way we handle “On Front page” and “Syndicate?” for Sections) called “Direct editing” (for example). If you Set that to ‘Yes’, your custom entity label could appear as a first-class citizen on the Content menu, which saves you a few clicks having to go to the content type ‘list’ panel, select the entity type and click ‘New’.

However:

What happens if the number of entities you want to put on there grows large?
Should we allow other core content types there? That creates problems for things like Users and Sections, because they have menu entries in other parts of the system, which could get confusing unless we allow people to rename how the core types appear on the Content menu.
What is an entity type based on ‘Section’ or ‘User’ anyway?
Do we need a ‘Media’ content type (so Images (and Files?) become an entity type based on Media, and people can add their own for Audio, Video, …)

The other option, instead of a column in the table, is a per-user pref. Perhaps a dropdown of all entity types and you multi-select the ones you want to have direct access from the Content (or whatever) menu. That seems more flexible, imo, as not everyone’s workflow will need to be dictated by an admin.

Bloke · Yesterday 22:42:43

Side note: the moment an entity is created, its label becomes “fixed” in the current language. Could we hook the labels up to the txp_lang table instead, so they change if the admin language is switched?

phiw13 · Today 04:55:12

Bloke wrote #340887:

Side note: the moment an entity is created, its label becomes “fixed” in the current language. Could we hook the labels up to the txp_lang table instead, so they change if the admin language is switched?

I would certainly hope so. Imagine I have a site, main language is Japanese. The entity label is thus set in Japanese, kanji or hiragana. Then the site expands and I get authors from say Malaysia, user language Malay. They’ll sure appreciate seeing those entity labels in their language.

–^–
No particular opinion on your two previous post as I still have trouble processing exactly where you’re going with those entities.

etc · Today 07:57:13

Bloke wrote #340885:

I haven’t quite got my head round what the txp_entity_delta table is yet, so it’s currently unpopulated on upgrade.

This (hopefully small) table contains individual ad hoc deviations from entities and is empty on update. One will be able to write an article with a predefined fields collection (i.e. entity), even empty, and then add or remove some fields individually, for this article only.

Using the magic number in the code for the entity ID feels kind of kludgy, imo. I think it’d be more readable to use the name, and that also guards against those siutations where someone might start with a ‘zero’ theme that only has custom entity types in it, or only populates one or two of the core types.

We use magic numbers not for the entities, but the supporting tables (1 = textpattern, 2 = txp_image etc). I currently don’t see how these core tables might be removable, but plugins will (should) be able to register new ones. Not yet very clear.

What we could do is add a database field (similar to the way we handle “On Front page” and “Syndicate?” for Sections) called “Direct editing” (for example).

Yes, that’s what I thought, but I’m not sure entities should be used for classification (though they might be). By their nature, they are just custom fields collections.

Side note: the moment an entity is created, its label becomes “fixed” in the current language. Could we hook the labels up to the txp_lang table instead, so they change if the admin language is switched?

phiw13 wrote #340889:

I would certainly hope so. Imagine I have a site, main language is Japanese. The entity label is thus set in Japanese, kanji or hiragana. Then the site expands and I get authors from say Malaysia, user language Malay. They’ll sure appreciate seeing those entity labels in their language.

Are labels/translations necessary at all? IIRC, we don’t have them for sections, categories and so on, and nobody complains. It’s a nightmare to maintain.

Bloke · Today 08:27:16

etc wrote #340890:

This (hopefully small) table contains individual ad hoc deviations from entities

Gotcha. Thank you.

We use magic numbers not for the entities, but the supporting tables (1 = textpattern, 2 = txp_image etc).

Okay. I was mistakenly thinking it was for the content types themselves. Thanks for the clarification. As long as these are set on upgrade and baked in and cannot be changed or deleted, the magic numbers are fine. But if we decide to allow core types to be removed or altered, that’s a different scenario and I then think the keys / names may be a better hook.

Yes, that’s what I thought, but I’m not sure entities should be used for classification

Well we allow people to fire up the Write panel with a set of fields associated with an entity(?). Or does the new fieldsets table handle the linking between content type and CFs? I could do with a little diagram or something that sets out how these things are interrelated cos my head’s a bit woolly on it at the moment.

Anyway – whether the entity or the fieldset defines how the Write panel differs, it may still be beneficial to put a mechanism in place to allow people to expose them as direct access links from a menu. It saves three clicks via the Articles panel.

Are labels/translations necessary at all? IIRC, we don’t have them for sections, categories and so on

We don’t at the moment. But we will when the multilingual interface is eventually rolled out. Just trying to get ahead of the curve.

We’ll eventually have a Section name (its key: which won’t change) and then its Title will be editable in any one of a number of languages you choose to expose on your front end. Essentially, all tables get a “lang” column (in the case of Sections, it will probably be done as a foreign key in a link table to avoid duplication of section data, which would make URL handling difficult).

I’d like us to keep multilingual content editing at the back of our minds while developing CFs because they seem to fit fairly naturally into “write new content with these fields in them, oh and this instance is in Russian, while this other instance carries the same content in English”.

Imagine a Language drop-down on the Write panel that flicks between the same set of CFs and core fields, but stores each set of content in a new row with a “lang” designator column.

So, kind of yes, entity labels may well become multilingual if they’re ever exposed as direct-access links from menus. But otherwise, well, yeah, maybe they’re not super important to be labelled in other languages.

Haven’t thought it all through yet, and it will probably be determined by how the various entities, fieldsets and deltas fit together.

colak · Today 08:37:15

Bloke wrote #340891:

We’ll eventually have a Section name (its key: which won’t change) and then its Title will be editable in any one of a number of languages you choose to expose on your front end. Essentially, all tables get a “lang” column (in the case of Sections, it will probably be done as a foreign key in a link table to avoid duplication of section data, which would make URL handling difficult).

I’d like us to keep multilingual content editing at the back of our minds while developing CFs because they seem to fit fairly naturally into “write new content with these fields in them, oh and this instance is in Russian, while this other instance carries the same content in English”.

Imagine a Language drop-down on the Write panel that flicks between the same set of CFs and core fields, but stores each set of content in a new row with a “lang” designator column.

So, kind of yes, entity labels may well become multilingual if they’re ever exposed as direct-access links from menus. But otherwise, well, yeah, maybe they’re not super important to be labelled in other languages.

Haven’t thought it all through yet, and it will probably be determined by how the various entities, fieldsets and deltas fit together.

I’m salivating:)

Textpattern CMS

Textpattern CMS support forum

#61 2025-09-29 11:21:49

Re: [RFC] TXP5 Custom Fields Management

#62 2025-09-29 11:31:59

Re: [RFC] TXP5 Custom Fields Management

#63 2025-09-29 12:37:59

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340759:

#64 2025-09-29 15:13:40

Re: [RFC] TXP5 Custom Fields Management

#65 2025-09-29 16:17:09

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340762:

#66 Yesterday 22:13:57

Re: [RFC] TXP5 Custom Fields Management

#67 Yesterday 22:41:25

Re: [RFC] TXP5 Custom Fields Management

#68 Yesterday 22:42:43

Re: [RFC] TXP5 Custom Fields Management

#69 Today 04:55:12

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340887:

#70 Today 07:57:13

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340885:

phiw13 wrote #340889:

#71 Today 08:27:16

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340890:

#72 Today 08:37:15

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340891:

Board footer