I have tested this item ✅ successfully on 47f11c0

I very much like this PR. It makes fetching the fields so much easier to understand. Thank you! ?

Should we put all fields into this PR, or should I do for every field a new one? The installer script needs then to be adjusted for every PR then, which will cause conflicts in other PR's which do change the installer sql files.

I'd do all types in this PR. There will be no conflicts in the new files anyway and the other file changes are already in this PR.

This PR needs the install and update SQLs to register the added plugins and its default parameter values then.

please also, do not forget to modify en-GB install.xml for any new plugin

@Bakual what do you think about the latest commit? Stuff is moved to layout as the other plugins and the field parameters are inherited now from the plugin. If there are no more concerns, I will start to move the other ones.

A few remarks concerning lang strings:

1. They should be alpha ordered
2. Both ini and sys.ini should contain for each plugin the two following constants/strings (here for Text)

PLG_FIELDS_TEXT="Fields - Text"
PLG_FIELDS_TEXT_XML_DESCRIPTION="The Text Fields plugin."

and for gallery

PLG_FIELDS_GALLERY="Fields - Gallery"
PLG_FIELDS_GALLERY_XML_DESCRIPTION="The Gallery Fields plugin."

3. The description should explain at minimum what it does... For example something like:
   PLG_FIELDS_TEXT_XML_DESCRIPTION="This plugin lets create new fields of type 'Text" in the extensions where custom fields are implemented." //Correct my English...
4. No need to add a comment like ; Params and/or empty lines
5. No need to make the constant more complex than necessary by using for example:

PLG_FIELDS_TEXT_FIELDPARAMS_USE_GLOBAL="Use From Plugin"

instead of

PLG_FIELDS_TEXT_PARAMS_USE_GLOBAL="Use From Plugin"

Can you alpha order the language strings?

There is also a travis complain. something about calling a static method.

@alikon I'v changed the installer scripts, can you please have a look if the are correct on postgres.

Are the strings correctly ordered?

no ?

alphaordering here means any string ?

current

PLG_FIELDS_CALENDAR="Fields - Calendar"
PLG_FIELDS_CALENDAR_XML_DESCRIPTION="This plugin lets create new fields of type 'Calendar' in the extensions where custom fields are implemented."

PLG_FIELDS_CALENDAR_LABEL="Calendar"

PLG_FIELDS_CALENDAR_PARAMS_FORMAT_DESC="The date format to be used. This is in the format used by PHP to specify date string formats (see below). If no format argument is given, '%Y-%m-%d' is assumed (giving dates like '2008-04-16')."
PLG_FIELDS_CALENDAR_PARAMS_FORMAT_LABEL="Format"

Should be

PLG_FIELDS_CALENDAR="Fields - Calendar"
PLG_FIELDS_CALENDAR_LABEL="Calendar"
PLG_FIELDS_CALENDAR_PARAMS_FORMAT_DESC="The date format to be used. This is in the format used by PHP to specify date string formats (see below). If no format argument is given, '%Y-%m-%d' is assumed (giving dates like '2008-04-16')."
PLG_FIELDS_CALENDAR_PARAMS_FORMAT_LABEL="Format"
PLG_FIELDS_CALENDAR_XML_DESCRIPTION="This plugin lets create new fields of type 'Calendar' in the extensions where custom fields are implemented."

No logical grouping?

No logical grouping?

I don't think we have a file in core where the strings are grouped. Usually we just alpha-order them.
For translation with Crowdin (and I think also com_localise) that wouldn't matter anyway. You only see the grouping if you're translating directly from the raw files.

We have a few files with grouping, alas. Better avoid it indeed.

Installation with postgresql as db works fine. Besides that: is this patch ready for testing?

Despite the language ordering, it is ready for testing.

No empty lines?

Please correct the ini file strings alpha ordering wherever necessary.
We should have for example:

; Joomla! Project
; Copyright (C) 2005 - 2016 Open Source Matters. All rights reserved.
; License GNU General Public License version 2 or later; see LICENSE.txt, see LICENSE.php
; Note : All ini files need to be saved as UTF-8

PLG_FIELDS_CHECKBOXES="Fields - Checkboxes"
PLG_FIELDS_CHECKBOXES_LABEL="Checkboxes"
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_DESC="The values of the checkboxes."
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_LABEL="Checkboxes Values"
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_NAME_LABEL="Text"
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_VALUE_LABEL="Value"
PLG_FIELDS_CHECKBOXES_XML_DESCRIPTION="This plugin lets create new fields of type 'Checkboxes' in the extensions where custom fields are implemented."

and NOT

; Joomla! Project
; Copyright (C) 2005 - 2016 Open Source Matters. All rights reserved.
; License GNU General Public License version 2 or later; see LICENSE.txt, see LICENSE.php
; Note : All ini files need to be saved as UTF-8

PLG_FIELDS_CHECKBOXES="Fields - Checkboxes"
PLG_FIELDS_CHECKBOXES_XML_DESCRIPTION="This plugin lets create new fields of type 'Checkboxes' in the extensions where custom fields are implemented."

PLG_FIELDS_CHECKBOXES_LABEL="Checkboxes"

PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_DESC="The values of the checkboxes."
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_LABEL="Checkboxes Values"
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_VALUE_LABEL="Value"
PLG_FIELDS_CHECKBOXES_PARAMS_OPTIONS_NAME_LABEL="Text"

Like 368042d ?

Concerning alpha order, it now looks fine. Thanks.

Question:
Any reason for adding JFormHelper::loadFieldClass('list'); to contentlanguage.php or frontend_language.php (these are just examples).

Oh, forgot
en-GB.lib_joomla.ini should also be patched in frontend. It should be the exact copy of the admin one.

There is no text for PLG_FIELDS_GALLERY_XML_DESCRIPTION.

Is it possible to show the configuration values set in the fields and system plugin?
Adding a text field for example, there is the field "filter" with the value "Use from plugin" or the field "Automatic Display" with the value "Use Global" and it would be nice to know what these values are without having to look them up.

There is already an issue open for the global value: #13350

Frontend lib file is changed.

Any reason for adding JFormHelper::loadFieldClass('list'); to contentlanguage.php or frontend_language.php

Because the JFormFieldList is not loaded automatically so I'v added the import to all fields which are extending list as I converted them back from abstractlist.

Gallery string is created, thanks for the hint @waader.

Finally found some time to test this.
Main result: It works, but there are a few bugs in the actual plugins.

@rdeutz Imho it could be merged to get the architecture right for the alpha2 and then fix the remaining bugs afterwards.

As for the findings in detail:

• If a plugin is disabled, the created fields of that type still show as published. They should ideally show similar to modules where the actual extension is disabled. This can be done afterwards in a separate PR for sure as it's only a visual thing.
  
• Checkboxes and Radio Field: "Checkboxes Values" and "Radio Values" respectively have no effect when set in the plugin parameters. They have to be set in the field parameters. Also, if no options are set a warning "Warning: DOMElement::setAttribute() expects parameter 2 to be string, object given in ...\administrator\components\com_fields\libraries\fieldsplugin.php on line 177" appears. This likely should be catched.
• Calendar Field: The "Format" parameter set in the plugin has no effect because there is a default value also set in the field parameter.
• Editor Field: Width and Height only apply to the textarea field when the editor is disabled. the editor itself always uses full width. Also the show button and hide button doesn't seem to have any effect.
• List Field: For some reason that type doesn't show up in my list of available types.
• Imagelist Field: Path settings don't work in Windows. Probably same issue we had with the Gallery type.
• URL Field: Schemes parameter only work when explicitely set in the field, the one set in the plugin isn't considered.
• User Field: "Multiple" doesn't work for that one and should be removed. The field doesn't support multiple selections.

Thanks @Bakual. Give me some days to fix the bugs, except the first one.

Imho those are all minor issues with the respective plugins and could be fixed after this is merged (to not delay this one). But I leave that for others to decide :)

I have tested this item ✅ successfully on 2ccdcd7

Set as successful test after talking with @rdeutz

I have tested this item ✅ successfully on 2ccdcd7

looks good so far. I have just tested the plugin funktionality.

RTC