Bot please stop, what did i do wrong ?

@mbabker make the bot stop ! :D

I have tested this item ✅ successfully on 6bb62b5

Tested only the custom list field type. That one is working correct now.

@Bakual, thanks for the test,
i have also fixed character '0' unsuable as field value (see description on top of this PR)

besides the list type, please also test fields

• radio, and checkboxes, both in form and in frontend viewing

i have also fixed character '0' unsuable as field value (see description on top of this PR)

That is a bug in the JFormFieldList, not in com_fields. Looks like you are fixing that in the wrong spot :)
Also, I wouldn't try to fix everything with your PR. Keep it on one topic (atomic) and it generally gets tested and merged faster.

We are not using JFormFieldList here

Custom Fields extend class JFormAbstractlist
libraries/joomla/form/abstractlist.php

which (JFormAbstractlist) extends JFormField

The bugs is in 2 places:

Custom fields helper forces the use of default value on empty
administrator/components/com_fields/helpers/fields.php
https://github.com/joomla/joomla-cms/pull/12739/files#diff-4d276fa5ac7a065127d4620092ed38fdR136

Bogus:

if (! $field->value)

Correct:

if (
  (is_array($field->value) && !$field->value) ||
  (!is_array($field->value) && !strlen($field->value))
)

Value-viewing layout files , have exact same code force a "return" on empty

The fix is valid and straightforward

I have updated testing instructions

We are not using JFormFieldList here

We are, because JFormFieldList extends JFormAbstractlist. It's the exact same code. So any change you make there, will potentially affect all other instances of JFormFieldList.
Since the regular use of JFormFieldList (specified in the form XML) behaves the same when you have the name/text set to 0 (will use the value instead), it is a bug unrelated to com_fields and shouldn't be handled in this PR. ?

hhmm i see, i will undo the zero value change and put the zero value fix in different PR, since it is not directly related to this PR, and it does concern more fields than just radio, checkboxes, list

@Bakual
I have reverted the fix, for zero character as value ? it is good for testing

Not sure this is enough.
I create a field list:

The Options are

When editing an article, I choose an item in the list, I see the Text to choose from, which is fine

In the db I have the correct value

BUT I get the Text in frontend when displaying an article (nothing displays if featured or blog layout)

I should get the Value and not the Text
Signature: Signed by Joomla

Hello

The view layouts should display the "Text" by default,

• since usually the "value" for radio/checkboxes/list, will be something that is not desired to be displayed, e.g. a number (of course you can have text=value too)

In my custom component it is configurable if the layout will show the "Text" or "Value"
with default being the "Text"

The "value" is stored in DB, effectively it is the "index"

then if later, you change the "Text", you do not need to resave all the articles ...

Example you have 'JNO' as text and later you decide to use 'JNO_RECOMMENDED'

Also "Text" is only 1 property
later you can add more properties to it:

• "Image"
• "Font-icon"
• "Description" / "Inline tip"

etc, whatever (or of course you can have a new field-type)

Also in future (it may be implemented that)

• some type of fields can be interchangeable without causing problems

that is why radio, checkboxes, list should have mostly same configuration
you will just change field type , and everything will continue to work

And then text-search index will / should store "Text" and other properties

I disagree.

since usually the "value" for radio/checkboxes/list, will be something that is not desired to be displayed, e.g. a number (of course you can have text=value too)

Usually is subjective to your needs.

My example above shows that it is not correct.
Take an example:
A value will never go through JText::() to be translated by a string, but the Text will.

It is exactly similar to this example:

            <option value="mail">COM_CONFIG_FIELD_VALUE_PHP_MAIL</option>
            <option value="sendmail">COM_CONFIG_FIELD_VALUE_SENDMAIL</option>
            <option value="smtp">COM_CONFIG_FIELD_VALUE_SMTP</option>

where the value "mail' corresponds to the Text "PHP Mail"
(COM_CONFIG_FIELD_VALUE_PHP_MAIL="PHP Mail")

or

                <option value="show_no_link">COM_CONTACT_FIELD_VALUE_NO_LINK</option>
                <option value="show_with_link">COM_CONTACT_FIELD_VALUE_WITH_LINK</option>

There are multiple examples in core.
One is not going to translate the value, but we will translate the Text (here a lang string).

There is one possible solution: a new parameter for lists.

I also found out there is no easy way to hide the label when rendered.

I never said to use -only- number as value (only said as example)

of course you can have alphanumerical characters
just 'value' should be unique in the set

About your examples, they support what i suggested:

value: show_no_link
text: COM_CONTACT_FIELD_VALUE_NO_LINK

value: show_with_link
text: COM_CONTACT_FIELD_VALUE_WITH_LINK

So i am a bit confused

I am saying that Text can be translated, not the value.
My screenshots above shows it is not the value which is displayed but the Text.

I am saying that Text can be translated, not the value.

Agreed i am saying the same thing

My screenshots above shows it is not the value which is displayed but the Text.

Yes that is the purpose of this PR

It fixes this issue: #12725 (so that "Text" is displayed)

OK.
Please explain to me how one can get a list choice where both possible Values and Text can be translated to fit the language used. When editing the field and when displaying its result.

value: show_no_link
value: show_with_link

so value will not be translated,

only "Text" will be translated, do we also want to translate the "value" ?
maybe i am missing some usage scenario,

if both need to be translated then some extra coding will be needed,
if it is about displaying, then the view layout can do anything

I posted the exact scenario in the screenshots above.

yes e.g.
you can use 2 language strings for both "Text" and "Value"

Currently
JFormAbstractlist::getOptionsFromField()
does not translate any of them, (nor it should do)

• for form it is done by during the select field creation
• for viewing, the translation is left to the layout, current code does not translate neither the "text" nor the "value"

(i will need to confirm the above, i am on the move)

Nor the label. See patch here for that one : #12656

What do you think about adding parameters to let translate or not all these?

@infograf768 Sorry JM but in select lists values never are translated because they are not supposed to be shown to users, Texts are translated, that's the sole purpose of the text feature in HTML select options. Text is meant to be a user friendly representation of the value. The value is the thing that is stored to the database and handled internally in code to decide what to do. Can you imagine the mess if you had translated values in database and deal with that in code? I think you confused something here.

@Bakual
therefore do i understand well that a custom field of type list implies some php code somewhere to be used? Which would mean that a big part of this new com_fields usage is specially for devs and not for the common user?

No. For a list field, you want the display text to be translated (what the user sees in the dropdown), but the value (what the code processes) to NOT be translated at all. Take our XML schemas as an example where we commonly have these options:

<option value="1">JYES</option>
<option value="0">JNO</option>

The 1/0 are never translated (and if they were it'd be next to impossible to work with the data). The display text (JYES/JNO) is.

Similar to "multiple", which exists in some fields,
there should be a parameter:
Language filter values or "Language filter option texts" (radio/checkboxes/list fields)

For radio/checkboxes/list fields it should be ON by default

For all other fields: text / textarea / etc it should be OFF by default

For other fields types parameter e.g. "integer" type, it will not exist, in their XML file

and JText::_() should be used at the view layout, so that in the end, a custom view layout will be able to do whatever is needed

therefore do i understand well that a custom field of type list implies some php code somewhere to be used? Which would mean that a big part of this new com_fields usage is specially for devs and not for the common user?

It uses the exact same code we have today for every list field (select dropdown). The values are never translated (because it would be a horrible idea that makes no sense) and the text is translated.
I really think you're mix up something here.

Thanks folks.
I do not want to pollute this PR anymore. Will ask some explanations by private chat as I still do not understand how a simple user will use the values from a list without adding somewhere some php code.

@infograf768

I am not sure what you want to know, it sounds like your asking if the layout files are flexible enough to do most common cases without the need of a custom layout ??

• the usage / display of the values happens in the layout files found in this folder (and in plugin folder if field is a plugin and in ...):

https://github.com/joomla/joomla-cms/tree/staging/components/com_fields/layouts/field/prepare

Example:
radio/checkboxes/list fields have the same identical layout file:
https://github.com/joomla/joomla-cms/pull/12739/files#diff-7af89bfa1d082ebacba8d9b5ab751e90

components/com_fields/layouts/field/prepare/radio.php
components/com_fields/layouts/field/prepare/checkboxes.php
components/com_fields/layouts/field/prepare/list.php

Layout files are loaded by the helper method FieldsHelper::render()
https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_fields/helpers/fields.php#L180-L192

• which tries to load layouts from some directories in an appropriate order

https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_fields/helpers/fields.php#L180-L191

I guess you mean that they are too basic,
e.g. currently no option to use JText or not,
e.g. currently no option to use custom separator, now it is only comma

so they need a couple of more configuration parameters to cover more usage cases without a custom layout

@ggppdk
Yes to the new parameters but:
Can we chat somewhere? Skype or glip? I think you do not understand my question, or I did not express myself correctly.
My skype is infograf768. On glip both jean-marie.simonet and infograf

Please explain exactly when you would need custom php code as I do not see it.

If you watch my video from Joomladay Israel I think it will answer your
question.

After a conversation with @ggppdk it confirmed my statement above:
#12739 (comment)

Using such custom fields NEED specific layouts in php where the new parameters are used to do something or another.

I evidently found some ways to use list without caring about the value, but in any case we do need a way to translate the Label and Text
i.e. in their respective files.

$texts[] = JText::_($optionText);

$label = JText::_($field->label);

Only common or very common parameters can be handled in the fields helper file,

an example of such a case are (field configuration parameter):
-- default value

Any field specific -display- parameters that appear in the XML file of field's type
-- are handled by the view layout, they can not be in common code of the fields helper

this makes the layouts more powerful, just now they are very basic and do little,
(but if they do get too complex they can harm category performance when showing many records ...)

Finally about the case of translating Text-labels of the options of fields: radio / checkboxes / list

• it has to be at the layout because the JFormAbstractlist::getOptionsFromField() that gives the options is supposed to give them unmodified

now because the FORM HTML of the fields of radio / checkboxes / list,
already assume that need to be JTexted and do it already, i guess, JText should be in the view layout

-- without need to add a new parameter to the fields configuration for "Language filter option texts"

even if you later decide to add the parameter: "Language filter option texts",
it can have a default in XML and in PHP code to "yes" so no B/C break

"Language filter option texts" ?
Translating the fields Label and Text (that last one for list/checkboxes) is not specific to multilingual sites.

"Language filter option texts" ?

Ok maybe bad parameter name, better:
Option Text is language string
-- yes
-- no

Homestly I'm lost by now. The option text is already translated fine when this PR is applied (without it's messed up).
See my options

Then how it appears in the article edit form

And finally in frontend in the article view

So the code is there to show the proper text based on value and even translate it. Nothing more is needed.

Using such custom fields NEED specific layouts in php where the new parameters are used to do something or another.

Keep in mind custom fields areen't meant to change behavior. Like change how the layout appears or what it is supposed to do. The fields are meant to add custom data. Like if you have a group of articles about historic events, you could add a date of the event using a custom calendar field. That date is just going to be shown in frontend.

Honestly I'm lost by now
Me too

Homestly I'm lost by now. The option text is already translated fine when this PR is applied (without it's messed up).

Because i added it in a today's commit, see the commit here: 141309f

I added it, after last comments from @infograf768, and after my comment, that the FORM HTML of the fields: radio / checkboxes / list, already assume that "Option Text" need to be JTexted and do it already, so JText for "Option Texts" should be in the view layout too, without a parameter

This PR makes multiple but small changes, for the JFormAbstractlist fields: radio, checkboxes, list

• corrected a few language strings, so that the 3 fields are consistent
• changed (wrong) parameter name "key" to "name" in XML files, that caused fields: radio / checkboxes not to show in the form
• reversed the "name"(=Option text), "value"(Option value) PAIR in JFormAbstractlist ::getOptionsFromField(), so that "Option Text" is displayed instead of "Option Value"
• added a layout for radio field (same as fields: checkboxes, list)
• added JText to the Options-text in the field's viewing layouts

Because i added it in a today's commit

Oh, I thought that one worked before as well, looks I was wrong.

we still need to Jtext the label

we still need to Jtext the label

right, yes,

But JText the label must be a different PR right ? because it is something that effects all fields

Like the "0" character as value, is not showing (single value selected), should be a different PR, because it effects all fields too, (i had fix here but it was undone)

Otherwise this PR will keep needing retesting, lets keep this PR to effect JFormAbstractlist fields: radio, checkboxes, list

This PR does already more than what it was supposed to do. Please don't add the label and the 0 issue here or we can never merge it.

I've tested this with all three types now. They all share an issue in frontend if a 0 value is selected:

• If no default value is set, they disappear completely
• If a default value is set, that default value is used instead of the 0 value.

I think that was the bug you solved and reverted due to miscommunication between the two of us?
This issue is specific to com_fields and could be solved with this PR or another one. I don't mind much.

The one I referred earlier was when 0 was used as the text not the value. Then the text is ignored and the value is used as text. Like when no text is given. But that is an issue unrelated to com_fields.

Checkboxes have an additional issue:
If the 0 value is the only one selected, then it will be unselected after saving. If you select the 0 value together with another value, then it gets saved properly.
This is an issue with com_fields only but probably also unrelated to this PR. So could be done in another PR as well.

• If no default value is set, they disappear completely
• If a default value is set, that default value is used instead of the 0 value. I think that was the bug you solved and reverted due to miscommunication between the two of us?

yes exactly

This issue is specific to com_fields

yes

Checkboxes have an additional issue:
If the 0 value is the only one selected, then it will be unselected after saving. If you select the 0 value together with another value, then it gets saved properly.

Yes,
!$this->value returns false if it is single value
!$this->value returns true if it is an array of values that one of them is "0'

Because the layout of all files and the helper class need to be to patch: see comment above: #12739 (comment)

Let's put it in a different PR together with the label you can do or i will do tomorrow

label PR is here: #12656

We need to merge this PR first to solve the other issues properly. From my PoV this is RTC now, but since I'm tester someone else should merge it :)