avatar stAn47
29 Mar 2016

Steps to reproduce the issue

enable mod_languages with some languages

the chosen script selector on default mod_languages template to initialize the chosen javascript is loaded for every single select rendered on the page.

it's not a good idea to alter rendering of 3rd party code from within this template file and for this reason i would strongly suggest to change this to local class instead of any select of the page

current code:

JHtml::_('formbehavior.chosen', 'select'); 


JHtml::_('formbehavior.chosen', '.mod_language_select'); 

and adjust the class of the select drop down:

<select class="inputbox mod_language_select">

and adjust the chosen renderer to always check if we got any elements per the selector:

original code:

        jQuery(document).ready(function (){
            jQuery('" . $selector . "').chosen(" . $options_str . ");

suggested code:

        jQuery(document).ready(function (){
            var e = jQuery('" . $selector . "'); 
                        if (e.length > 0) e.chosen(" . $options_str . ");

broken selects where we do not want to render them

System information (as much as possible)

joomla 3.5

avatar stAn47 stAn47 - open - 29 Mar 2016
avatar andrepereiradasilva
andrepereiradasilva - comment - 29 Mar 2016

@infograf768 can you see this one? is this a bug?

avatar infograf768
infograf768 - comment - 30 Mar 2016

It is true that any module or component containing JHtml::_('formbehavior.chosen', 'select'); (not only mod_languages) will force all select boxes on the site to also display as chosen.

It is also true that this should be the choice of the template to decide or not to implement chosen.
This obvioulsy can be decided by overrides, mod_languages included.

Example using Protostar:
If I take off JHtml::_('formbehavior.chosen', 'select'); from mod_languages and I edit an article or edit a module (frontend) or display smartsearch, mod_languages dropdown will still be displayed with chosen as chosen is loaded by these.
If we follow this proposal (the code proposed works fine. I used mod_languages_select with an s), if nothing is loading chosen in frontend, mod_languages will be alone to use chosen.

I consider the possible proposed patch to \layouts\joomla\html\formbehavior\chosen.php a good new feature in any case.
If we do and PLT is in favour, then It would be sensible to not only patch mod_languages but all core tmpl using chosen.

My personal feeling is that a template designer should decide globally if chosen should or not be used for the template and make the overrides accordingly.

avatar infograf768
infograf768 - comment - 30 Mar 2016

After some discussion with @roland-d I found we have a much simpler solution for example with mod languages:

diff --git a/modules/mod_languages/tmpl/default.php b/modules/mod_languages/tmpl/default.php
index 83e5f2a..414d18e 100644
--- a/modules/mod_languages/tmpl/default.php
+++ b/modules/mod_languages/tmpl/default.php
@@ -13,5 +13,5 @@
 if ($params->get('dropdown', 1))
-   JHtml::_('formbehavior.chosen', 'select');
+   JHtml::_('formbehavior.chosen');
@@ -23,5 +23,5 @@
 <?php if ($params->get('dropdown', 1)) : ?>
    <form name="lang" method="post" action="<?php echo htmlspecialchars(JUri::current()); ?>">
-   <select class="inputbox" onchange="document.location.replace(this.value);" >
+   <select class="inputbox advancedSelect" onchange="document.location.replace(this.value);" >
    <?php foreach ($list as $language) : ?>
        <option dir=<?php echo $language->rtl ? '"rtl"' : '"ltr"'; ?> value="<?php echo $language->link; ?>" <?php echo $language->active ? 'selected="selected"' : ''; ?>>
avatar stAn47
stAn47 - comment - 30 Mar 2016

hello, let me explain the background:

we are developers of various extensions running on joomla and the "default mod_languages" template breaks our select drop downs. i know this can be handled via template overrides, but it's quite complicated or impossible to fix this once our customers install our extensions. what you propose is that we would automatically install the template mod_languages file to change the chosen selector to be more exact (using classes) and not that generic (using element type).

the fix in chosen.php is intended to fix a javascript error IF THE SELECTOR FAILS and returns no items for any sort of reason.

you are right, that there are more ocurrances of this code within the core joomla, but if they are loaded from components, the effect is not that destructive as if they are loaded from a module shown on every site's page.

other modules that include such generic loader for the chosen are:

everywhere else it's loaded within components' backend which should be all okay. we also use chosen within our extensions, but it's always crafted to meet the purpose:

  • either for multi selects
  • either for ajax driven searches
  • we strongly do not recommend to use it on mobile devices, since the browsers native rendering works much better

best regards, stan

avatar infograf768
infograf768 - comment - 30 Mar 2016

Also, advancedSelect is default, but we can use anything without changing the library:

if ($params->get('dropdown', 1))
    JHtml::_('formbehavior.chosen', '.mod_languages');
<select class="inputbox mod_languages" onchange="document.location.replace(this.value);" >

will also work as it is $selector that counts.

avatar stAn47
stAn47 - comment - 30 Mar 2016

i actually like the advancedSelect class which does the job and makes it quite consitent.

avatar infograf768
infograf768 - comment - 30 Mar 2016

This is what I propose:

I have seen the issue for mod_languages, smartsearch (finder) and edit modules in frontend.
I will try to make a patch for these.

In the meanwhile, you can propose a PR for the library as it would be independant.

avatar infograf768
infograf768 - comment - 30 Mar 2016

PR here #9671

please test

Note: Edit modules (frontend) is not in the scope of this PR.

avatar brianteeman
brianteeman - comment - 30 Mar 2016

Closed as we have a Pr for testing - thanks

avatar brianteeman brianteeman - change - 30 Mar 2016
Status New Closed
Closed_Date 0000-00-00 00:00:00 2016-03-30 15:05:43
Closed_By brianteeman
avatar brianteeman brianteeman - close - 30 Mar 2016

Add a Comment

Login with GitHub to post a comment