I have tested this item ✅ successfully on 550eeac

Works good to me thanks @degobbis :)

I have tested this item ✅ successfully on 550eeac

RTC

Please target this combat Pr on J3.10 and I'm not sure if this is the best way to do this.

I didn't looked at the layout/form engine but why do we get an empty response from the orignal $layout? The other question is what if I return empty as layout because I don't want any layout?

When you don't want any layout you can override the getInput method right?

We get an empty response as in 3 that specific layout does not exist.

When you don't want any layout you can override the getInput method right?

We get an empty response as in 3 that specific layout does not exist.

Then we should check if the layout exists and and don't guess it.

Then we should check if the layout exists and and don't guess it.

Ah ok so not throwing that via getRenderer but checking whether the layout file exists right?

Maybe checking the render if it can tell us if the layout exists. If not we should extend it because checking if the file exists isn't so easy because jlayoutfile searches multiple locations for the file iirc.

Maybe checking the render if it can tell us if the layout exists. If not we should extend it because checking if the file exists isn't so easy because jlayoutfile searches multiple locations for the file iirc.

Done please see here @HLeithner bf8bed1

Please target this combat Pr on J3.10 and I'm not sure if this is the best way to do this.

Also done now.

@richard67 can you please test again?
Please download the new version of the plugin.

I'm not a big fan of using that kind of automatically changing things. That will be confusing for developers when they specify a layout and a different one is actually loaded.

JLayouts already support a wide array of fallbacks by itself. So you can for example declare a suffix based on the current Joomla version and JLayout would automatically search for a matching layoutfile.
I would try to use that instead of adding fallback code everywhere.

Well how would you approache the issue mention here than?

Personally, I decide for one way in my extension. Either radiobuttons or switcher. As I also have to switch the order of the options for them to properly show, this PR alone wouldn't be sufficient. It's not like something is broken if you use buttons in J4, it's just not using the same UI.
It would also be pretty simple for an extension to build an own formfield which extends the radiofield and contains just some small logic to switch the layout (and options order) based on the active Joomla version. So it's not like it's currently impossible to do it.

But if you really insist on adding some automatically code into our formfields, I would add to the layoutname the Joomla major version as a suffix. Then extension developers can provide own JLayouts with the proper design based on the Joomla version their extension runs.
See https://docs.joomla.org/J3.x:JLayout_Improvements_for_Joomla! for more details about JLayouts.

But as I wrote I wouldn't add anything as it's pretty simple to solve if an extension developer needs to have different designs for the two Joomla versions. He will need such code anyway for all his other layouts to adjust to the new BS4 template :)

I do not like the idea with fallback.

if need version specific layout then idea by @Bakual is much better.
Use version specific suffixes. That why a layout suffixes was made.

Well i can not follow how version specific layout can help here? The core does not ship such layouts? I'm not sure why all fields should have to be forked for 3.10 + 4 support by extension devs?

The core does not ship such layouts

Correct, because it does not need.

Check the code:

$renderer = new FileLayout('blabla.foo.bar');
$renderer->setSuffixes(['j4']);

echo $renderer->render($blablaData);

The FileLayout class will look first for layout blabla.foo.bar.j4 and if it not found will use blabla.foo.bar.

Or this:

$renderer = new FileLayout('blabla.foo.bar');
$renderer->setSuffixes(['j3']);

echo $renderer->render($blablaData);

This will search for blabla.foo.bar.j3 first and if it not found will use blabla.foo.bar.

Extension developer can implement it in his field very easy, just override getRenderer() method:

protected function getRenderer($layoutId = 'default')
{
    $renderer = parent::getRenderer($layoutId);

    if (major version === 3)
    {
      $renderer->setSuffixes(['j3']);
    }

    return $renderer;
}

Links for references:
The code responsible for handle suffixes:

And method to add suffixes for current major version FileLayout::loadVersionSuffixes()

Whole idea of this PR are against Layouts idea, because the Layout class already designed to fallback to default if override not found.

I'm not sure why all fields should have to be forked for 3.10 + 4 support by extension devs?

Why all layouts? To my knowledge only the switcher layout is an issue because we explicitely have to set the layout in the XML (since class wasn't fine for some reason). All other fields use the default layout. Or do I miss something?

Why all layouts? To my knowledge only the switcher layout is an issue because we explicitely have to set the layout in the XML (since class wasn't fine for some reason). All other fields use the default layout. Or do I miss something?

You are right, in this case it only affects the radio field. But Joomla 3 will continue to exist alongside Joomla 4 for a while and who knows what will change in Joomla 4. So it makes sense to use a Global solution for all fields.

With my PR I want to create the basis for the fact that not simply a label without field and without warning is returned.

If a layout is set by the user, which does not exist, there are in my opinion only two correct procedures:

1. we return an error (which was probably also the programmer's idea)
2. we use a standard layout (which would be my preferred approach).

The way it is now, I think it can't be right.

Procedure 2 also allows extension developers to use only one additional attribute in their manifest file to have the right layout for both versions, without a B/C break and without having to modify any more code in their extensions. So they can cover both versions with only one extension.

As I understand it, Joomla 3.10 is primarily intended to ease the transition to Joomla 4, even for extension developers. Procedure 2 is a good approach and does not have to be adopted in Joomla 4, unless we plan to change layout names in Joomla 5 again ;-)

In Joomla 4, however, I think at least procedure 1 is reasonable.
I would be willing to implement it there as well, if desired.

Layout class already designed to fallback to default if override not found, if we need another fallback then we doing something wrong.

Alternative solution would be pull request that call $renderer->loadVersionSuffixes()
in FormField::getRenderer()

Then extension developer can provide J3 or J4 specific layout without use of own field class.

Example if the field layout is joomla.form.field.radio.switcher, then:
on Joomla! 3.10 Layout class will looks for:

joomla.form.field.radio.switcher.j310
joomla.form.field.radio.switcher.j31
joomla.form.field.radio.switcher.j3
joomla.form.field.radio.switcher

and on Joomla! 4.0 Layout class will looks for:

joomla.form.field.radio.switcher.j400
joomla.form.field.radio.switcher.j40
joomla.form.field.radio.switcher.j4
joomla.form.field.radio.switcher

So developer can provide any of this layouts, and he free to choose to provide J3 specific version or J4 specific version.

Layout class already designed to fallback to default if override not found, if we need another fallback then we doing something wrong.

Sure but we are not talking about fallbacks to default / overrides that works fine we are talking about fallbacks to the default layout of the fom field. You can check the plugin from above to see that it would be broken right know by using an non existing layout.

You can check the plugin from above to see that it would be broken right know by using an non existing layout.

Yeap I seen,
That why I suggested to call $renderer->loadVersionSuffixes() in the FormField class ?
this can be done for 3.10

Anyway, the idea with a layout fallback will introduce much more confusing and inconsistency.
It fixing a local issue, but in global context just add much confusion. (why we have layout fallback for an input layout, but do not have fallback for $renderLabelLayout, and for $renderLayout etc etc.)
This better to avoid.

btw, additionally to $renderer->loadVersionSuffixes() we may also provide layout joomla.form.field.radio.switcher.j310 for Joomla 3.10 for transition to switcher field. The layout will display old "btn-group" radio-button style for Joomla! 3.10 and will be ignored for Joomla! 4.

You are right, in this case it only affects the radio field. But Joomla 3 will continue to exist alongside Joomla 4 for a while and who knows what will change in Joomla 4. So it makes sense to use a Global solution for all fields.

I really doubt there will be more changes like this. The switcher is a very special case which doesn't need a global solution.

Please check alternative solution #30070

This solution with the fallback to a standard layout is just my idea for a user-friendly process in the missing of a layout.

The basis for this is a correct error handling when a layout is missing. Therefore I have separated this error handling into a separate PR #30079.

The PR of @Fedik to provide an extra layout for the transition to J4 for this individual case is an acceptable alternative.

If my idea should not be pursued further, this PR can be closed.

New PR by @Fedik is #30078 .

@degobbis Would your PR here still make sense after @Fedik 's new PR #30078 has been merged, so yours is an alternative possibility in addition to his one? Or do they exclude each other, i.e. if his PR has been merged, yours is not needed anymore or doesn't make sense anymore?

If my idea should not be pursued further, this PR can be closed.

Whoever is responsible for deciding which approach is desired may do so before I close this PR.

@degobbis Yes, I understood. My questions above are for making decision for those people easier. If your PR still would make sense in addition to the other one so we have to alternative solutions, then why not? I think your opinion counts here, too. Anyway thanks for making this one and having tested the other one. All contributions are welcome.