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
[4.0] Searchtools: Normalise the use of "noresults" round1 #19076
Conversation
Thank you @infograf768 for this PR. One little comment here from me. First of all I'm ok with merging this in J4, but since we have a new design for the list views, which is not yet approved (image below) we will eventually end up redoing this part once again as the aim is to use custom elements for the search tools instead of the plain js script of the current implementation. The obvious reasons:
All and all let's merge this, as the approval of the design might take some time, and rework the UI implementation later on. Thanks again for this |
Unrelated to this PR, the new design proposed above looks like it has the same flaw imho that the present one (Table Options), i.e. it seems one has to click to get a dropdown of the filter settings. |
In any case, if this is merged, I can do a round2 for the other components for which the attribute can work. |
@infograf768 the new implementation (right hand side dropdown) cannot replicate the old behaviour as it will hide portion of the table (it get's worse for narrow screens). Maybe something that needs to be reviewed again, @ciar4n @coolcat-creations. |
@dgt41 - I'd rather this was merged now so when the change is made, it's easier as all components will be consistent :) |
@C-Lodder |
Imho there is no need for the
becomes
So I certainly would not use the noresults stuff in com_associations as it is not worth creating workarounds to replace such a simple code snippet. |
Not really too fussed, but given the choice bewteen the two, I actually agree with @Bakual |
'searchFieldSelector' => '#filter_search', | ||
'orderFieldSelector' => '#list_fullordering', | ||
'showNoResults' => !empty($noResultsText) ? true : false, | ||
'noResultsText' => !empty($noResultsText) ? $noResultsText : '', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
line 47 can be this: 'noResultsText' => $noResultsText,
'totalResults' => $data['options']['totalResults'] ?? -1, | ||
'noResultsText' => $data['options']['noResultsText'] ?? JText::_('JGLOBAL_NO_MATCHING_RESULTS'), | ||
'showNoResults' => !empty($noResultsText) ? true : false, | ||
'noResultsText' => !empty($noResultsText) ? $noResultsText : '', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here 'noResultsText' => $noResultsText,
@Bakual |
@Quy If it is decided to drop the noresults and keep the new way to separate filters, then we can make a full PR for that and drop this one. |
Weird, just discovered the noresults AND separate filter code is already present in 3.8/staging... |
For com_associations, with the changed I just did, we do get the same html |
@wilsonge |
I have tested this item ✅ successfully on 9a77da4 This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/19076. |
@infograf768 I have read and re-read this issue and I am sorry I just don't get what the problem is - other than some messages getting the wrong colour. |
This is quite old. It was, among other stuff, correcting the display of fields in multilingual associations component and normalising the noresult stuff. That last one looks like it is not desired, but correcting the display of fields in multilingual associations IS needed. The Type and Language fields are displayed on top of the searchtools instead of being on same level and to the left of the page as is done below for languages or templates, etc. |
It was also correcting the display of the menu items manager where the custom fields are stuck to the searchtools instead of aligned to the left. |
Can you then either close this and create a new pr to address those issues or resolve the conflicts here and update the original post and testing instructions |
I guess I may be able to do a new PR, but it would be the last on this matter as I did not get any formal reply. |
Closed as new PR available #21581 |
In 4.0 was added, but half baked, the use of the "noresults" filter attribute in Searchtools.
It is already working OK for Modules and Template styles.
To test as an example for modules, just select the Trashed status when no module is trashed.
We get a blue background notice.
But it was not implemented correctly for Menus, Menu Items and Associations, even after the merge of #19044
The issue are multiple but basically, searchtools in 4.0 changes the way to display separate filters from the basic filters for a component, not only the use of the "noresults" attribute.
In com_menus, it concerns Client and Menutype. In com_associations it concerns Itemtype and Language.
This PR corrects the display of the separate filters for these components (For com_associations for example, they now display left instead of right of the "Table Options"), enables correctly the noresults attribute for Menus, Menu Items as well as for Articles, Featured and Categories.
Hint for people using Patchtester: you may have to delete manually the file
.../administrator/components/com_associations/layouts/joomla/searchtools/default/bar.php
to test the correct display of the filters.Example for com_associations (could not get the new "noresults" there as getTotal errors)
It has not been decided yet if 4.0 should keep this feature in the future.
Therefore, it can be decided to merge or not until it is decided if we go back to the 3.x searchtools or not.