[#19723] - [4.0] Add view exclude option for modules in the assignment tab
- Closed
- 21 May 2019
- Medium
- Build: master
- # 19723
The issue:
A typical scenario I believe every Joomla users have encountered is: You have a module on the article list page(like Category Blog), but you don't want this module to also show on the article content page. However, since the article page inherits itemid of the blog page, the module will also show on it. According to Joomla's documentation, you can create hidden menu items for each article to avoid this, but I really don't like this approach, for two reasons:
1)It is a painful toil if I have hundres of articles;
2)The breadcrumb would be homepage>article instead of homepage>category>article
Possible solution:
Providing a multi select field for excluding or including com_content (+ 3rd party?) views.
Simplified check:
$option = JFactory::getApplication()->input->getCmd('option');
$view = JFactory::getApplication()->input->getCmd('view');
if ($option == 'com_content' && $view == 'category'){
// check include / exclude option value and add module or skip
}
What do you guys think about this feature? I think it could be very helpful on blogs or complex websites.
joomla-cms-bot
- | Labels |
Added:
?
|
||
franz-wohlkoenig
- | Status | New | ⇒ | Information Required |
| Build | staging | ⇒ | 4.0-dev |
| Category | ⇒ | com_modules Feature Request |
I think that it is must have feature!
@brianteeman Yes, I am aware of that and we shouldn't making extensions like the Advanced Module Manger obsolete by implementing every cool feature. But on the other hand, I think this specific feature would be a complement to the core functionality and would improve Joomla's blog capability.
Personally I'm -1 on this functionality in core. Module display is driven on menu item configuration, adding view configuration in the UI adds another highly complex layer of processing and storage. Not to mention that this effectively invalidates the existing ability to cache the database query results of determining what modules to display on a given page (as again this is menu item driven) as this result set would have to be post processed against request data, and I'm not a fan of making that performance sacrifice.
@mbabker Hm ok, isn't it possible to include the check within the menu item check, because that is the root of the issue? But I see, if we only use the item id for the cache, without using option and view parameters, we will have some trouble here.
But what would be a good practice for the end users? Implementing different position outputs as mentioned in one of the answers @ stackexchange?
Part of the reason plugin events exist around the module loading is so extensions can customize what is loaded. And there are valid use cases for it. But to efficiently use those solutions you have to in effect not use the caching system since the cache ID (and inherently query filters) in ModuleHelper::getModuleList() is based on the active user's groups, the menu item ID, the application ID (site/admin), and if multilanguage functionality is enabled then the active language (you couldn't cache/persist that result with request parameters efficiently, and that is in part what implementing this feature requires, without blowing up your cache store almost to a point where it makes using the cache store overkill). Or, your plugin fully replaces that query through the onPrepareModuleList event and as a result the responsibility of caching/filtering the loaded modules becomes entirely your responsibility.
I can't say I pay attention to the solutions for this particular issue or use case, I don't have workflows that call for it. So I don't know what a good end user solution is, but just at a technical level to me it creates more maintenance overhead and forces you to lose some performance oriented capability that would penalize larger sites.
Just to add too since I had some time to think on my drive in to work this morning.
You can still cache based on the existing query parameter, but then you're stuck plucking objects out of the result set in a post-processing step because there is no efficient way to write that query to be request parameter aware for a multitude of reasons. So you still have a performance hit in your workflow, maybe not as bad as not having a cache at all but it is there.
Again, not having touched any tools trying to implement these types of solutions, you run into problems with just view based filters. Take www.joomla.org as an example (just that one subdomain, not the entirety of the network). And for the sake of argument we'll even restrict this to the News area as that demonstrates possible issues quite easily. Note this is a site with monthly traffic in the hundreds of thousands of sessions/pageviews/etc. so performance is an important KPI here.
If the site were configured in a way where only the top level News area had a menu item (IIRC it is the category blog view, I'm not actually logged in at the moment to validate; for the record its child subcategories do have menu items as well), and we wanted different modules for the two subcategories (general news and release announcements), a view based filter wouldn't work because you are still on a category view, so now this filter has to become item ID aware too (item ID as in the content item's ID, not the Itemid menu item parameter).
That one change alone would basically mean you're better suited designing module assignment for content items versus menu items, but that's beyond the point. As a continuation to the above, assume you wanted different modules for the article view of the two subcategories, with this hierarchy the article view would presumably need to inherit the filtered category rules as well as those from the menu item itself to make things work (and at that point you're at three levels of inheritance and asking for trouble trying to merge the display rules correctly).
Either way it isn't technically infeasible to filter in this way, but to do it right requires a lot of effort and I honestly believe it would potentially result in managing module assignment being too complex of a UI to implement efficiently.
| Status | Information Required | ⇒ | Discussion |
| Title |
|
||||||
| Labels |
Added:
J4 Issue
|
||
| Title |
|
||||||
| Status | Discussion | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-05-21 08:00:30 |
| Closed_By | ⇒ | franz-wohlkoenig |
This functionality is already available with extensions https://extensions.joomla.org/category/style-a-design/modules-management/