I don't know which steps are exactly needed to reproduce the issue.
This is what I did:
Saved.
Went to Content > Articles > Options button
Front end:
Same result with all selections below 25.
Changed to 25 or higher
First test Firefox. Second test Chrome.
Labels |
Added:
?
|
Made some investigations. This time with template beez3 because it doesn't use "chosened selects"
Primary reason for behavior above is article "Smart Search" inside category "Joomla!".
In article text there is plugin call
{loadmodule finder,Smart Search}
Module mod_finder has a line that loads "chosened selects".
JHtml::_('formbehavior.chosen', 'select');
When I disable the line
#JHtml::_('formbehavior.chosen', 'select');
no "chosened selects" anymore. NEVER while paginating through whole list with articles of category "Joomla!".
Even if article "Smart Search". is NOT in the displayed list you'll see sometimes "chosened selects" while paginating..
It looks like that category list is loading more articles than needed (?).
Or in other words: That too many articles than needed in list are sent through plugins somewhere.
A performance issue?
So its just an issue with the sample testing data?
So its just an issue with the sample testing data?
1)
I don't know. It's not forbidden to enter line
{loadmodule finder,Smart Search}
or any other module call like this that uses formbehavior.chosen in articles. Then you'll see described behavior with or without testing data.
It's not a problem for Protostar. There I will provide a PR (always "chosened style" in category list).
But Beez3 normally doesn't use "chosened selects". There it's a really strange behavior to have sometimes this or that style. I don't know a way to suppress already loaded formbehavior.chosen.
A way could be to use a special CSS class selector instead of "select" in all lines JHtml::_('formbehavior.chosen', 'select');
E.g. something like
JHtml::('formbehavior.chosen', 'select.chosened');
or
JHtml::('formbehavior.chosen', '.chosened');
Please advise! Should Beez3 use "chosened selects" ON ALL PAGES or not? Sometimes it's forced to use them sometimes not.
2)
See comments below headline
BUT (after reactivating line)
I think that's a performance issue. Why are articles sent through plugin events that are not relevant for the currently displayed list page?
Status | New | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-02-14 13:20:50 |
Closed_By | ⇒ | bertmert |
Addition 2:
Really strange. All I found out meanwhile: When "not chosened" JHtml method formbehavior.chosen is NOT called at all.
Other find:
Start with clean session:
Display # set to 25:
Order by title ASC (headline)
Order by title DESC (headline)