Custom Field Types in Admin

[bitstarr]

I have a non gpm news (blog) plugin which is based on flex objects (for reasons of better overview as with the classic pages way).

I use a custom field type to show a checkmark if a value is set in the list in the admin. In the edit its a datetime field.
This is not working anymore in admin2.

Have a look into the code:

list:
https://github.com/bitstarr/grav-plugin-news/blob/main/blueprints/flex-objects/news.yaml#L57

edit/form:
https://github.com/bitstarr/grav-plugin-news/blob/main/blueprints/flex-objects/news.yaml#L233

admin specific custom filed template:
https://github.com/bitstarr/grav-plugin-news/blob/main/admin/templates/forms/fields/news-isset/edit_list.html.twig
https://github.com/bitstarr/grav-plugin-news/tree/main/admin/templates/forms/fields/news-datetime

They also do not render correctly in the edit view (note that the date fields shoul also be togglable).

This is surely a quite specific issue of my way hacking into the interface of the old admin.
But maybe it also illustrates use cases that can be considered for admin2 and flex-object plugin improvements.

[rhukster]

Thanks Sebastian, this is a genuinely useful report. You called it "a quite specific issue of my way hacking into the old admin", but after reading your code I think you're being too hard on yourself. There are three separate things here and two of them are on us.

First the architecture bit, so the rest makes sense. The classic admin builds forms server-side with Twig, so dropping a template into admin/templates/forms/fields/ was enough to define a field type. Admin2 is a SvelteKit app that renders fields in the browser from blueprint JSON served by the API. It never sees your Twig. So a Twig-defined field type can't work there, and Admin2 falls back to showing the raw value in a textarea with a type badge, which is your third screenshot.

Your datetime fields. Good news, you don't need to port anything. Your news-datetime.html.twig just extends core's datetime template, and your own comment explains why you made it: so you could attach different list output without stepping on other plugins. Admin2 has a native datetime field, so changing type: news-datetime to type: datetime in your form section will render properly right away.

If you do want a real custom field type in Admin2 later, that mechanism exists and is documented. You ship a small web component at your-plugin/admin-next/fields/{type}.js and the filename becomes the blueprint type name. Nothing to wire up, it's discovered from disk. The guide is at https://learn.getgrav.org/20/api/developer-guide#custom-admin-fields-via-web-components, and there's a short working example inside flex-objects itself at admin-next/fields/save-redirect.js.

The togglable dates. You were right, and this turned out to be a genuine bug rather than a limitation. toggleable only rendered its checkbox for fields sitting directly inside a section. Yours are nested inside columns > column, and there Admin2 was silently dropping the toggle. That hit publish_date, unpublish_date and hero_source in your blueprint, and it would hit anyone using toggleable inside columns. Fixed in 2.0.15, and it works inside list items now too, where it was equally broken. It's independent of the datetime change, so switching to type: datetime wouldn't have brought the toggle back on its own.

Your list columns. This one's a real gap and I want to be straight with you about it. Both news-isset and news-array only ship an edit_list.html.twig, so they exist purely to customise a column in the list table. The classic flex list used to resolve forms/fields/{type}/edit_list.html.twig per column, and that went away with the old Vue list frontend. Admin2's flex list has a fixed set of column renderers and no way for a plugin to add one, so there's no replacement today. Custom field types don't cover it either, since they only apply to the edit form.

The nearest thing right now is setting the list column to type: toggle, but I saw your comment about the red X reading like an error when the value is simply absent, and Admin2 does the same green check and red X, so that's not really what you want.

We already built this exact contract for the Users list, where a plugin declares extra columns with a fixed set of formatters, including a boolean one. Extending that to flex lists is the obvious fix and your case is a good argument for it. I'm leaving this open to track that part.

So: one thing you can fix in a second, one bug on us, and one honest gap that your report is good evidence for. Appreciate you writing it up with the code links.