By jhriggs on

I am happy to announce menus.module. This module allows site administrators to create customized hierarchical navigation menus in the same style as the 4.3.0 integrated admin menu.

The menu structure is formed by a taxonomy vocabulary. Each term in the vocabulary becomes a menu item that can be assigned an arbitrary URL, on- or off-site. Terms with children become submenus that can be expanded/collapsed or set to always be expanded. The goal is to allow administrators to create site navigation that is a little more customized/personalized than the simple link_page() function and that is a little more dynamic/functional than static HTML/PHP code.

A menu can be created from any or all vocabularies. Each vocabulary creates a separate menu block that can be independently positioned and/or only displayed on certain pages as desired.

Following the example of my previously announced module, quotes.module, installation is all web based (no .sql file).

You can find the module on the projects page.

Comments

adrian’s picture

adrian commented

I have been watching this module be developed.. and i can definately see myself using it for my future developments.

admin@deepsilence.net’s picture

admin@deepsilence.net commented

I was just trying to figure out how to hack this together, and it seems like I don't have to after all. Nice. Will definitely be using this, thank you.

jhriggs’s picture

jhriggs commented

Let me know if you have any problems or suggestions.

Anonymous’s picture

(not verified) commented

works like a charm!

dries’s picture

dries commented

I explored the module a bit but it didn't live up my expectations; why bother with taxonomy when all I want to do is add a few menu items to the navigation block?

In fact, I even failed to add a single taxonomy based menu item; the GUIs and the approach's complexity confused me.

Also, despite the comment in the code, the code doesn't follow Drupal's coding standards at all.

moshe weitzman’s picture

moshe weitzman commented

I experienced a perfect install and easily figured out how to add my vocabularies.

jhriggs’s picture

jhriggs commented

Glad to hear it. Thanks, Moshe.

jhriggs’s picture

jhriggs commented

I explored the module a bit but it didn't live up my expectations; why bother with taxonomy when all I want to do is add a few menu items to the navigation block?

That is not the goal of this module. The goal is to provide complete menus, not additions to the navigation block. An administrator can create a completely customized menu to suit the basic navigation needs for his site. The main navigation/admin menu will still be used for administration and content management. For a simple example of its usage, you can see it on my test site.

In fact, I even failed to add a single taxonomy based menu item; the GUIs and the approach's complexity confused me.

Install the module. Create a taxonomy with the items and structure you want to use for the menu. Go to "administer > menus > create" and select your menu taxonomy. In "administer > menus > overview" you can edit the links for each menu item and indicate whether or not it should always be expanded. Your suggestions are welcomed for a less confusing implementation; however, everyone that I have talked to about it thought it was straightforward and understandable.

Also, despite the comment in the code, the code doesn't follow Drupal's coding standards at all.

Now this, I have to admit, is something to which I take offense. I just reread the coding standards, and am amiss to find any deviations. I am very interested in what "doesn't follow Drupal's coding standards at all."

killes@www.drop.org’s picture

killes@www.drop.org commented

1) You break lines to 80 columns. We don't do this.
2) You indicate the end of a function with // function foo
3) you use <<< syntax

Don't take it to serious, it is a contrib module after all.
But you could remove that note from the code. :)

--
Drupal services
My Drupal services

jhriggs’s picture

jhriggs commented

None of those items are addressed in the coding standards. As such, they can't be not following the coding standards.

1) Actually, I break all my lines at 70. This makes for code that is much easier to read IMNSHO. I do all of my development in emacs via an ssh connection. Without wrapping, development would be a nightmare. There is nothing worse than trying to read or edit 200-character-long lines...in a GUI or not.

2) Is that really a problem? I find it quite helpful when all you see is a stray closing '}' to know to what it belongs. It also makes it very easy for finding the beginning and end of every function.

3) There are good arguments for and against HEREDOC syntax. I acknowledge that. When it comes to readability of code in which you are writing markup, though, I believe that HEREDOC has a great advantage (again IMNSHO).

I find it significantly easier to read this: 

$theOutput = <<<EOT
<p>
  Here is a paragraph that I will try to make fairly long just as an
  example of the different ways to output data in PHP.  The HEREDOC
  syntax makes it much easier to include "quotations", write <a
  name="foo">tags</a> (without leaning toothpick syndrome), and still
  handle $variables.
</p>
<ul>
  <li>A list Item.</li>
  <li>Another item.
    <ul>
      <li>A sub item</li>
    </ul>
  </li>
</ul>
EOT;

than it is to read this (which is what we have in most of the code): 

$theOutput  = "<p>";
$theOutput .= "Here is a paragraph that I will try to make fairly ";
$theOutput .= "long just as an example of the different ways to ";
$theOutput .= "output data in PHP.  The HEREDOC syntax makes it ";
$theOutput .= "much easier to include \"quotations\", write <a ";
$theOutput .= "name=\"foo\">tags</a> (without leaning ";
$theOutput .= "toothpick syndrome), and still handle $variables.";
$theOutput .= "</p>";
$theOutput .= "<ul>";
$theOutput .= "  <li>A list Item.</li>";
$theOutput .= "  <li>Another item.";
$theOutput .= "    <ul>";
$theOutput .= "      <li>A sub item</li>"
$theOutput .= "    </ul>";
$theOutput .= "  </li>";
$theOutput .= "</ul>";

Not to mention that (without going through and adding all the newlines in the second form) the HEREDOC syntax will output final HTML that is much easier to read, debug, etc., than all the string concatenation.

I realize this is not a very serious issue. All programmers have specific preferences. Contrib module or not, though, being told that you are not following the standards when you took pains to follow them to the tee is a slap in the face.

Steven’s picture

Steven commented

I think the main argument against heredoc is that you either have to match the indentation of the program (resulting in odd indentation in the output) or ignore any PHP indentation (resulting in code that is hard to read).

If you use single quotes to enclose your strings, you'll have no problems including regular double-quotes in your strings, though you'll need to use concatenation for variables (in fact this is not too much of a problem, because most variables are passed through t() for translation anyway).
Though in fact, I believe you're free to surround your HTML attributes with single-quotes.

Personally I think 'text is hard to read when non-wrapped' is a non-argument. 80 characters is an arbitrary limitation based on ancient text-modes. My screen can fit a lot more. And even if you're ssh'ing, you can resize your terminal to any width. Why not 60 chars? Why not 90?
I'd expect editors like emacs to at least have a smart wrapper for programming code, which deals with correct indentation.

jhriggs’s picture

jhriggs commented

I agree that there is a dilemma when it comes to indentation using HEREDOC syntax. In my experience, though, it is not difficult to see where HEREDOC starts and ends. The start is clearly identifiable with the mark (i.e. "<<<EOT") and the end is easy to find in that you will have the closing mark ("EOT;") at the beginning of a line all by itself.

I don't believe, though, that wrapping is a non-argument. On my laptop I am limited to a certain number of columns. Obviously, I can only resize the terminal within the bounds of the screen. I agree that the column at which the code is wrapped can be somewhat arbitrary. I use the default of 70 so that no matter what terminal I am (or anyone else is) using, whether it can only handle 72 columns or 720 columns, the code will be easy to read and navigate.

Emacs does have a smart wrapper that indents code with hard wrapping. Personally, I much prefer it this way. When you don't have a mouse to navigate a long line of code, it can be a real pain to move around with command keys.

dries’s picture

dries commented

I agree with UnConeD. In my opinion code wrapping is mostly a non-argument. Frankly, my editor does a better job wrapping code/text than you do: it lets me customize the wrapping to both my working environment and my personal taste. The code is also a tiny bit more efficient because of the reduced parsing overhead and less string concatenations. Fortunately, we can agree to disagree. ;-)

ax’s picture

ax commented

as are others. see the thread starting at Re: [drupal-devel] coding style (was: [drupal-user] heredo) for an earlier discussion.

i repeat my point stated there:

shouldn't it be possible to reach agreement in that, to make drupal code easier to understand, maintain, and be less error prone, drupal coding style should be changed in the 3 points mentioned (

  • using double quotes for strings containing html with double quotes
  • not using heredoc syntax / multi-line strings
  • not breaking long lines

)?

we should definitely review the Coding standards chapter.

dries’s picture

dries commented 
$ ./scripts/code-style.pl modules/menus.module | wc -l
    297

Also, we never write $myFirstVariable. We always write $my_first_variable.

As Gerhard pointed out, don't take this to serious unless you want your module to become part of the main distribution (Drupal core). It is your module, you have to maintain it, so feel free to do it your way. :-)

jhriggs’s picture

jhriggs commented

I'm not taking it too seriously...I know it's no big deal. :-)

I recognize that the code may not match that of core, but my point is that it follows all of the standards as described in the handbook. There is no convention for variable names (or any of Gerhard's 3 points) mentioned there. I followed the coding standards as they are prescribed. If they don't match what you are expecting, they need to be updated. If there had been a convention for variable names, I would have used it, whether I liked it or not. I am one who is strict about coding standards...I love them and hate projects that don't have them.

So, thank you for having them, but if they aren't the REAL standards (as indicated by your perl script), let's get them updated, and my code will be some of the first to conform. :-D

dries’s picture

dries commented

I'm not the author of the coding guidelines in the Drupal handbook. I measure the conformity using the Perl script and by looking at the code. Maybe file a task so we don't forget to update the coding guidelines?

adrian’s picture

adrian commented

I for one like all of those things.
I am not to0 caring about the 80 column line breaks, but ending the functions with the comments and using the <<&lt syntax really appeal to me from a readability point of view.

dries’s picture

dries commented

Thanks for the clarifications. I got it to work now. I didn't realize your module created a new block until I read your follow-up and saw your test site. I thought new menu items were going to be added to the existing navigation block.

Still, I don't see why I need a vocabulary to create a menu ... Say, I wanted to add a link to my "about" page in the newly created menu. How would I do that?

adrian’s picture

adrian commented

in your menu taxonomy , add an 'about' term

then in the menu admin screen , next to the about item , you type in the page it links to .. which might be /about , or /node/view/12 .. depending on where that node is.

dries’s picture

dries commented

So you are telling us that setting up a vocabulary with an 'about' term just to create an 'about' menu item is simple? First, people have to build and maintain the menus in what seems to be (and should be) an unrelated part of the administration pages. I find that cumbersome. Second, in the taxonomy pages, people are overwhelmed by terminology, features and settings that have nothing to do with menus -- and that isn't even useful to build menus. Usability anyone? In short, make a custom, optimized GUI for administering menus.

jhriggs’s picture

jhriggs commented

That was my original plan, but all I found was that I was duplicating code that already existed. Taxonomies already handle hierarchical structures, names, descriptions, etc. Why duplicate all of that when all I want to do is add a couple of bits of information to each term? We spend a lot of time, it seems, discussing not reinventing the wheel. Why reinvent it for this?

Now, that said, there may be a more integrated/elegant way of implementing this functionality. Perhaps the vocabulary and terms can be modified from within this module using taxonomy_* functions. (I would rather not go straight to the tables.) I have not looked into this as of yet. At this point, this met my needs and it works...and it IS the first version. Until you put it out there for people to try and critique, how would you know what others think about the usability and interface? The feedback I got from people who saw it before being committed to CVS thought it was easy enough. Suggestions and contributions are always welcomed, so I thank you for your input, Dries. :-)

dries’s picture

dries commented

In essence there are two new things I'd like to add to Drupal 4.4.0: good file management (so we can add images and documents to posts) and a good menu system (so people can easily add and remove navigational elements). My main criteria are user-friendliness and code quality. For both criteria, simplicity is key.

Gabriel R.’s picture

Gabriel R. commented

In essence there are two new things I'd like to add to Drupal 4.4.0: good file management (so we can add images and documents to posts) and a good menu system (so people can easily add and remove navigational elements).

And I will love you for that!

osku’s picture

osku commented

And I would like to see that once could easily also delete those files :)
After a specific time they would be deleted automaticly or one could remove them with a simple form in some admin menu or something like that.

boris mann’s picture

boris mann commented

And again, a ton of comments. Install was a pleasure and easy as always.

CSS classes with spaces in them breaks a bunch of stuff: including sending IE5 on the Mac into berserk-o mode. I see what you're trying to do. The best way to accomplish this with CSS is to have class="menus" and then id="(menus-taxonomy)". Class is if you are going to have multiple (as could be the case) and id is for when they are going to be unique per-page -- since the block can only show up once, this is also the case.

Should use theme_item_list: of course, no hierarchical support until someone, somewhere approves my patch that supports it...

I currently have secondary links in xtemplate moved to the side block of my site to solve what you have here -- this is much more flexible.

jhriggs’s picture

jhriggs commented

CSS classes with spaces in them breaks a bunch of stuff

I am not specifying a class with a space in it. There is no such thing. This is how one specifies more than one class in CSS. (See section 5.8.3 of the CSS spec.) I am creating a div with both classes, menu and menus-menu, so you could have a selector in your CSS that looked like this: div.menu.menus-menu. The menu class gives the style of the 4.3.0 navigation menu. The menus-menu class gives you a little more control (if needed) of the look of the menus created with this module.

I don't mind the idea of a separate ID (i.e. menus-<tid>) for the separate menus, though, if anyone sees interest in individually controlling the style of each menu. It seems like it might be overkill.

Should use theme_item_list

True. I am attempting to emulate the look and feel of the navigation/integrated admin menu, though, which does it this same way.

Mike@frazierhome.net’s picture

Mike@frazierhome.net commented

Very nice, and I've implemented this module on my website: FrazierHome.net For me this helps take some complexity out of all of the boxes I used to have for various vocabulary terms.

I did have a problem with this on the Interlaced theme. The way the menu worked (the bullets) were different than the bullets on the admin menu. To fix this, I modified the module to do a <div id="menu"> where the code originally did <div class="menu menu-menus">.

jhriggs’s picture

jhriggs commented

This seems to be browser-specific. (See comment from bmann below.) What browser are you using?

Perhaps I won't try to use two classes for that div. Instead I will place a div inside another div, one with class menu, the other with class menus-menu.

Mike@frazierhome.net’s picture

Mike@frazierhome.net commented

I was using IE 6 on Windows 2000. I didn't try it on Mozilla, so can't tell you if its a browser issue or what.

The key for me was it had to be an id= and not a class= . When it was class= it seemed to get ignored.

adrian’s picture

adrian commented

Your site's navigation is exactly the kind of menu that this module makes easy to accomplish.

Sure, it's not OPTIMAL (regarding having a seperate taxo screen) .. but it still works.

jsloan’s picture

jsloan commented

Echoing others on this page I want to thank you for creating this module. I was ready to tackle the problem but your contribuion fits perfectly into what I needed. I was able to add a function to create a horizontal menu that I can use in my theme to give top level navigation - I'm going to add DHTML drop-downs for the next level sub menu items. Your implementation of the taxonomy and your coding make this very easy to extend. If others are woring on a similar function for this module then let's share ! ! !

BTW - There must be a "menu fever" going around - because this is now a thread on drupal-devel [RFC] navigation.module ... this seems to duplicate what you have done, or is the difference greater than I realize?

jim

jhriggs’s picture

jhriggs commented

Thanks for all of your comments, Jim! I'm glad you found it useful.

Yes, there is a navigation fever of sorts lately. In the past few weeks there have been several navigation-related modules that have popped up. I think everyone has picked up on the fact that this seems to be a big focus of users...and something that is needed but lacking in core.

I wrote this to fulfill a specific need that I had, whereas the navigation.module discussion, I believe, will become more of a core focus for 4.4.0. Hopefully some of the better bits and pieces of all of these modules will be incorporated to create one flexible, powerful, integrated navigation system.

TomMynd’s picture

TomMynd commented

I installed the module without any problems. After reading your instructions a second time I was able to setup a simple menu. :) I must admit: Good job!

But I have one question: Is it possible to use the Permission for some Menuitems or complete menus?

Currently I'm building a litte site, that should only be seen, when a user has logged in. But the menu is shown to an "anonymous_user". Did I miss something or is this not implemented??

Donovan@drupal.org’s picture

Donovan@drupal.org commented

This module, with the change suggested by TomMynd would fit my needs perfectly. I think it would also significantly improve the applicability of the module by enabling quasi-customizable (role/permission-based ) menus. For example, in my case it would allow me to present a webmail access link only to certain members of my community to whom I have assigned username@mydomain.com email addresses. Any chance of seeing this modification?

niko’s picture

niko commented

Assume I have menu tree like

-foo
--bar
--bar2
--bar3

I assign some URL to every menu item including foo.
But when I click foo menu is not expanding :-(
Is it limitation or bug?
Can menuitem be expanded and simultaneasly open some page?

Regards,
niko

rotaiv’s picture

rotaiv commented

I just installed and configured the menu module. On the front page, I have two menus that expand with sub-items. If I click on one of the menu's it expands and shows the sub items. However, as soon as I click on one of the sub-item, the menu collapses. I tried checking the "Always expand" but this does not seem to help. Is there something else I need to do?

jxs2151’s picture

jxs2151 commented

It was fixed by matthias and uploaded to the CVS.

rotaiv’s picture

rotaiv commented

I removed the previous menus module then installed the latest one from CVS:

$Id: menus.module,v 1.9 2004/03/11 15:41:14 mathias Exp $

Now I get the following errors when I try to create a new menu:

warning: call_user_func_array(): First argumented is expected to be a valid callback, 'pager' was given in /var/www/web/includes/theme.inc on line 219.

warning: call_user_func_array(): First argumented is expected to be a valid callback, 'page' was given in /var/www/web/includes/theme.inc on line 219.

I used /admin/system/modules/menus to unintsall the old one; copied to new file to the modules directory; then used the same URL to install the new one.

Almudena’s picture

Almudena commented

sorry, I post the comment in the wrong message