Joomla! Issue Tracker - CMS

Download
Launch
Feeling Lucky

[#46361] - [6.0] After redefining the plugin layout, the layout is not displayed in the list.

No Code Attached Yet
avatar korenevskiy
korenevskiy
23 Oct 2025

Steps to reproduce the issue

I opened the default Cassiopeia template.
In the settings, I created a redefinition of the plug-in layout plg_fields_imagelist
I checked the availability of the layout at
templates/cassiopeia/html/plg_fields_imagelist/imagelist.php
And created a copy
templates/cassiopeia/html/plg_fields_imagelist/pictures.php
There is still 1 default layout in the field layout list.
I use Cassiopeia by default. I also used CMS resources to create the layout. Unfortunately, it does not appear in the list.

But then there's a mistake.
The template parameters override the layout at
/templates/cassiopeia/html/plg_fields_imagelist
but to display it in the layout list, you need an address.
/templates/cassiopeia/html/layouts/plg_fields_imagelist/field

I'm not arguing that the layout file should be located elsewhere. I don't have to create the file myself through the file manager. The template has an override function. The override function tells us that by overriding the layout with the built-in CMS functions, it should have been included in the layout list. This means that automatic redefinition is not being done in the right way.
Either the layout display list is not working, or the automatic layout override function is not working.

Image

Expected result

After redefining the layout in the template parameters, the redefined layout should appear in the list of layouts in the plugin field settings.

Actual result

After redefining the layout, the layout does not appear in the list.

Additional comments

It was also found out that if you place the layouts at the specified addresses, they are displayed in the list.

joomla-cms/administrator/components/com_fields/src/Field/FieldLayoutField.php

Lines 104 to 108 in 508ac3d

$template_paths = [
Path::clean(JPATH_SITE . '/templates/' . $template->element . '/html/layouts/' . $extension . '/field'),
Path::clean(JPATH_SITE . '/templates/' . $template->element . '/html/layouts/com_fields/field'),
Path::clean(JPATH_SITE . '/templates/' . $template->element . '/html/layouts/field'),
];

But if everything is working correctly as intended, then there is an error in the name of the fields, then you need to rename the layout field to input layout.

Or the layouts in the template parameters are automatically redefined in the wrong way.

avatar korenevskiy korenevskiy - open - 23 Oct 2025
avatar joomla-cms-bot joomla-cms-bot - change - 23 Oct 2025
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 23 Oct 2025
avatar brianteeman
brianteeman - comment - 24 Oct 2025

The paths that the fieldlayout field is looking in are the generic paths for the renderer for ALL fields. It is not looking at the override path for the specific plugin.

The generic renderer is analogous to the module chrome not the module layout

avatar Fedik
Fedik - comment - 24 Oct 2025

I copy my comments here from #46313 .
In short: it is not a bug, but misunderstanding due poor documentation.

There is 2 layout systems working here, and they are not interchangeable.

  1. Layouts from tmpl/ which renders the field value. It can be only one, so no reason to create dropdown for it.

    joomla-cms/administrator/components/com_fields/src/Plugin/FieldsPlugin.php

    Lines 222 to 228 in 1c654ef

    // Get the path for the layout file
    $path = PluginHelper::getLayoutPath('fields', $this->_name, $field->type);
    // Render the layout
    ob_start();
    include $path;
    $output = ob_get_clean();

  2. Layouts from layouts/ which renders the wraper around the value, and label. This you can select in the field parameters.

joomla-cms/components/com_fields/layouts/fields/render.php

Lines 55 to 58 in 10f250f

$class = $field->name . ' ' . $field->params->get('render_class');
$layout = $field->params->get('layout', 'render');
$content = FieldsHelper::render($context, 'field.' . $layout, ['field' => $field]);

joomla-cms/components/com_fields/layouts/field/render.php

Lines 33 to 42 in 10f250f

<?php if ($showLabel == 1) : ?>
<span class="field-label <?php echo $labelClass; ?>"><?php echo htmlentities($label, ENT_QUOTES | ENT_IGNORE, 'UTF-8'); ?>: </span>
<?php endif; ?>
<?php if ($prefix) : ?>
<span class="field-prefix"><?php echo htmlentities($prefix, ENT_QUOTES | ENT_IGNORE, 'UTF-8'); ?></span>
<?php endif; ?>
<span class="field-value <?php echo $valueClass; ?>"><?php echo $value; ?></span>
<?php if ($suffix) : ?>
<span class="field-suffix"><?php echo htmlentities($suffix, ENT_QUOTES | ENT_IGNORE, 'UTF-8'); ?></span>
<?php endif; ?>

Create file templates/cassiopeia/html/layouts/com_fields/field/foobar.php. And it will be available in that layout dropdown.

avatar brianteeman
brianteeman - comment - 24 Oct 2025

and i repeat that this might be what the code does but it is wrong. as I said before this is the render for all fields and not the output of the specific field. The render is the same as a module chrome it is not a layout

avatar Fedik
Fedik - comment - 24 Oct 2025

The render is the same as a module chrome it is not a layout

Yes. it renders "wrappers" for the field value and label.

You want multiple tmpl/ and be able to select it like for module tmpl/?
Then it will be new feature.

avatar brianteeman
brianteeman - comment - 24 Oct 2025

I just want to be able to use the template override as created by the template manager.

avatar Fedik
Fedik - comment - 24 Oct 2025

It already works.
You create an override and it will be used automatically, no need to select anything.

avatar korenevskiy
korenevskiy - comment - 24 Oct 2025

If it works automatically. Then the field of the layout list in the parameters of the field that should display the override list is not correctly named. Either the list of layouts should be named differently, or since the list of layouts redefines something completely different than necessary, or the name of the field in the list of layouts should be renamed to a more precise definition.
For the sake of example: the content of an article can be called text and the content of a category can be called text. Imagine that in the admin panel there are 2 positions with the same TEXT names. Opening one takes you to the article, opening the other takes you to the categories, but they both have the same name in the menu. This does not reflect the difference between categories and articles.
It's the same here, we need to add a clarification to the current field so that it's clear that this is not a layout of a custom field, but a layout of a system field, or add a new function so that we get a redefinition of the user field.

Well, in general, using an automatic function to redefine the layouts of the system field is stupid. Since we are redefining the layout of the plugin and not the system input field.
It may be very good that you can redefine the system input field, but the list of layouts in the plugin should specifically choose to redefine the layout of the entire plugin and not the system field.

Fedik probably doesn't want to fully express his thought for some reason.

Add a Comment

Login with GitHub to post a comment