[13]Additional logic in Module Manager Menu Item Assignment

[ewel]

Yes, I made the first versions for J!1.0.x. I have not looked at that version for many months since I upgraded to J!1.5 but it should still work fine with more or less the same functionality as the 1.5 version. I finally listed the module in the JED to share it with the community awaiting J!1.6, there seems to be a need for it. See http://extensions.joomla.org/component/ ... Itemid,35/.

This evening I was confronted again with the reasons why I made the module and proposed the new feature. I realised that by using JTags for horizontal navigation the ItemID system gets confused enough for modules not to appear where they should. ITags just links to articles and is not bothered about the ItemIDs that drive the menu assignment of modules. So I am planning to publish just about every module on my website through Mod OnAnyPage to make use of JTags and still see some modules where they should be.

This made me realise that the system of publishing modules should really be disconnected completely from the ItemID system except where admins optionally wish to use it. Unfortunately however the current menu assignment system is very user-friendly because it takes only a few clicks that anyone can understand. The question therefore is how to make a nice and simple alternative system which can assign modules to any page. If you look at my module, you will see that I evidently do not know the answer to that question yet. Having looked at MetaMod and the manual of the commercial Context Module (both do similar things be it with quite a different focus and methodology) I do not think a nice and simple solution has been put into practice yet by others. But perhaps someone else in this forum has a good idea?

[pmcnamara]

I need this functionality in J 1.5

Any ideals ?

[corrado444]

Hi, I think Mod OnAnyPage is a stroke of genius, but unfortunately I have to agree with you that it's not as elegant as it could/should be.
I finally wrapped my head around it, but the other day I was trying to explain it to a client and after a while I had to give up.

I think the problem resides in the fact that an additional module is needed, while the functionality should really be folded into the core and present in every module page (not that I expect you to do something like that, it's purely an academic flight of fancy).

The way I envision it is something along the lines of having another multiple select box right next to the current one that would allow the user to pick the links that should NOT display the module.
Essentially the reverse of what the module assignment select does now or an override if you will.

In that case the user would assign a module to every link in the site, move over to the next box and check the pages where the module should not be present.

As an aside, something like that is already possible by using conditionals in the index.php page in the template:

<?php if( JRequest::getVar( 'view' ) == 'frontpage' ) { ?>

But if there was something in the administration it certainly would be more accessible. It's already hard enough to explain how to modules work in Joomla as it is, I don't cherish the thought of explaining how an override would work.

But does my suggestion make sense? Having the override select next to the current one?

[ewel]

I have to agree that Mod OnAnyPage is not as elegant as module assignment to pages should and could be. It was always intended as a patch without hacking the core, and it cannot be more than that.
The way I see the future is that chunks of the xml and php of Mod OnAnyPage would be put into the core as standard options below the current module assignment. It's all GPL so the core team is free to copy and paste at leisure.
Short of that, I think it would be nice to have a module assignment component which in some way overrides the current menu assignment and allows more eloborate page-driven parameters to be set for any module.
The day I know how to do either I will do it, but for now I'm focussed more on quietly expanding the library of parameters. Meanwhile, hopefully someone more capable will come along and solve it all for everyone.

As to getting a client's head around it: I had problems myself in the beginning. Still, once you get used to it, it is not very difficult. It is just a box in a box. The inner box is the module content, and the outer box is to set where that is shown.
The inner box is the newspaper publisher (i.e. a module), who does not deliver himself. Instead he brings a stack of papers to the delivery boy, the outer box (i.e. MOAP), who gets on his bike and delivers a paper to each house with a subscription (i.e. selected pages).
So, the delivery address for the newspaper publisher is not the house of a subscriber, but the address of the delivery boy (i.e. a fake intermediate module position). The newspaper publisher does not even know who the subscribers are. The delivery address for the delivery boy is the house of each subscriber (i.e. the real module position). But the delivery boy has no idea what today's news is.

Ironically, in a perverted way you could say that this is a separation of model, view and content (wink).

BTW, what also helps is choosing easy names for modules and positions. For example, to publish a module with ID 34 and named 'Random Image' to the 'left' column module position, I would publish it to fake position 'left34'. Then I would publish a Mod OnAnyPage copy named 'Random Image (MOAP)' to the 'left' position, and I would set the position to be published to 'left34'.

The biggest problem that emerges from the support requests that I get is that templates sometimes have a layout for modules with fixed width, height, margins, padding, etc. As a result, when Mod OnAnyPage hides the modules to be displayed by it, and shows no content, the template will still see Mod OnAnyPage itself and apply the fixed css to create an empty space. Of course there are often ways around this, but sadly the level of complexity just becomes too high for many of those who decide to give Joomla a try, and who use a templated CMS precisely to avoid having to understand HTML, Javascript, CSS and PHP.
This alone is reason enough for me to keep hoping for a solution in the core. This, and misunderstanding clients, also means that the solution will have to be integrated within the module manager.

To this end I still have problems conceptualising how it could work. As you can see in Mod OnAnyPage, there are many possible options. I do not really see much future for a left side of the module manager stretching pages down with parameters. So, one could cut down the number of options, but then again people rarely complain about having too many options if they are presented in a user-friendly way. One could try and use collapsable panes like I am doing in the current MOAP version, but at the moment that does not fit into the layout and structure of the left side of the module manager. So, would it be better afterall to have a separate component for module assignment override settings?

[bradnana]

Take another look at the original white paper for this thread. I just revisited this and found that the screen shots I had included were no longer showing up, so I replaced them. I think they give a pretty straightforward visual conception of what we're all needing. Would a box like this one not work for you?

As far as having a second select box next to the current one, that seems unnecessary. A single box should be sufficient since a module can only be either on a page or not on a page. There's no in between. Right now, we can say, 'if a module is marked to be on a page, then it is not on any others.' However, what we're getting at is just having the option to also say, 'if a module is not marked to be on a page, then it is on all others. That's just an either/or scenario, and it can be accomplished with one box I think.

As a proof case, this is a basic functionality in Drupal, and it works well just like this.

I have to agree with you that this is something that should be in the Joomla core and not added as a module/plugin/etc... It really shouldn't be an added 'feature'. It's just common sense that got left out of the system!

Also see the original white paper for a workaround. It involves using an unpublished menu containing published menu items. I suppose it is best described as a hack since it exploits a small, insignificant loophole in the system whereby modules show up based on the published status of the menu item to which they are assigned without regard to the published status of the menu itself. Using it, though, is unhandy on larger sites because it involves creating a menu item for every new article created. But it can work in a pinch.

[ewel]

Your picture shows exactly what would be needed to make assignment of modules to menu items work properly. And that should in any case be included in the core.

However, that really is not enough in my view. For example, I am using mod_categories as a section blog replacement. With some layout adjustments this enables me to have a section blog (lookalike) to category blog to article sequence. But, this requires that I publish mod_categories only in section overviews and not on any other page within sections. Also this requires that a visitor who side-steps the menu system, through search or another component without a menu item, will still find mod_categories in the section overview (where leading and intro are set to zero so it would be quite bad if the module disappeared).

This cannot be done with menu-assignment of modules, and can only be done by additional logic to select pages on the basis of the request variables. In this case, that is option=com_content, view=section and layout=blog. I could hard-code the necessary condition into the template, but I think there should be options for this in the module manager.

Incidentally, I really do not see the point in having to make a hidden menu item for every possible page.

[bradnana]

Incidentally, I really do not see the point in having to make a hidden menu item for every possible page.

I am just making the point that is the only way to accomplish adding a module to all pages except a select few given the current system without using additional logic like your module. Basically, the module is set to appear on all menus except the unpublished one and then any pages that should not show the module are given a menu item on that menu. It's been a while since I've used this approach, but it worked well for me at one time.

[corrado444]

Actually, the fake menu approach was needed more in Joomla 1.0 than it is in Joomla 1.5. Not that at the moment I can remember why, but on a day when I had less to drink and I was a bit more focused on the problem I came to that conclusion (and I am sticking by it .

I wanted to point out that it was not my intention to criticize modonanypage in any way. It's been the answer to my prayers more than once since I was bale to make it work. In fact, my point was to agree with the author that this functionality should really be in the core.

As for my difficulty in having my clients understanding it, I have a couple of clients that have had absolutely no trouble with it (one of them even explained a couple of tricks I missed) but by and large it's often hard enough to have the majority understand how the regular module system works that adding MOAP on top of it would be futile.
I have some clients that have difficulty creating folders and sending emails.
My average client's understanding of computers in general seems to be more in the realm of Hal2000 than real computing. They basically expect the Joomla interface to read their minds and any thinking on their part is fuzzy at best.

In any event, we all seem to agree that what we need is nto roll some sort of module functionality improvement into the Joomla core. How can we go about this?

[bradnana]

Most of my work is custom coding and the like. I don't actually spend much time working with CMS apps, per se. When I do, it's usually Drupal, but I'm beginning to grow weary of the constant game of 'can't keep up for catching up'! I have recently returned to thinking Joomla is the best bet for the majority of my web site clients... often for the same reasons that corrado mentioned. In fact, I'd sell more site accounts if I could just focus on Joomla and get to know it better.

Having said that, I really have to switch gears when I start talking and reading Joomla-speak. So, help me understand this better. @ ewel, when you say,

"...this enables me to have a section blog (lookalike) to category blog to article sequence. But, this requires that I publish mod_categories only in section overviews and not on any other page within sections."

does it not work if you simply create a menu item for the section overview and then apply mod_categories to that menu? If so, you could use the hack that I noted above, i.e., just unpublish the menu if you don't actually need it.

And this...

"...this requires that a visitor who side-steps the menu system, through search or another component without a menu item, will still find mod_categories in the section overview (where leading and intro are set to zero so it would be quite bad if the module disappeared)."

I can see your point, but I thought I remembered that Joomla correctly renders module assignments even if a page's menu item is circumvented; such as through search. No? Of course, like you said, if a page has no menu item associated with it, that poses an entirely different scenario. In that case, the fault lies in the fact that Joomla's module assignment is rooted in the menu system to begin with.

On that note, it might be significant that Drupal's assignment relies on the node (content item) being viewed irrespective of the menu item associated with it. But that opens a whole 'nother can of worms!

It gets more and more complicated as we consider various scenarios, but I still think the most feasible solution is to include a simple EXCEPT method in the core. That may not be the solution for every possible site architecture configuration, but it should cover a large majority, and keeping it as simple as possible should make it easier to implement and more likely to be included in any core changes.

[ewel]

I am just making the point that is the only way to accomplish adding a module to all pages except a select few given the current system without using additional logic like your module.

I completely agree with that point.

Actually, the fake menu approach was needed more in Joomla 1.0 than it is in Joomla 1.5.

Very true. J1.0.x was a nightmare I thought, and J1.5 was a great improvement. So much so that no doubt there are many websites which really do not need additional page-driven logic.

I wanted to point out that it was not my intention to criticize modonanypage in any way.

Feel free to criticise! I know the module is far from perfect, it can never be more than a trick, and the truth is that I am an amateur not a programmer, but criticism is inspiration for improvement.

As for my difficulty in having my clients understanding it, I have a couple of clients that have had absolutely no trouble with it (one of them even explained a couple of tricks I missed) but by and large it's often hard enough to have the majority understand how the regular module system works that adding MOAP on top of it would be futile.

One of the MOAP users said that it was the most difficult module he had come across, and I can understand that. I am trying to make it simpler to understand but in ultimately there is only so much clarity you can create with a confusing work-around.

In any event, we all seem to agree that what we need is nto roll some sort of module functionality improvement into the Joomla core. How can we go about this?

I am also glad we are discussing this topic again!
I would be happy to spend time and work together with a programmer to try and create something for J1.6.
But, as said, I am still not sure what the interface would be like. Would one put in a few options? A lot of options? Would one put in a few options with a plugin trigger to allow plugins to insert many more options? Would one follow the MetaMod method and simply make a text field for filling in php conditions? Would one do that but provide a simplified language for conditions like that used in templates? Would it be an idea to show a site map made by an internal spider, and tick the wanted or unwanted pages? Etc.

So, help me understand this better. @ ewel, when you say,

"...this enables me to have a section blog (lookalike) to category blog to article sequence. But, this requires that I publish mod_categories only in section overviews and not on any other page within sections."

does it not work if you simply create a menu item for the section overview and then apply mod_categories to that menu? If so, you could use the hack that I noted above, i.e., just unpublish the menu if you don't actually need it.

One of the other oddities of Joomla is that you cannot create a section blog of category descriptions which are linked to category blogs. You can create a section blog of articles but skipping the category level is often unwanted. You can also make a section list of categories, but those are then linked to category lists of articles when you would want to have links to category blogs of articles.
So, my work around is the mod_categories module, but if I publish that to the section menu item, then the module should appear throughout the section unless and until I have another menu item pointing to a category or article in that section. So, I could create hidden menu items for every category, but it is much more precise if I use logic to check the option, view and layout request variables.

Another example for which I used MOAP while I am updating my website offline is that I wanted some modules to appear everywhere except on pages where I have demo modules running. I could create a hidden menu item for each of those articles. But it works so much better to just fill in the article ID and exclude that.
Also, I installed a brilliant new extension, blog calendar reloaded. That links to a page listing articles for a date or date range. I think half of those who maintain a Joomla website would not even realise they'd have to make a (hidden) menu item for that.
One of these days I should site down and see how I used my module, and write down those examples where I could not have achieved the same without additional logic.

As a side note, it would be good to note that Mod OnAnyPage is limited by menu assignment like any other module. So if there is no menu item for com_users, then like any other module MOAP may not appear on login, register or lost password pages.

Which reminds me: when I said I don't see the point of making hidden menu items I meant that I don't want to have to make a hidden menu item for pages like those of com_users; I don't want to have a menu item for those pages at all and I still want my site-wide modules there.

I can see your point, but I thought I remembered that Joomla correctly renders module assignments even if a page's menu item is circumvented; such as through search.

Joomla does not as such remember the menu item, but has JRoute to find it. Good extensions will make links using JRoute, which will attempt to add the appropriate ItemID. Once an itemID is added to the request you get the modules assigned to the menu item corresponding to that itemID. If the itemID is lacking, the right set of modules will not appear.

So, to see this for yourself, you could open your website without sef enabled. Go to a page with modules that are not site-wide, and note the itemID. Then take off the itemID in the address bar and see what happens. Or, copy that itemID, go to another page and paste it in the address bar to get a set of modules that belong to another page.

JTags for example, an otherwise excellent piece of work, does not properly link to itemIDs as far as I know. Since it is using com_search I suppose there is an issue with that too. But to be sure I have to check my memory by repeating an experiment.

On that note, it might be significant that Drupal's assignment relies on the node (content item) being viewed irrespective of the menu item associated with it. But that opens a whole 'nother can of worms!

That sounds like what I would like to see. For ease of reference I call it page-based assignment, but what I mean is that you can select on the basis of the component, view, task and other things that are put into the request for the page.
I have to admit to having zero experience with Drupal, so I don't know what sort of worms crawl out of the can. What issues are those?

It gets more and more complicated as we consider various scenarios, but I still think the most feasible solution is to include a simple EXCEPT method in the core.

I completely agree that this exception option has to be done anyway, but I also do think more should be done.

[Sphale]

The problem is linking modules to menu items. I want to have my custom built modules be used as menus, however I can't have my modules show up since it isn't a normal Joomla menu. And yes, I know about "all", but I have custom build modules that only go on selective pages. To fix this problem I believe we need to change/ fix the way modules are linked to. I believe we should be able to choose by article, category, and section like how we do with the menus.

[ewel]

I want to have my custom built modules be used as menus, however I can't have my modules show up since it isn't a normal Joomla menu. And yes, I know about "all", but I have custom build modules that only go on selective pages. To fix this problem I believe we need to change/ fix the way modules are linked to.

I am not sure exactly what you have in mind, but it sounds like you would perhaps be better off making a component? To my mind the objective is to have some precision with assigning modules to pages, not to use modules as pages (though as a side effect that might be possible).

I believe we should be able to choose by article, category, and section like how we do with the menus.

Agreed, and furthermore by component and some other things.

Incidentally, in J!1.6 there will no longer be sections but only categories on as many levels as you want. There will also be some changes in respect to managing modules, but I am not sure yet what and how.

[corrado444]

Actually, I just finished a Screencast on Joomla 1.6 new admin features and I was very happy to see they are addressing these issues with the modules. I could not test how the features worked because the site actually crashed in the middle of the podcast, but from the menu screen you get an idea of the possibilities.

Here are the links to watch the screencast:

http://www.conticreative.com/10-Minute-Joomla-Tips/

and:
http://vimeo.com/channels/10minutejoomlatips
http://www.[youtube].com/user/10minutejoomla
http://10minutesjoomlatips.blip.tv/

[ewel]

I think it was in the presentation by Andrew Eddie that I heard that the current module list in the menu manager will probably change. It is good to see that there is a 'hide' button, but to have a list of modules for every menu seems to be rather impractical. I think the average website will have more modules than menu's so it would be better to use the current place in the module manager for a list of menu items with radio buttons for each.

My ideal would be a component with lists of menu's, modules and pages (the latter perhaps as a result from a crawl) in which each item can be clicked. In the menu list there would be show or hide, in the module list there would be multiple select boxes to include or exclude menu items or other pages, and in the pages list there would be show or hide buttons. But, that's easier said than done!

[corrado444]

I always thought that the ideal system should have a pane just like the present one in the module interface but working in the opposite manner.
First select where to display the modules, then override the display in the next pane.

Eventually, it would not be a bad idea to have a further override in the menu, and I think that in the Joomla 1.6 demo I screencasted the admin features were rough enough that probably that's not going to be their final form.

But frankly, any improvement on the present system will be welcome.

[ewel]

But frankly, any improvement on the present system will be welcome.

Indeed.

I am not sure if it is a new thought, but I was just thinking that it would be really nice if the assignment logic was separated into plugins. Then the core plugin would deal with menu assignment, anyone could write an additional plugin for any component, for access levels, or any other set of criteria. Each plugin could automatically be given space for a small form below the menu assignment in the module settings, and JPane would come in handy here. Plugins would need to provide a little form for settings, and would need to be called during page creation to perform their own unique checks. The logic making use of plugins could then simply ask each plugin if a module should be shown, and show only if all plugins answer in the affirmative. By installing or ignoring available plugins, admins could make it as capable and complex or as simple and limited as they want.

[undercash]

Hi
I have been trying to do this setup

http://docs.joomla.org/Show_a_Module_on ... ected_ones

but without any sucess, anyone made it with this hack??

thanks

[corrado444]

I have used similar tricks with success. My advice to you would be to make sure the syntax is correct (I have often copied snippets that turned out to have a syntax error) and make sure that the ID's are correct.

You have to be especially careful about the itemid of the page you want to exclude. If you are trying to apply it to a section or category the syntax may be a bit different.
I am actually working on a repository of snippets like that one on my site. I have a dozen or so that are very useful, but first I have to create a site I can test them on. I had done so me really nifty coding on a client's template recently and then they decided to use a different template. Since the code is very dependent on the content id's is not something I can integrate elsewhere easily.

Keep on trying and post your code trying to be as precise as possible. You may want to create a new thread for that. Link to it from here.

[undercash]

I have been very carefull and tried several times ,different positions.. no good result

[gjones]

Just wanted to add my support for the need for this feature. It would certainly make life easier.

thanks,

[ewel]

If I could find an experienced Joomla developer to work with I'd happily implement my ideas about how it can all be done. Meanwhile..

You have to be especially careful about the itemid of the page you want to exclude.

In my experience it is best to leave the itemId alone. The itemId is related to a menu item. Joomla's module manager already has assignment to menu items, so hacking a module to insert selective code triggered by the itemId seems rather pointless.

Instead, use JRequest to find significant portions of the URL(s) you are targeting. With SEF URLs off, look at the option (i.e. the component), view, layout and task, and of course the id which often you will use in combination with checks for one or more of the other portions.

So, for example, suppose I had a component com_articles with categories and sections, and I wanted to target the blog views of 3 of the 5 categories in 2 of 3 sections. I would check JRequest for the option to find com_articles. If so, I would first check if the layout is blog. Then I would check the view to see if it is category. If it is, I would compare the category id with my list of targeted ids. I could also use the id (again from JRequest of course) to do a database query to find the section to which the category belongs so as to compare that with my list of target sections. Where you have a comma separated list of ids, it makes sense to convert that into an array and use in_array or loop through the array with for each.

Never forget to set the menu assignment in the module settings of the module you are hacking to all menus. In this way you can fully rely on your code without the itemId confusing things. If you are targeting a page with your code where the hacked module does not appear according to the itemId (which, again, is the menu assignment), then your code will never get the chance to do its work. Also, don't forget that pages of components for which you have no menu item will not have an itemId and therefore no module will be assigned to that page, with the result that your beautifully hacked code will never come into play. So, make sure there is a menu item for every component with output that you want to target, and assign your module to all menus.

Hacking and coding in this way can be fun if you feel it is easier to hack a module than to use OnAnyPage or MetaMod, but for existing options (OnAnyPage) and recipes (MetaMod) you may be wasting your time. By the way, the code of OnAnyPage and the site of Metamod contain a number of tricks that you can use as examples for your self-coded conditions. Even if you do want to write out the conditions yourself, then consider using one of these two 'intermediary' modules because unlike hacks you can switch them on or off. They both have a field where you can insert your own options. If you run into trouble and you need something of which you are confident that others may often need it too, then let me know and I will see if I can build it into Mod OnAnyPage with you as tester. The last time I checked, the developer of MetaMod was also helpful in creating recipes.

[corrado444]

Good post Ewel. I have been using both Metamod and OnAnyPage and I realize that targeting item IDs is a bit of a hack that may not survive subsequent edits. However, it's pretty simple to implement and at least gives you the functionality you need for the time being.
Then you can go and write better code for it once you know you are going to get what you need.

[yourmanstan]

I wrote the following tutorial that should help with Joomla 1.5. Very easy solution

Suppose we want to disable the left column for specific pages. The solution is to create a corresponding module disable position: "x-left". We then create a custom html module and title it "TURN OFF LEFT COLUMN" so that administrators will understand what it is. The title and text within the module do not matter so long as they provide sufficient explanation to administrators who may come across them. The module is then assigned to the menu items where we do not want to show the left column. We will then edit the index.php for the template as follows:

Usually the template code would be something like this:

Code: Select all

<?php if ($this->countModules('left')): ?>
<div id="left"><jdoc:include type="modules" name="left" style="rounded" /></div>
<?php endif; ?>

We will make a simple change to disable the module position when a module is assigned to the module disable position:

Code: Select all

<?php if ($this->countModules('left') && !$this->countModules('x-left')): ?>
<div id="left"><jdoc:include type="modules" name="left" style="rounded" /></div>
<?php endif; ?>

Once this is done, the left column will now be disabled on the individual pages we specify by simply assigning a module to the x-left position for those pages. We can also create corresponding disable positions for each of the other positions to allowing an override to disable any position on any page.

Since each of the positions begins with "x" they are kept together and at the end of the list (out of the way for the usual changes to the modules). Although this is quite a simple solution and is almost painfully obvious, I haven't seen it used on any major templating sites and it is extremely powerful and useful addition to any Joomla template. After writing this article I have found one alternative method to achieving this goal, however I believe this solution is more graceful, less processing, and does not require a programmer to administer once implemented

Posted a PDF of this tutorial here: http://www.bristleconeweb.com/images/st ... sition.pdf

About the author: Jonathan Stanley is a website developer and Joomla veteran at Bristlecone Web http://www.bristleconeweb.com