User tests: Successful: Unsuccessful:
Pull Request for Issue #40762 and follow up of #39051.
The use of the parameter 'showon' has been introduced in Joomla 4.3 for custom fields.
However, it lacks the handling of the fields when displayed in the front-end.
This PR is adding the missing functionality.
In the 'Content' context:
Create a field of type 'text' named 'Conditional Text'.
Create a field of type 'list' named 'Box'. Add options (value1, value2 and value3).
Create a field of type 'list' named 'Square'. Add options (value1, value2 and value3).
For testing, you will need to change the value of the 'showon' attribute found in the 'options' tab for the text field.
After each change, open an article in the backend and change values of the Box and Square fields and check that the text field shows or hides depending on the values selected and the condition that has been set in the 'showon' attribute.
In the frontend, when opening the article, the display of the fields should match the display of the fields in the backend.
Values of the 'showon' attribute you can try out, as examples:
'Conditional Text' will show if:
box:value1
=> Box has value1
box!:value1
=> Box does not have value1
box!:
=> Box has a value that is not empty (in this case, you could add an empty option to that 'Box' field)
box:value1[OR]square:value1
=> Box has value1 or Square has value1
box:value1[AND]square:value1
=> Box and Square must have value1
box:value1[OR]square!:value1
=> Box has value1 or Square does not have value1
box:value1[AND]square!:value1
=> Box has value1 and Square has a value other than value1
box:value1[AND]square:value1,value2
=> Box has value1 and Square has value1 or value2
box:value1[AND]square!:value1,value2
=> Box has value1 and Square has value3
Test that wrong entries in the 'showon' parameter with values such as tada
, box::
, box:!
, box:3:21
, [AND]box:value3[OR]tada:2:3
... does not generate errors in the front-end.
To test custom fields sent through emails, you will need to create fields in the 'Contact' - 'Mail ' context.
Create a field of type 'text' named 'Conditional Subject'.
Create a field of type 'list' named 'Sub'. Add options (value1, value2 and value3).
Make sure both fields have proper permissions to be editable in the contact form.
Set a 'showon' value for the text field, for example: sub:value1
.
Now, when you go to the front-end and display the form for a contact, you should be able to switch between values of 'Sub' and check that the text field shows or not. When the email is sent, the content of that email should reflect the choices you made.
To test subforms, make 'Conditional Text', 'Box' and 'Square' part of a subform field.
Note that in subforms, the 'showon' parameter must use a different syntax, since the field names, in a subform, show as 'field[id]'. For instance, if 'Box' has id 15, the name of 'box', in the subform, will be 'field15'.
So you can try testing with 'showon' values such as field15:value1
.
Test the subform in the backend and the results in the frontend should match what has been selected in the backend.
Note: the 'showon' parameter will also 'work' with the syntax {fieldgroup X}
that you can put inside the content of your article. However, it won't work if you hand-pick fields in the editor or have conditions set in different field groups.
Notes to developers:
why adding the code to match the showon parameter in FieldsHelper? So it can be made available globally and used in overrides and third-party extensions easily. The function names in the helper are not set in stone, I welcome suggestions.
why have a particular case for subforms? Because when a subform is about to get displayed, the sub-fields have already been prepared for display and it's too late to change anything. Therefore, changes have to be made in the onCustomFieldsPrepareField function of the subform plugin.
why make changes to the render.php files? So that we have all possible fields, prepared (it's also more efficient and prevents changes in too many places). The downside: we will only cover the {fieldgroup X}
syntax of the content plugin, 'showon' won't work if fields are hand-picked or not in the same group.
All fields show in the front-end, no matter the values that have been set in the 'showon' parameter.
Same goes for fields that will show in emails sent through the contact component.
Only the fields that are set to show actually show in the front-end.
Same goes for fields that will show in emails sent through the contact component.
For showon syntax, check: https://docs.joomla.org/Form_field#Showon
Category | ⇒ | Administration com_fields Front End com_contact Plugins |
Status | New | ⇒ | Pending |
Labels |
Added:
PR-4.3-dev
|
Hello @HDInfautre, can you share your configuration of the custom fields (just a screenshot of each one of their setup)?
Thanks!
Bonjour @HDInfautre, pouvez-vous partager votre configuration des champs personnalisés (juste une capture d'écran de chacun de leur configuration) ? Merci!
OK, I put the images in my tests, I don't know if that will help, I could also give access.
Bonjour @HDInfautre, pouvez-vous partager votre configuration des champs personnalisés (juste une capture d'écran de chacun de leur configuration) ? Merci!
OK, I put the images in my tests, I don't know if that will help, I could also give access.
Super, thanks, now can you tell us which combination (what value of the showon you used) did not work for you?
Bonjour @HDInfautre, pouvez-vous partager votre configuration des champs personnalisés (juste une capture d'écran de chacun de leur configuration) ? Merci!
OK, j'ai mis les images dans mes tests, je ne sais pas si ça va aider, je pourrais aussi donner l'accès.
Super, merci, pouvez-vous maintenant nous dire quelle combinaison (quelle valeur du showon vous avez utilisée) n'a pas fonctionné pour vous ?
I mentioned above that everything worked in the tests performed, except the use of "!"
I just tried again with
liste!:a
case-a-cocher!:cas1
bouton-radio!:btn1
If needed, I can provide access to the test site where I hope others will run the tests to confirm or not.
Bonjour @HDInfautre, pouvez-vous partager votre configuration des champs personnalisés (juste une capture d'écran de chacun de leur configuration) ? Merci!
OK, j'ai mis les images dans mes tests, je ne sais pas si ça va aider, je pourrais aussi donner l'accès.
Super, merci, pouvez-vous maintenant nous dire quelle combinaison (quelle valeur du showon vous avez utilisée) n'a pas fonctionné pour vous ?
I mentioned above that everything worked in the tests performed, except the use of "!" I just tried again with liste!:a case-a-cocher!:cas1 bouton-radio!:btn1
If needed, I can provide access to the test site where I hope others will run the tests to confirm or not.
I tried list!:a and it worked for me.
So, maybe yes, I am going to take you up on the offer. Can you give me access to your test site?
You don't have to give it here, as it is public and I don't want you to get flooded with people accessing your site, just give me access on Mattermost :-) Thanks!
OK, I had a conflict with another plugin.
This works
Thanks olivier
I have tested this item
Thanks
OK, I had a conflict with another plugin. This works Thanks olivier
Thank you for the tests and helping through this :-)
I have tested this item
Status | Pending | ⇒ | Ready to Commit |
RTC
parameter must use a different syntax, since the field names, in a subform, show as 'field[id]'.
That a good find.This actually were a huge mistake of doing that
It broke whole subform and force us of doing work around here and there. Like you made in current PR.
After some testing around, I found if we just remove this useles thing,
then all works as normal for Subform field:
joomla-cms/plugins/fields/subform/src/Extension/Subform.php
Lines 409 to 410 in b945390
joomla-cms/plugins/fields/subform/src/Extension/Subform.php
Lines 261 to 262 in b945390
It just a note.
The PR is good as it is.
Labels |
Added:
?
|
This is a feature for sure. Needs to go to either 4.4 or 5.0 because this changes the behaviour of showon in the rest of core. Fields will now act differently from other places.
I'm also nervous about the fact the current showon implementation is not what user's believe. Being real most users believe that the field is removed from the form - not just visually hidden. We've regularly had people submit bug reports on that more general behaviour in components until now. Hiding the info in the frontend is definitely more in line what the end users believe but is still masking the fact it's not doing what they expect (it's also a far too big b/c break to just do what they expect). So yeah I'm just in two minds over this.
Whether this is merged or not we need to write some clear end user facing docs about what showon does and doesn't do. Because now we expose this through custom fields (I'd missed that 4.3 feature) it's going to be even more exposed to them than it has been in the past
Title |
|
I have tested this item ✅ successfully on 5fe8138
Labels |
Added:
Feature
PR-5.0-dev
Removed: PR-4.3-dev |
I want to address George @wilsonge comment:
Being real most users believe that the field is removed from the form - not just visually hidden
It is true that rather than hide the values on render, we should 'clean' the values on save.
That will prevent the rendering of values in the frontend when there should not be any
Category | Administration com_fields Front End com_contact Plugins | ⇒ | Administration com_categories com_config com_contact com_content com_fields com_finder com_installer com_menus com_templates com_users Language & Strings |
I synced my branch and thought it would sync with 5.0 and it did with 4.3, so I am going to close this one and redo another one with the changes I made since the original PR, which is not correct in the first place.
Status | Ready to Commit | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-09-09 22:35:58 |
Closed_By | ⇒ | obuisard | |
Labels |
Added:
Language Change
|
Hi
I tested from ms previous tests of showon for adminstrator especially for sleeping boxes and radio button which are more useful to me.
case-a-cocher:cas1
bouton-radio:btn1
liste:a
It seems to me that the test with "!" wouldn't work? so I didn't test everything at the end.
my tests :
box:value1=> The box has a value1
ok for check-box, radio-button, list :-)
box!:value1=> The box has no value1
nOk for case-a-cocher, bouton-radio, liste ZZ
box!:=> Box has a non-empty value (in this case, you can add an empty option to this 'Box' field).
nOk for case-a-cocher, bouton-radio, liste but I'm not sure I understand
box:value1[OR]square:value1=> Box a valeur1 or Square a valeur1
OK for case-a-cocher:cas1[OR]bouton-radio:btn1
box:value1[AND]square:value1=> Box and Square must have value1
OK for case-a-cocher:cas1[AND]bouton-radio:btn1
box:value1[AND]square:value1,value2=> Box has value1 and Square has value1 or value2
OK for case-a-cocher:cas1,cas2[AND]radio-button:btn1
Testing the wrong entries in the 'showon' parameter with values such as tada, box::, box:!, box:3:21, [AND]box:value3[OR]tada:2:3... doesn't generate errors in the front-end.
No errors (but it might be interesting one day to say so in the admin!)
No testing:
box:value1[OR]square!:value1=> Box has value1 or Square does not have value1
box:value1[AND]square!:value1=> Box has value1 and Square has a value other than value1
box:value1[AND]square!:value1,value2=> Box has value1 and Square has value3
Images



