-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
Remove chosen from com_search #24623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Chosen is not accessible so we shouldnt use it unless it offers something useful. In the search component in the front end there are potentially two lists Ordering and display # Neither of these require or benefit from chosen so this simple PR returns them to regular and accessible lists
|
I have tested this item ✅ successfully on aa618b8 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24623. |
|
I have tested this item ✅ successfully on aa618b8 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24623. |
|
RTC This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24623. |
|
Whats the reason to remove this without needs? The only thing what could happen is to break sites that expect chosen. |
|
It is removed from this page because chosen breaks accessibility and we dont need any of the added features of chosen for the select lists here. It cannot break an existing site |
|
We don't in this view but the long standing opinion is removing this can affect ssites that were using it on other pages without the include. This was how we ended up basically rolling out chosen into every view in the backend (as well as the consistency argument). I agree with @HLeithner that this is something not to be fixed in 3.x sadly |
I don't follow this logic. We are talking about a component so how it can affect other pages that are not com_search |
|
No it doesn’t affect other pages but it does affect modules and plugins on that page For the record I disagreed with this logic at the time. But it’s long been made standard. And especially given we should be trying to 3.x towards more support only mode in anticipation of 4.0 it doesn’t make sense to make changes like this |
|
in which case the user can create a template override |
|
@wilsonge : What kind of plugin? For which modules? Some example? Specifically? It was a very bad code! |
|
it was introduced as a fix #1653 for some issue, which no one know anymore |
|
I'm closing this because of the statements above not breaking user templates. |
|
Shame that accessibility doesnt matter |
|
RTC This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/24623. |
|
Thx |
|
thanks |
Chosen is not accessible so we shouldnt use it unless it offers something useful.
In the search component in the front end there are potentially two lists Ordering and display #
Neither of these require or benefit from chosen so this simple PR returns them to regular and accessible lists
Pull Request for Issue #24469