Thanks @brianteeman

Updated PR, please test it now guys, thanks! :)

Can you guys please test this? @brianteeman @laoneo @regularlabs

Can you rebase it to the 4.2-dev branch as it is a new feature?

Done, I was able to do it! @laoneo
Thanks to the docs haha: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request

https://user-images.githubusercontent.com/1296369/159136063-8470361b-9b14-4cd5-9654-d4bb58cd143d.gif

When the next time the branch is merged from 4.1-dev into 4.2-dev, then the commits which are not from you will disappear.

When I want to create an integer field there are untranslated strings:

Thank you for spotting this, sorry, please try now.

I have tested this item ✅ successfully on 9137eee

Please test again, thanks guys!

Use Global and Use settings from Plugin have the same value.

<select id="jform_fieldparams_form_layout" name="jform[fieldparams][form_layout]" class="form-select form-select">
	<option value="" selected="selected">Use Global</option>
	<option value="" selected="selected">Use settings from Plugin</option>
	<option value="joomla.form.field.list">HTML Select</option>
	<option value="joomla.form.field.list-fancy-select">Enhanced Select</option>
</select>

Thanks for spotting this @Quy, I guess this was due to @brianteeman suggestion of adding useglobal="true".

What is the standard practice here? Should we remove the useglobal="true" attribute, or should we remove <option value="">COM_FIELDS_FIELD_USE_GLOBAL</option> ?

I see that, for comparison, the 'multiple' field is not using useglobal="true" as an attribute.

useglobal = true should result in the select showing something like "Use Gobal (HTML Select)" which you cannot see when you have it as an option

That's interesting. Though It doesn't seem to happen from @Quy screen for some reason it seems, @Quy can you confirm?

If it works that way, we should probably also do an additional PR to cover other cases where useglobal="true" is not yet used (it doesn't seem to be implemented everywhere, maybe not for field plugins) @brianteeman

It does not display as seen in the screenshot. I would say do a separate PR for useglobal and not include it in this PR if it is available in plugins.

Thanks for the feedback. I removed useglobal="true" for now.

Please test again! Thanks!

This pull requests has been automatically converted to the PSR-12 coding standard.

This pull request has been automatically rebased to 5.0-dev.

This pull request has been automatically rebased to 5.0-dev.

So I guess this PR is scheduled for Joomla 5?

After applying the patch I get this error: Class "Joomla\Plugin\Fields\Integer\Extension\Integer" not found

I have tested this item ? unsuccessfully on 9137eee

Althought the patch does indeed add the required field, you cannot then use ti as adding an article is broken with the following message
Class "Joomla\Plugin\Fields\Integer\Extension\Integer" not found

Reverting the patch and you can add articles again

I have tested this item ? unsuccessfully on 9137eee

This test was unsuccessful due to articles no longer being able to be created after the patch had been applied. This is the error that returned.

An error has occurred.
0 Class "Joomla\Plugin\Fields\Integer\Extension\Integer" not found

@crommie @flo-the-cat @oshufx The reason for the unsuccessful tests is because this PR has merge conflicts. You can see them when going to the PR and scroll to the bottom. I will try to solve them.

@crommie @flo-the-cat @oshufx The reason for the unsuccessful tests is because this PR has merge conflicts. You can see them when going to the PR and scroll to the bottom. I will try to solve them.

Just say when and we will retest

Just say when and we will retest

@crommie @flo-the-cat @oshufx Ready. If you use Patchtester, just don't forget to revert this and any other PRs and then fetching the list of PRs again before applying this PR again.

I have tested this item ✅ successfully on 9137eee

Without patch:

Form layout (in options tab) has options Default and Enhanced Select
Plugin has option to enable/disable Multiple and add a Default Value for the list

With patch:

Form layout is now in the first tab and no longer in the options tab. It has options Use settings from plugin, HTML Select and Enhanced Select
Plugin has option to enable/disable Multiple, add a Default Value for the list and a dropdown to choose HTML Select or Enhanced Select

Thanks for testing! One more test to merge :)

On second thoughts, I decided to undo the change of moving the form_layout setting from params to fieldparmas. For multiple reasons:

• For backwards compatibility. Moving it to fieldparams would mean saved values would have been lost
• It's under params for the subform, and the option is named the same. So it's best if it's consistent across all field types.
• It's a setting shared by multiple fields, so it makes more sense to be in the Form Options

So the option has now returned once again under "Options -> Form Options", as part of the standard params.

Please re-test again, thank you :)

I am afraid the test instruction are not clear enough for me to follow:
Go to Plugin Manager, and in the plugin options of 'Fields - List', change the default 'Form Layout' option
Change it to what? I have a choice of HTML Select or Enhanced Select. I created some list values here too - but that does not seem right and they are not used.

Edit an article and check the form display of the field
I get either an empty list box or an empty textarea. I don't know what I am looking for.

Testing in 5.0.0-beta2-dev

I am afraid the test instruction are not clear enough for me to follow: Go to Plugin Manager, and in the plugin options of 'Fields - List', change the default 'Form Layout' option Change it to what? I have a choice of HTML Select or Enhanced Select. I created some list values here too - but that does not seem right and they are not used.

@ceford

Set it to "Enhanced Select" for example. When editing the field in the article, you should see this:

While if you set it to "HTML Select" you should see this:

There are problems with this PR. It adds a form field to four Field Plugins: Integer, List, Radio and SQL. But the radio field has a Buttons/Switcher choice and the SQL plugin cannot be saved unless a default SQL query is entered.

Applying the patch and creating a Field of each type, when I edit an article the Fields tab gives me the following errors, before the first field:

Warning
: Undefined property: stdClass::$value in
/Users/ceford/Sites/joomla-cms/libraries/src/Form/Field/SqlField.php
on line
302


Warning
: Undefined property: stdClass::$text in
/Users/ceford/Sites/joomla-cms/libraries/src/Form/Field/SqlField.php
on line
302


Deprecated
: trim(): Passing null to parameter #1 ($string) of type string is deprecated in
/Users/ceford/Sites/joomla-cms/libraries/src/HTML/Helpers/Select.php
on line
388

For the SQL field:

 Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /Users/ceford/Sites/joomla-cms/libraries/src/HTML/Helpers/Select.php on line 557

Could be my fault for not filling out the fields properly.

Thanks for testing @ceford

the SQL plugin cannot be saved unless a default SQL query is entered.

That is a separate issue not coming from this PR. It was an issue already present. I tried to fix it as part of this PR as well, but @laoneo asked me to remove it from this PR. See: #37320 (comment)

So that is a separate issue. If it was me I would have included it here, but I didn't make the decision.

Applying the patch and creating a Field of each type, when I edit an article the Fields tab gives me the following errors, before the first field:

I can't reproduce this, I don't get these errors.

I don't think those warnings are coming from this PR. I didn't touch those files, and none of the changes I made should affect those files. I basically only made changes to XML files, so no PHP errors should be affected at all.

I tested every single field. None of them was getting the global settings from their associated plugin for the form layout.
When you reverted the changes (from fieldparams to formoptions), the merge of the plugin params and fieldparams had no longer any effect on form_layout.
The fix I proposed resolves that issue.

@obuisard That is extremely weird. After applying the patch, for me all fields inherit the layout from the respective global settings. I just tested it again to make sure and still worked for me. So I'm not sure why it's not working on your end.

I just applied your proposed change though. Can you please test again now? Thank you!

@obuisard That is extremely weird. After applying the patch, for me all fields inherit the layout from the respective global settings. I just tested it again to make sure and still worked for me. So I'm not sure why it's not working on your end.

Could be a side effect if you have not saved the fields again after the location change of the form_layout.

I have tested this item ✅ successfully on 9137eee

Thank you :)

This pull request has been automatically rebased to 5.1-dev.

RTC

Many thanks for this contribution @AndySDH and the very nice teamwork!

I have tested this item ✅ successfully on 9137eee

Very nice work! We love it!