[RFC] TXP5 Custom Fields Management

etc · 2025-09-28 08:52:05

Bloke wrote #340721:

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.

Would all content types share sections? That looks confusing.

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.

This, yep.

What about adding a class name to all the fields with the space-separated name(s) of the Entity to which they relate? Then you can just hide everything that doesn’t match the drop-down.

Great idea, though it would require a rule per entity? I hoped some css magic could reduce the set to one rule, but it looks impossible. Anyway, I’m not convinced any more that retrieving all cfs is a good idea — it scales badly. If we decide to keep the entity switcher on Write tab (which I’m not sure, neither), js looks unavoidable.

jakob wrote #340730:

I don’t think there’s such an option. I think you’re limited to “starts with…”, “contains”, “ends with” type selectors

Contains word is what I use here.

Bloke · 2025-09-28 09:14:44

etc wrote #340735:

Would all content types share sections? That looks confusing.

Well, I guess. But it’s no more confusing than front-page, category, author and search all sharing section="". Conditionals can differentiate, perhaps if we introduce ?fid, ?lid and ?pid variables to help with <txp:if_individual type="article|image|file|link|entity"> etc.

The four contexts already exist, albeit they’re tied to the URL already, without section, so we could maybe even keep that concept:

example.org/section/id <= assumes article
example.org/section/entity-type/id <= for custom entities
example.org/section/image/id <= image context
example.org/section/file/id <= file context
example.org/section/link/id <= link context

Without the id we know we’re in a ‘list’ context inside the given content/entity type.

As I say, other permlink schemes might be more challenging.

Not married to the idea. Just wondering out loud if it might be useful. Alternatives welcome.

etc · 2025-09-28 09:27:07

Would not this imply that every Page needs to take into account all content types, since it is accessible for every flavour?

Bloke · 2025-09-28 09:58:37

etc wrote #340738:

Would not this imply that every Page needs to take into account all content types, since it is accessible for every flavour?

If you’re using them, yes. But if you’re not intending to expose them to the URL scheme in your page templates, you can ignore them, the same way you can ignore if_author, if_category, and if_search in your default page template if you’re not using those features.

So, for example, if you’re using images and files as they are today to serve as part of a page, you just handle articles as normal. If you add a new content type and want to use it to hold stuff that you pull in via article_custom, you don’t need to bother as it’s not exposed to the URL. But if you decide to show that content type to the world and allow them to browse it, you add a conditional to handle it to the page template.

Or maybe I’m missing something. I’ve not thought it through in detail.

Edit: Maybe page templates could optionally be extended to be cognisant of entity so you could create a page specifically for a section+entity combo. That saves littering conditional tags.

Last edited by Bloke (2025-09-28 10:02:44)

etc · 2025-09-28 10:09:59

Sections are often publicly exposed, via <txp:section_list /> menus etc. So you’d need to exclude all purely ‘image’ sections etc from ‘articles’ menus and vice versa. Sharing sections among content types looks more annoying than useful for me.

Bloke · 2025-09-28 10:12:34

Ah yes, true. Okay. Scratch that. Any other ideas?

giz · 2025-09-28 19:23:02

One thing to consider in the layout of elements in TXP5 is that css is excellent in repositioning elements in the interface — as long as the html structure is relatively flat.

Currently Hive wraps containers around core groupings of fields eg.

div.txp-layout-4col-3span
- h1.txp-heading
- div#main_content
  - div#pane-text.text
    - div.txp-form-field.title
    - div.author
    - div.txp-form-field.txp-form-field-textarea.body
    - div.txp-form-field.txp-form-field-textarea.excerpt
  - div.txp-dialog
div.txp-layout-4col-alt
- div#txp-article-actions.txp-save-zone
- div#supporting_content
  - etc.
  - section#txp-image-group.txp-details
  - section#txp-custom-field-group.txp-details
  - section#txp-recent-group.txp-details

This means that css can only directly relocate a node within its siblings. To move a custom field (say into #txp-image-group), is possible but more involved than it need be through using display: contents; on both parent containers.

On the other hand if we go extreme with:

div.txp-layout
- h1.txp-heading.pane-text
- div.txp-form-field.title.pane-text
- div.author.pane-text
- div.txp-form-field.txp-form-field-textarea.body.pane-text
- div.txp-form-field.txp-form-field-textarea.excerpt.pane-text
- div.txp-dialog.pane-text
- div#txp-article-actions.txp-save-zone.supporting
- etc.supporting
- section#txp-image-group.txp-details.supporting
- div.txp-form-field.article-image.supporting
- div.txp-form-field custom-field custom-1.supporting
- div.txp-form-field custom-field custom-2.supporting
- etc.supporting
- section#txp-recent-group.txp-details.supporting

The layout of the grid could notionally be:

.txp-layout {
  display: grid;
  grid-template-columns: 1fr 20%;
  gap: var(--gap);
}

.supporting {
  grid-column-start: 2;
}

…but a problem rears its head; textareas can be any height depending on their contents, but we’re in a grid so adjacent .supporting nodes will share the row height, meaning there will be a gap to the .supporting node underneath. A workaround is to set textareas to @grid-row: span {n}, but is less than ideal unless there is a ‘hook’ for the css to discriminate on the number of row-spans to apply.

A middle ground would be to maintain .pane-text and .supporting as container divs, which gets us half-way there.

The inclusion of toggle-able panels for functional groupings would break in both these scenarios, but there is food for thought…

etc · 2025-09-28 20:31:38

I wouldn’t flatten everything, but cfs should go into the same area that body and excerpt, since they play the same role. I’m not even sure they should be wrapped in a foldable section any more, since all cfs become ‘pertinent’ for the given entity type.

Bloke · 2025-09-28 23:05:33

giz wrote #340746:

One thing to consider in the layout of elements in TXP5 is that css is excellent in repositioning elements in the interface — as long as the html structure is relatively flat.

etc wrote #340747:

I wouldn’t flatten everything, but cfs should go into the same area that body and excerpt, since they play the same role.

All good points.

How about, at the risk of “configuration” we utilise the (now redundant, due to Entities) “family” column. We can call it what we like – I wanted to use ‘group’ but it’s a MySQL reserved word. But essentially it allows you to group fields into logical sets.

The original idea was that each group got its own twisty box. Whether we go with twisties or not, having the ability to specify that fields belong together – and perhaps in some sort of order – helps lay them out.

So let’s say people can assign a group name to each field if they want and it’ll be collected with other fields of the same group name. Now say we introduce a convention alongside it. If you prefix your family name with txpmain. then your group appears in the excerpt/body/title area. If it is prefixed with txpaside. then it appears where they do now in the sidebar. Otherwise, without any prefix, they are just appended according to the following rules:

1. Textarea or input boxes (over a certain size?) go in the main column.
2. Everyrhing else (radios, checkbox sets, select lists, date pickers, etc) goes in the sidebar.

Haven’t thought about a way to indicate what order they should appear. Maybe we leave that to CSS.

This whole scenario is made more difficult by the fact custom fields can be shared and therefore the groupings may change for different content/entity types. That’s not easy to reconcile, so ideas welcome.

etc · 2025-09-29 08:37:43

Bloke wrote #340748:

This whole scenario is made more difficult by the fact custom fields can be shared and therefore the groupings may change for different content/entity types. That’s not easy to reconcile, so ideas welcome.

It’s rather belonging to multiple families that is difficult to handle. The entity is unique on Write tab. Otherwise, yes, that might work, and we already have a mechanism to store fold/unfold states. But I’m not sure about the main/aside separation, unless it’s only semantic, and all cfs are siblings.

Bloke · 2025-09-29 09:34:41

etc wrote #340754:

It’s rather belonging to multiple families that is difficult to handle. The entity is unique on Write tab.

Yes, that’s what I meant. It probably won’t happen, but what if you wanted your Location custom field to be in a different group, or in a different order visually on the screen, on the Write panel and the Images panel? Currently there’s no way to do that. And, further, my suggestion yesterday of using main/aside isn’t applicable to all content types. Only images and articles have a sidebar, so it’s rather useless.

I’m not sure about the main/aside separation, unless it’s only semantic, and all cfs are siblings.

That was my initial thought, yes. Just dump them in one of the main/side locations, perhaps subgrouped, and let CSS/themes/plugins position the field groups or rearrange the fields within the group.

But I dunno. There’s got to be a better way.

jakob · 2025-09-29 10:50:14

I’m probably banging on about the same thing as before, but it seems to me harder to bend the existing write panel to fit all kinds of layouts and demands than it would be to have admin-definable entry panels. Why not make the entities / content-type include a content-type designer panel where you – the admin, or certain permitted users – can determine the panel layout via a simple drag-drop interface. You could have full-width, main / aside (+reversed) container rows into which you place your core and custom fields and twisty-groups. Add a new row with a different layout if you want to comine them. That then becomes the edit panel for that content-type. Ideally, you could also say which columns you want in that content-type’s list view and default ordering criteria.

That would sidestep the need for complicated accessible custom field switching, specific css hierarchies or new flat layouts with named css-grid areas for better rearranging using css, because you can simply predefine the panel layout up front. Like Stef said, the likelihood that you’re going to switch between structurally different content-types mid-article is small. I think other CMSes do similar things. Craft CMS has a form designer for the admin end, Twill CMS and I believe others enable that through a code / json file that defines field types and their containers.
And for those who would still prefer custom-field switching within the article panel (e.g. when the content-type is structurally similar/identical but sections have different visible fields), there is still bot_wtc, or maybe we can come up with something a little more robust for in-panel switching.

Textpattern CMS

Textpattern CMS support forum

#49 2025-09-28 08:52:05

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340721:

jakob wrote #340730:

#50 2025-09-28 09:14:44

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340735:

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

Re: [RFC] TXP5 Custom Fields Management

#52 2025-09-28 09:58:37

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340738:

#53 2025-09-28 10:09:59

Re: [RFC] TXP5 Custom Fields Management

#54 2025-09-28 10:12:34

Re: [RFC] TXP5 Custom Fields Management

#55 2025-09-28 19:23:02

Re: [RFC] TXP5 Custom Fields Management

#56 2025-09-28 20:31:38

Re: [RFC] TXP5 Custom Fields Management

#57 2025-09-28 23:05:33

Re: [RFC] TXP5 Custom Fields Management

giz wrote #340746:

etc wrote #340747:

#58 2025-09-29 08:37:43

Re: [RFC] TXP5 Custom Fields Management

Bloke wrote #340748:

#59 2025-09-29 09:34:41

Re: [RFC] TXP5 Custom Fields Management

etc wrote #340754:

#60 2025-09-29 10:50:14

Re: [RFC] TXP5 Custom Fields Management

Board footer