Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [RFC] TXP5 Custom Fields Management
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").
TXP Builders – finely-crafted code, design and txp
Offline
Re: [RFC] TXP5 Custom Fields Management
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.
TXP Builders – finely-crafted code, design and txp
Offline
Re: [RFC] TXP5 Custom Fields Management
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…
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: [RFC] TXP5 Custom Fields Management
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Offline
Re: [RFC] TXP5 Custom Fields Management
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.
Offline
Re: [RFC] TXP5 Custom Fields Management
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?
Offline
Re: [RFC] TXP5 Custom Fields Management
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340720:
Tested, it works… Can one of our css gurus imagine a markup that reveals all
div.edit-custom-nwherenbelong 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?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: [RFC] TXP5 Custom Fields Management
etc wrote #340720:
Tested, it works, but my css-fu does not go beyond generating a rule per cf … Can one of our css gurus imagine a markup that reveals all
div.edit-custom-nwherenbelong to some attribute of the currently selected option?
I don’t think there’s such an option. I think you’re limited to “starts with…”, “contains”, “ends with” type selectors (see MDN), and using some data-attributes in the content part of ::before and ::after pseudo selectors. Maybe someone else knows more…
Also, with a setup like that, your custom fields would have to be a descendent or sibling of the chooser, so couldn’t easily be strewn around the page without using js to set a class or data attribute on a higher-level container. I’m not sure, but where the presence of fields on a page can be changed through the UI, I’m guessing you’d also need to set aria-attributes for accessibility, so js would probably be unavoidable.
TXP Builders – finely-crafted code, design and txp
Offline
Re: [RFC] TXP5 Custom Fields Management
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.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: [RFC] TXP5 Custom Fields Management
Bloke wrote #340731:
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.
Skimming Olegs code, and assuming I understand what he’s trying, I would suggest the same, either directly to the CF or if they are part of a group, on the group container.
Some JS is possibly needed (aria attributes maybe? Not sure what you will end up with).
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
phiw13 on Codeberg
Offline