? Pending

User tests: Successful: Unsuccessful:

avatar infograf768
infograf768
15 Dec 2017

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.
screen shot 2017-12-15 at 09 07 06
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)
screen shot 2017-12-15 at 10 41 19

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.

avatar infograf768 infograf768 - open - 15 Dec 2017
avatar infograf768 infograf768 - change - 15 Dec 2017
Status New Pending
avatar joomla-cms-bot joomla-cms-bot - change - 15 Dec 2017
Category Administration com_associations com_categories com_content com_menus
avatar dgt41
dgt41 - comment - 15 Dec 2017

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:

  • easier and more semantic HTML (check how many useless containers we have)
  • more performant (faster) script
  • less prone to bugs (hopefully)

screen shot 2017-12-15 at 11 04 57

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

avatar infograf768
infograf768 - comment - 15 Dec 2017

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.
I hope we will get back to a display of the filters similar to what we have in 3.x, i.e the filter fields will keep showing until we clear them.

avatar infograf768
infograf768 - comment - 15 Dec 2017

In any case, if this is merged, I can do a round2 for the other components for which the attribute can work.

avatar dgt41
dgt41 - comment - 15 Dec 2017

@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.
It would be nice if we can normalise the code to reflect J3 and then refactor it to meet the new design/js

avatar C-Lodder
C-Lodder - comment - 15 Dec 2017

@dgt41 - I'd rather this was merged now so when the change is made, it's easier as all components will be consistent :)

avatar infograf768
infograf768 - comment - 15 Dec 2017

@C-Lodder
Will prepare round 2 for all remaining core components that permit.
Concerning the noresults attribute, com_associations is a special case that we will have to solve separately as defining $this->total when nothing is chosen for the itemtype and language filters gives a wrong query.

avatar Bakual
Bakual - comment - 15 Dec 2017

Imho there is no need for the noresults attribute as it only complicates things instead of making it easier.
We have to add the attribute to the XML and fetch the total in the view class only to replace a simple if-else clause containing a one-liner with an if clause in the view layout.

<?php if (empty($this->items)) : ?>
 	<joomla-alert type="warning"><?php echo JText::_('JGLOBAL_NO_MATCHING_RESULTS'); ?></joomla-alert>
<?php else : ?>

becomes

<?php if (!empty($this->items)) : ?>

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.
Besides that of course the message isn't related directly to search tools and also doesn't necessary have to be in the same "block". There may be other reasons why the list doesn't show results (permissions, no items in general, ...). So it doesn't make sense to shove that message into the searchtools JLayouts.

avatar C-Lodder
C-Lodder - comment - 15 Dec 2017

Not really too fussed, but given the choice bewteen the two, I actually agree with @Bakual

avatar infograf768
infograf768 - comment - 15 Dec 2017

@Bakual
please note that other stuff than noresults has been modified in searchtools. Specially the way to get some filters display separately from the others.
before this patch, it is the case aleady for client in languages installed, cache, modules and template styles. This new global search tools includes this by default, before the pr.
i corrected it here for com_associations.
we have to decide if we keep that new code or not as it can be totally separated in the global layout from the noresults.
or just come back to our good old 3.x searchtools

avatar infograf768
infograf768 - comment - 16 Dec 2017

@Quy
Let's 4.0 leaders decide about the noresults stuff before modifying the code.
The same code is also used in the global searchtools
https://github.com/joomla/joomla-cms/blob/4.0-dev/layouts/joomla/searchtools/default.php#L69

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.

avatar infograf768 infograf768 - change - 16 Dec 2017
Labels Added: ?
avatar infograf768
infograf768 - comment - 16 Dec 2017

Weird, just discovered the noresults AND separate filter code is already present in 3.8/staging...
It is used for cache, template styles, modules and installed languages.

avatar infograf768
infograf768 - comment - 16 Dec 2017

For com_associations, with the changed I just did, we do get the same html
<joomla-alert type="info" role="alert" class="joomla-alert--show">No Matching Results</joomla-alert> without using noresults.

avatar Bakual
Bakual - comment - 16 Dec 2017

For reference the PRs which introduced noresults into 3.6 and 3.7 respectively:
#9738
#10090

Still think this makes no sense.

avatar infograf768
infograf768 - comment - 28 Dec 2017

@wilsonge
What have you decided? See #19076 (comment)

avatar astridx
astridx - comment - 4 Mar 2018

I had this issue in com_menu while showing menu items of admin menus. After applying using this branch the was the correct text.
menus all menu items tes administration
menus all menu items tes administration 2

avatar astridx
astridx - comment - 4 Mar 2018

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.

avatar astridx astridx - test_item - 4 Mar 2018 - Tested successfully
avatar brianteeman
brianteeman - comment - 10 Aug 2018

@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.

avatar infograf768
infograf768 - comment - 12 Aug 2018

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.

We have now:
screen shot 2018-08-12 at 07 02 31

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.

screen shot 2018-08-12 at 07 04 36

avatar infograf768
infograf768 - comment - 12 Aug 2018

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.

avatar brianteeman
brianteeman - comment - 12 Aug 2018

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

avatar infograf768
infograf768 - comment - 12 Aug 2018

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.

avatar infograf768
infograf768 - comment - 13 Aug 2018

Closed as new PR available #21581

avatar infograf768 infograf768 - close - 13 Aug 2018
avatar infograf768 infograf768 - change - 13 Aug 2018
Status Pending Closed
Closed_Date 0000-00-00 00:00:00 2018-08-13 06:53:31
Closed_By infograf768

Add a Comment

Login with GitHub to post a comment