With a little more work, this could be more flexible to support any component parameters,

• thus useful to a lot more cases

Examples

showon_ext="global:some_param:0,1"
showon_ext="com_content:some_param:0,1"

...

Sample code

$gshowon = explode(':', $gshowonfield, 3);

// Get global config if first part 'global' otherwise it is component name
$extension = $gshowon[0];
$config = $extension == 'global'
    ? JFactory::getConfig()
    : JComponentHelper::getParams($extension);

// Get parameter value
$gsetting = $config->get($gshowon[1], null);

// Get showon values
$values = explode(',', $gshowon[2]);

thanks @ggppdk for your excellent suggestion!

I just changed my PR according to the code you suggested, moreover I changed the title, the change summary and the testing instructions.

i think this is very usefull thanks.

just one remark. i think this behaviour should be integrated in the current showon, not in a new attribute.

I wonder if that is such a great idea for core.

The showon feature was introduced to have a way of dynamically showing/hiding certain parts of the current form depending on parameters being changed at runtime. Eg a user enables one parameter and gets some related options instantely without reloading the form.
In the proposed case here it is different as the value will not change after the form is loaded. This is done solely at loadtime here.

At the same time this feature here could already be easily done with a custom formfield.

This would also encourage coupling between components. What's the use-case?

This would also encourage coupling between components.

This help in reduce configuration options. If we display all of the fields, then the coupling will be less because we display all of them ?
What if we remove the ability for components and only allow this attribute to use global config ?
is it more acceptable ?

What's the use-case?

This helps configuration UI be less clattered, and hide fields that are not used during configuration (ok i know you meant usage in core configuration, but this will be mostly useful to 3rd party extensions)

At the same time this feature here could already be easily done with a custom formfield.

you mean

• extend all Joomla form fields to add an attribute ?
• or do you mean create a single "wrapper" field that instatiate other fields ?

is making configuration simpler for the user a good purpose ?
this a trade-off, maybe it is not worth having,

still it feels like a natural extension of showon capabilities

My initial motive for this PR was to have a possibility for disabling the "usesecure" field in the mod_login module: this field is useless and probably misleading if you set "Force HTTPS" in the global configuration to "Entire Site". @conconnl suggested in the discussion about my PR #8619 that we should have a way to gray out or hide that "usesecure" field if the entire site is shown via HTTPS. Neither he nor I know about any other way to achieve this currently, so I implemented the new field attribute "showon_ext" (which I initially called "globalshowon" since it only coupled a form field with one or more global configuration items). Thanks to the suggestion of @ggppdk I enhanced this such that you can now couple a form field with global configuration items and/or configuration items of any component.

if it already known that this field should be disabled because globalOption = blabla, then why need to render this field at all? ?

I do not see a reason to use original showon here. Just do not render the field.
(btw "showon" not fastest script on the page when you have a loot fields in the form)

Yes this is the intention of "showon_ext": the field will not be part of
the form since there is no way to make it visible by changing any other
field in the form (in other words: the field is not rendered if the
conditions given in "showon_ext" evaluate to false).

Am 21.07.2016 um 09:57 schrieb Fedir Zinchuk:

if it already known that this field should be disabled because
|globalOption = blabla|, then why need to render this field at all? ?

I do not see a reason to use original |showon| here. Just do not render
the field.
(btw "showon" not fastest script on the page when you have a loot fields
in the form)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#11207 (comment), or
mute the thread
https://github.com/notifications/unsubscribe-auth/AH9KbRJuTL8qa1veIQudU43YO_R_TAcsks5qXyZUgaJpZM4JP-D_.

Am I correct that this can be used in a menu item options to show a field or not based on the components global options? If so then this would be very useful as we can greatly simplify the display of options in a menu item in the same way as I did for component options in an earlier PR

@andrepereiradasilva

I do not see a reason to use original showon here. Just do not render the field.

you are right , this PR does what you say,

it does not hide it, or disable it, instead it does not render it at all, see line:
https://github.com/joomla/joomla-cms/pull/11207/files#diff-9d799c43096f42c965b28c44a8d8a8b1R988

@jo-sf
i think the attribute name 'showon_ext' is confusing / wrong,
attribute name should be 'renderon':
renderon="..."

@ggppdk I would extend the formfield where I need that and add the check to it. I'm assuming it's only a few fields where this would be needed in an extension so it's only one custom field to make.

@Bakual
yes do it already ) i am using a showon replacement

@brianteeman
Yes, you are correct, the intention of this PR is to be able to not render form fields at all if they are useless due to global settings or settings within any component.

@ggppdk
I agree with you that the attribute name "showon_ext" is misleading since there is no way for the user of a form to make a field visible that is hidden due to e.g. any global setting (at least not by changing any other field in the same form as is the case with the "showon" attribute). The attribute name "renderon" matches what really happens: if the conditions given evaluate to True the field will be rendered, otherwise the field will not be rendered.

I therefore renamed the attribute to "renderon" and changed the initial comment including testing instructions accordingly.

This feature makes much sense,
into simplifying forms,

just one using it should not mark such depedent fields as e.g. required,

or otherwise the server-side validation should made aware of the renderon="..."
and avoid throwing an error

About the above, see similar discussion here:
#11243

Regarding the example form I used in my test instructions it shall be discussed whether the condition "global:force_ssl:0,1" is suitable. It is clear that showing the "Encrypt Login Form" field is useless if "Force HTTPS" is set to "Entire Site" (numeric value: 2). It is also clear that the "Encrypt Login Form" shall be shown if "Force HTTPS" is set to "Administrator Only" (numeric value: 1).

But what about the setting "None" (numeric value: 0)? In this case there is probably no server certificate for HTTPS available, otherwise I would assume that the administrator of the Joomla installation would have set "Force HTTPS" to "Administrator Only" (at least). IMO it makes no sense (from the security point of view) to let the user of a site log in via HTTPS whereas the user of the backend logs in via HTTP.

And at least currently there is no check whether HTTPS is available if the "Encrypt Login Form" field is set to "Yes" as is the case for the "Force HTTPS" field when changing it from "None" to any other value.

So my proposal regarding the "Force HTTPS" configuration is as follows:

• if set to "None" do not show the "Encrypt Login Form" field and do not show the "Secure" field in the menu item "Metadata" tab, moreover do not try to switch to HTTP when doing a preview from the backend
  • it cannot be guaranteed that HTTPS will work at all (probably never tested)
  • if the Joomla installation is reachable via a non-standard port and/or via HTTPS only the user will have given all necessary information (scheme, port) in the URL and Joomla shall not change scheme or port (see also #11213)
• if set to "Administrator Only" show the fields mentioned above and do the preview from the backend via HTTP links
  • doing login at the frontend (site) should send the login name and the password via HTTPS to the server, and since we know that's possible (setting "Force HTTPS" to "Administrator Only" is only possible if the check that HTTPS is available was successful) it should be used here as well
• if set to "Entire Site" do not show the fields mentioned above and do the preview from the backend via HTTPS links (default)
  • it's all HTTPS so we need not enable any option causing a connection being made via HTTPS

This is nothing to be added to this PR, instead it shall be considered when this PR has been accepted and the new feature is to be used e.g. in the mod_login module.

Applying my proposal to the test case given above would mean, that the attribute "renderon" should be set as follows:

renderon="global:force_ssl:1"

Doing so the "usesecure" field ("Encrypt Login Form" field) will be shown only if the global configuration field "Force HTTPS" is set to "Administrator Only" (numeric value: 1).

I have tested this item ✅ successfully on 18369bb

I have tested this item ✅ successfully on 21d3674

I have tested this item ✅ successfully on 21d3674

I have asked the PLT whether or not we should include this feature into the core.

i also have a similiar PR #12518 ? that intends to solve other issues (#12517), but also does something like this (not all)

What's the status here?

@mbabker @franz-wohlkoenig
Do you need any information from my side? Or is it about adding this feature to the core or not?

IMO this feature makes sense in that it allows to simplify forms and to hide fields that are unnecessary and probably misleading due to settings in another form, e.g. in the global configuration or even in another component. The only point to consider when adding this attribute to any form field is that this field must not be required - see also the comment from @ggppdk (23 Jul 2016).

@jo-sf thanks for Answer, i think @mbabker asked about "Core or not".

Well, it hasn't been touched in 6 months either and currently has merge conflicts. So if this is something being pursued it needs to be updated and get a fresh round of testing and review, otherwise it can be closed out.

@mbabker
Thanks for your feedback. Some minutes ago I merged my PR with upstream/staging and thus removed the merge conflict. In doing so I also adapted my PR to the general changes made in field.php in that all field attributes are now instance attributes and that the parsing of the "renderon" conditions is now done by a new method in helper.php as is the case with the parsing of the "showon" conditions.

I hope that testing this PR will work without any problems - my own tests were successful.

I have tested this item ✅ successfully on 75bc2fe

@jo-sf Test Instructions stay same?

@franz-wohlkoenig yes, the test instructions are still the same - but as I saw right now my PR is again out-of-date (just three days ago I merged it with upstream/staging).

its not really a problem for the base branches to be out of date. its only a problem if there is a merge conflict

@brianteeman thanks for your notice, but when I saw it I had already merged my PR with staging...

@jo-sf Test stopped cause couldn't connect to HTTPS. Test instructions are perfect, thanks.

System information

3.7.3-dev (latest nightly build)
Multilanguage Site
macOS Sierra, 10.12.5
Firefox 53 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

@jo-sf how to go on with this PR?

@franz-wohlkoenig actually I don't know how to proceed with this PR. It seems as if there is currently no great need for such a feature, but when I can continue one day with the secure login topic

• switching to HTTPS when logging in at the frontend and HTTPS is available
• switching back to HTTP when logging out at the frontend
• using non-default ports für HTTP and HTTPS

(I probably missed some of my issues now) the "renderon" feature would be of some help since it can be used to hide fields in the configuration that are not needed due to the setting of other fields. Well one simple example for using that feature I've already given in the test instructions for this PR - IMO it makes no sense to enable secure login in any mod_login module as long as no HTTPS is available (there is a test in the backend such that you cannot switch to HTTPS unless you have HTTPS available but no such test is done when changing the mod_login setting).

Maybe there are some other places when configuring modules or components where a dependency between any global configuration item and a configuration item for that module or component exists. Any such suggestions are welcome!

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/11207

closed as stated above. It can always reopen if needed.

What a shame this is closed. It would be really useful to me right now. Use case exactly as stated in one of the comments above - to hide a menu item setting if a global setting has disabled it.
In particular I have a global setting with three possible values: 0=hide, 1=show, 2=show & link
In the menu I only want to display the option if the global setting is >0 and to have three options: ''=use global, 1=show, 2=show & link
In other words I want a global setting to turn off the ability to override it at the menu level. But if the global setting is on (1 or 2) then I want the menu to have the option of using the global setting or overiding it to 2 or 1.
I suppose I could implement it as a custom field, but this is not the first time I have wished for this logic and it seems like core functionality to me.
Bring back "renderon" !