Custom Field Groups

ironmangary · 2022-11-23 01:01:28

I read somewhere that a more robust custom fields system is being created for the next release. Along those lines, if you’re going to allow an infinite or even a large number of custom fields, I think it would be nice to be able to group fields so that you don’t have to see all custom fields for every article you create.

Using my own wrestling site as an example, each wrestler profile uses several custom fields, such as “Tag-Team,” “Manager,” Wins,” “Losses,” and “Draws.” Each event uses a completely different list of fields, such as “Venue” and “Broadcasters.” When I’m writing up an event, I have to scroll past all of the wrestler related fields to get to the ones for events, etc. It would be nice, if, under Custom Fields,” instead of displaying or not displaying all fields, you can choose your groups; i.e. one group named “Wrestler” and another named “Events.”

phiw13 · 2022-11-23 02:22:06

You are not the only one who wishes for a way to group custom fields :-)

That idea has been suggested before, this post and the following ones have already discussed it – along the lines of what you suggest above.

Bloke · 2022-11-23 09:38:09

Custom fields can be assigned a group (a family or collection, I forget which naming convention has been adopted) but there is nothing that core does to enforce or otherwise act on that information, besides sorting.

It will be down to plugins (probably) or hooks to provide context. So if you wish to use the collection to tie custom fields to sections then a plugin could hide ones that don’t match when you change section. Or if you want to group them under their own twisty based on group, a plugin could do that instead.

There’s no sane way that core could decide what to do with them, since implementations are so varied.

P.S. “next version” is fluid and subject to change.

Myusername · 2022-11-23 15:24:27

I think custom field groups are extremely useful. And attaching them to sections would be the coolest thing here.

I think when creating a section, there could be an option of which groups of custom fields would be available for that section. That’s what happens in expressionengine and I love how the custom fields work there.

etc · 2022-11-23 21:05:47

Myusername wrote #334189:

I think custom field groups are extremely useful. And attaching them to sections would be the coolest thing here.

While tempting, this could be a bit restrictive in txp case (I don’t know what EE sections are). Sections in txp are more about presentation (theme, search, etc) than content. You might want to have a car section, but thermal and electric cars would have slightly different cf sets (think of the fuel tank). Splitting them into two sections would, for example, complicate the search. So I agree with Stef:

Bloke wrote #334188:

It will be down to plugins (probably) or hooks to provide context. So if you wish to use the collection to tie custom fields to sections then a plugin could hide ones that don’t match when you change section.

However, core should find a way not only to hide, but to completely remove cf ‘unset’ by plugins, to save db space. I don’t remember what happens if an article does not send a cf data on save: is some empty value written to the db or nothing at all? Of course, there are some non-evident choices to do, as Stef has outlined here.

Bloke · 2022-11-24 07:10:20

etc wrote #334190:

I don’t remember what happens if an article does not send a cf data on save: is some empty value written to the db or nothing at all?

If the CF data is not in the payload because you’ve changed something (e.g. a field that once held data is hidden because someone changed a section) then as far as I’m aware, nothing is sent for that field.

In theory that would mean whatever was stored in the previous field remains, but that seems silly. It needs testing because it should blank out anything that isn’t explicitly set. We know which fields are in scope at save time, so this seems reasonable.

etc · 2022-11-24 10:06:28

Now that CF are stored in separate tables, it should be possible to attach to every article an individual cf collection, not only hiding the irrelevant cf, but simply not storing them at all. An electric car does not need a fuel tank capacity cf, so why creating a blank db record?

I would even move some core fields to cf collections. Not every article needs keywords, article images and so on. It implies the corresponding tags deprecation, but I wouldn’t expect a seamless switch to cf branch anyway.

Myusername · 2022-11-24 10:45:03

etc wrote #334190:

While tempting, this could be a bit restrictive in txp case (I don’t know what EE sections are). Sections in txp are more about presentation (theme, search, etc) than content. You might want to have a car section, but thermal and electric cars would have slightly different cf sets (think of the fuel tank). Splitting them into two sections would, for example, complicate the search.

In this case, you can simply put all the custom fields you need, be it thermal or electric cars, in the same group. So it doesn’t matter if the car is thermal or electric, all the options will be there, like it works now (but still, only the cf you choose). Even so, it will have more organization and flexibility, after all, the way it works today, in addition to the custom fields for cars, there are also custom fields for bicycles, motorcycles and trucks, are all there, but you will never use them in car section. I strongly recommend that you take a closer look at EE, it might open your mind to new ideas.

Bloke · 2022-11-24 11:51:16

EE has been on my list to look at for ages but as it was traditionally paid-for sw, I never did.

I’m reluctant to enforce a section to CF mapping. For starters, articles are the only content type in Txp that are section-aware. And custom fields will work across all content types.

Secondly, there are many more ways to use custom field groups than to limit their choice by section. It implies you would have to tie the section name to the custom field group name somehow. While you might want to do that (e.g. by calling them the same names) it puts a burden on the system and the person entering data to know this and implement it. Especially if someone adds a new section and doesn’t create a corresponding CF group.

Plus it adds JavaScript overhead to the Write panel. And what if you don’t want all sections to respond to changes?

I’d much rather leave the capability there and have plugins fill the gaps. The custom fields store is, as Oleg implies, more than just custom fields. It could become the de facto storage location for all core and custom metadata. There’s a reason I named the tables txp_meta_* 😁😎

As far as I’m aware, nobody in CMS land has attempted to store data by the most appropriate type based on its intended usage, to make storage as efficient and fast as possible.

Thinking back, I do recall now that if you change a field and it goes out of scope, when you save it should remove the data. Pretty sure it iterates over all fields of the corresponding content type and blanks out anything that’s not in the payload. Would have to test to be sure.

etc · 2022-11-24 13:27:22

Myusername wrote #334196:

In this case, you can simply put all the custom fields you need, be it thermal or electric cars, in the same group. So it doesn’t matter if the car is thermal or electric, all the options will be there, like it works now (but still, only the cf you choose).

That’s exactly what I would like to avoid. There is no sense to store db records that would never be used anyway.

Even so, it will have more organization and flexibility, after all, the way it works today, in addition to the custom fields for cars, there are also custom fields for bicycles, motorcycles and trucks, are all there, but you will never use them in car section. I strongly recommend that you take a closer look at EE, it might open your mind to new ideas.

I hear you, just saying that sections are not the best choice for that. We need another (new?) entity to attach cf groups to articles (images, files, …)

Bloke · 2022-11-24 16:41:55

etc wrote #334202:

There is no sense to store db records that would never be used anyway.

Definitely. There’s a lot of work gone into the underlying CF architecture to ensure that the field storage is the most efficient type for representing the data. So the ethos is that only the data that is needed is stored. And if it doesn’t work that way, it should.

Destry · 2024-01-10 13:53:02

etc wrote #334194:

I would even move some core fields to cf collections. Not every article needs keywords, article images and so on.

+1

Textpattern CMS

Textpattern CMS support forum

#1 2022-11-23 01:01:28