One thing I noted is that when you choose an override from a template which isn't active, the field will not show. JLayouts only work from the active template.

Hey there,
great job with doing this!

I'm testing it and it does work correctly :) There are a couple of issues to address though:

• I noticed that you've put a "check" that hides the select input if Automatic Display is set to "No". However, you shouldn't do this, because this layout selection should (and indeed does) come into place also when you insert a field as part of a Field Group in the content with the content plugin, as described in #18162. So the select input field is always valid and doesn't need to be hidden away if Automatic Display is set to "No".

• I had my layouts in templates/your_template/html/layouts/field (which worked fine for the Content Plugin) and they were not showing up here in the select, so I think this folder is missing from the list. Yes, I know, yet another folder to add... didn't realize there were so many. Not sure why both this and templates/your_template/html/layouts/com_fields/field are used...

• Another thing, the "render" layout should probably not show up in the select list, as that equals to "Use Default". Unless by "Use Default" you mean the very default from the core which is not overriden? Because if you include an overridden render.php, then it should not be in the list. Maybe you could change the default option to "Use Default (render)"?

Also, a question, why is it that a filename cannot have an underscore? So far I've been using underscores for the filenames of my layouts manually used with the Content Plugin and they've been working normally. Not a big deal, just wondering.

Great job again!

@AndySDH please mark your Test as successfully:

• open Issue Tracker
• Login with your github-Account
• Click on blue "Test this"-Button above Authors-Picture
• mark your Test as successfully
• hit "submit test result"

@franz-wohlkoenig Sure, thanks for the guidelines! I'll be waiting for @Bakual about the fixes above and then will do that :)

because this layout selection should (and does come) into place also when you insert a field as part of a Field Group in the content with the content plugin

Ah true, didn't think of that. My though was to prevent misunderstanding when someones wants to insert a single field manually. I think then the layout doesn't apply (but haven't tested) and that could be confusing.

templates/your_template/html/layouts/field

That is then a lookup folder from JLayouts overriding mechanism itself. Looks indeed like I have to add that one as well. The com_fields one is because that is where the default layout actually is stored.

Another thing, the "render" layout should probably not show up in the select list

Yes, it should not. The "Use Default" should cover that. That was my plan. Do you have an override for that in your template (I think I didn't test that case)? Or why did it show up?

Also, a question, why is it that a filename cannot have an underscore?

Not really a technical reason. I based the formfield on the component layout one. In view layouts, we use underscore in layout files which should not appear in the select list. That allows to have "children" layouts. If you for example look at the article view, you see the default.php and a default_link.php file. The latter is a child layout of the former and doesn't appear in the article layout list.
I thought it makes sense to keep that naming convention to allow "hiding" certain layout files.

Ah true, didn't think of that. My though was to prevent misunderstanding when someones wants to insert a single field manually. I think then the layout doesn't apply (but haven't tested) and that could be confusing.

You have a point. Yeah, the layout indeed does not apply when you insert a single field manually. Maybe for clarity we could rename the option to "Automatic Layout", and in the option description, change it to "Choose an alternate layout to be used with Automatic Display or as part of a Field Group."

Unless... we want to actually make it work also for when inserting a single field manually? (if that is even possible). This way, the option could act as "Default/Base Layout", which is always used for that field unless otherwise overridden in the single field via content plugin.

That is then a lookup folder from JLayouts overriding mechanism itself. Looks indeed like I have to add that one as well. The com_fields one is because that is where the default layout actually is stored.

Yeah, figured so... One more folder to add, damn! Haha.

Yes, it should not. The "Use Default" should cover that. That was my plan. Do you have an override for that in your template (I think I didn't test that case)? Or why did it show up?

Yeah, I have an override for render.php now in templates/your_template/html/layouts/com_fields/field and it's showing up in the list, it looks like.

In view layouts, we use underscore in layout files which should not appear in the select list. I thought it makes sense to keep that naming convention to allow "hiding" certain layout files.

Gotcha, that makes sense to me too. Good idea/decision 👍

Yeah, the layout indeed does not apply when you insert a single field manually.

I took another approach. The layout now applies also when you insert a single field 😄
You can still manually choose a different layout when inserting the field manually. You can even use the default one if you use "render" as layout option.

One more folder to add

Done.

Yeah, I have an override for render.php now in templates/your_template/html/layouts/com_fields/field and it's showing up in the list, it looks like.

Took care of them as well now.

@Bakual Fantastic! Saw all your latest commits, perfect stuff. Everything looks thorughly taken care of. I will test this all once again with the latest changes and officially mark as successful.

I have tested this item ✅ successfully on 2d7e71e

Can others test this? :)

I have tested this item ✅ successfully on ea054e2

@AndySDH can you please retest?

Ready to Commit after two successful tests.

Sorry for being late to the party, but com_contact needs to be adjusted too https://github.com/joomla/joomla-cms/blob/staging/components/com_contact/layouts/fields/render.php#L70.

Thanks for the reminder @laoneo !

I have tested this item ✅ successfully on 8ba9ff9

I have tested this item ✅ successfully on 8ba9ff9

@Bakual when you get a minute can you please update this pr and fix the merge conflicts?

@zero-24 Rebased and fixed the conflicts

By the way, @laoneo, your comments from: #20243

I would rather see a new function in core to define a default layout for the > field and provide different layouts for the same field type. For the list it would mean to add a new file > here like /plugins/fields/list/tmpl/list_ul.php and then provide these layouts as option in the field.
What do you guys think?

For the people who are requesting a layout chooser per field, It got merged today by #18571.

This PR actually wasn't specifically about what you mentioned over there. This PR here added the ability to add and choose a Custom Layout at a FIELD level (so before even knowing what field type it's going to render). (override for: "components/com_fields/layouts/fields/render.php")

What you were proposing is to add and choose an even deeper Custom Layout at a VALUE level for specific field types, where you would be able to specify a layout for individual values for fields that have multiple values (such as list, checkboxes, repeatable) (override for "plugins/fields/list/tmpl/list.php"). Which is not possible right now and was not included in this PR, just so you know.

@AndySDH Please don't post on closed/merged PRs. Nobody is going to read and answer that.
Open a new issue instead.