WordPress Trac: Ticket #13976: wp_nav_menu() uses IDs for menu-items preventing re-use on the same pagehttps://core.trac.wordpress.org/ticket/13976
<p>
Hello,
Working to replace my hand-coded menus with the new dynamic menus in Wordpress 3.0 I've noticed a problem: menu items generated with wp nav menu() are given a unique CSS ID. This prevents re-using the same menu on the same page (my menu appears in both the header and footer) while maintaining valid HTML.
</p>
<p>
To reproduce this problem, call the a menu twice in the same theme and attempt to validate the HTML (<a class="ext-link" href="http://validator.w3.org/"><span class="icon">​</span>http://validator.w3.org/</a>).
</p>
en-usWordPress Trachttps://core.trac.wordpress.org/chrome/site/your_project_logo.pnghttps://core.trac.wordpress.org/ticket/13976
Trac 1.0.1foolsrunFri, 18 Jun 2010 14:08:12 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/13976#comment:1
https://core.trac.wordpress.org/ticket/13976#comment:1
<ul>
<li><strong>keywords</strong>
<em>wp_nav_menu</em> added
</li>
</ul>
TicketfilosofoFri, 18 Jun 2010 14:20:26 GMTattachment sethttps://core.trac.wordpress.org/ticket/13976
https://core.trac.wordpress.org/ticket/13976
<ul>
<li><strong>attachment</strong>
set to <em>nav-menu-item-id-filter.13976.diff</em>
</li>
</ul>
TicketfilosofoFri, 18 Jun 2010 14:25:31 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/13976#comment:2
https://core.trac.wordpress.org/ticket/13976#comment:2
<ul>
<li><strong>keywords</strong>
<em>has-patch</em> added
</li>
</ul>
<p>
I've seen this complained about elsewhere, so we could probably use a filter on the id attribute (patch does that).
</p>
<p>
Otherwise, I don't know that we should try to ensure unique IDs in core: it's simple enough to get around the problem (make a new menu) that people using the same menu on twice on one page can add a couple lines to their theme's <tt>functions.php</tt> file if they really want to do that.
</p>
TicketfoolsrunFri, 18 Jun 2010 14:38:42 GMThttps://core.trac.wordpress.org/ticket/13976#comment:3
https://core.trac.wordpress.org/ticket/13976#comment:3
<p>
Am I understanding correctly that this would prevent ANY unique ID or class from being applied?
</p>
<p>
While I suppose that does solve the problem, it removes functionality afforded by having a unique element to each menu item. It seems to me that using classes rather than IDs would solve this problem while maintaining a unique identifier for each item.
</p>
<p>
Maintaining multiple menus with the same items in them seems like it defeats the purpose of having the menu defined in one place.
</p>
TicketfilosofoFri, 18 Jun 2010 15:00:08 GMThttps://core.trac.wordpress.org/ticket/13976#comment:4
https://core.trac.wordpress.org/ticket/13976#comment:4
<p>
What I'm saying is that this scenario--printing the same menu twice on one page--is unusual enough that we shouldn't try to handle it in core, but the attached patch makes it so someone who wants to can make unique IDs in just a few lines of code.
</p>
<p>
I concede that it might be better just to get rid of the id attribute altogether, but there's precedent for including them in the page- and category-listing functions.
</p>
<p>
If you really don't like it currently, pass your own Walker class to <tt>wp_nav_menu</tt>, or use regex to filter out the id attributes at one of the several filters the markup goes through before being printed.
</p>
TicketfoolsrunFri, 18 Jun 2010 15:13:47 GMThttps://core.trac.wordpress.org/ticket/13976#comment:5
https://core.trac.wordpress.org/ticket/13976#comment:5
<p>
What about allowing an arbitrary prefix to the IDs?
Instead of
</p>
<pre class="wiki">&lt;li id="menu-item-123"&gt;
</pre><p>
I could define in the wp_nav_menu() arguments that I want them to read
</p>
<pre class="wiki">&lt;li id="header-menu-item-123"&gt;
</pre>
TicketshidouhikariSat, 03 Jul 2010 18:59:50 GMThttps://core.trac.wordpress.org/ticket/13976#comment:6
https://core.trac.wordpress.org/ticket/13976#comment:6
<p>
what about not using ID at all? Use only classes, and if consumer wants an ID he puts hte menu inside a div or span.
</p>
TicketfilosofoSat, 03 Jul 2010 19:03:58 GMThttps://core.trac.wordpress.org/ticket/13976#comment:7
https://core.trac.wordpress.org/ticket/13976#comment:7
<p>
shidouhikari,
</p>
<p>
As I mentioned in my previous comment, there's precedent in the page- and category-listing functions, and for many people apparently it's important that <tt>wp_nav_menu</tt> be similar to them in output.
</p>
TicketshidouhikariMon, 05 Jul 2010 17:46:25 GMThttps://core.trac.wordpress.org/ticket/13976#comment:8
https://core.trac.wordpress.org/ticket/13976#comment:8
<p>
I see... but I still think it's easier and simpler to convert ids to classes other than parsing or using regex to fix. Wordpress have beeing losing quality in its standards and passing features for plugins to handle, which should be kept as standard defined by core.
</p>
<p>
We shouldn't receive poorly standardized stuff from core and spend precious CPU time to fix them, making results different from the standard.
</p>
<p>
Also, *in Wordpress* menus were always neglected and less used. Joomla themes for exemple use to have the same menu on top, left, right, etc.
</p>
<p>
There's no real need to use id when we have class, so why insist to use it? Why force users to be limited to use each menu only once per page, or force them to use tricky techniques to make it possible, if those thechies shouldn't be needed at all? It becomes more complex than needed, and throws the responsibility that should be from core to plugins, making it worse and worse.
</p>
TicketnacinTue, 06 Jul 2010 21:06:55 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/13976#comment:9
https://core.trac.wordpress.org/ticket/13976#comment:9
<ul>
<li><strong>keywords</strong>
<em>menu</em> <em>id</em> <em>css</em> <em>wp_nav_menu</em> removed
</li>
</ul>
<p>
I agree with shidouhikari. We allow the same menu to be used twice. For example, in the header and in the footer. My suggestion -- make it a class, but leave the ID for first usage.
</p>
TicketshidouhikariWed, 07 Jul 2010 04:56:27 GMThttps://core.trac.wordpress.org/ticket/13976#comment:10
https://core.trac.wordpress.org/ticket/13976#comment:10
<p>
Trying to make me cleaner.
</p>
<p>
Core devs shouldn't suggest what WP users should and shouldn't do. I can think it's not common, usual, recommended, etc enough to use the same menu more than once per page, but a site may require that feature, therefore I can't block a designer from doing it just because I don't need, I don't want or I don't like it.
</p>
<p>
If I can me it easy (not use blocking ID attribute at all and use only class attribute, or even better develop options to allow full customization of menus UL, LI, A, etc), why make it hard?
</p>
<p>
A use case is Joomla, where the same menu is used on 2 or even 4 places on the theme, with different styles. Wordpress just never used many menus because we didn't and don't have good menu generators, we barely could control pages order, and it's hard for themes to rely on plugins with proper menu generators.
</p>
<p>
The ideal solution would be having a UI to create a menu with its itens, including nested ones, having standard classes to point current page, post type, etc and their children, and allow us to set custom classes as we do with body_class, post_class, comment_class. Then the function to print the menu has a parameter to set its ID.
</p>
TicketnacinSun, 11 Jul 2010 02:13:14 GMTattachment sethttps://core.trac.wordpress.org/ticket/13976
https://core.trac.wordpress.org/ticket/13976
<ul>
<li><strong>attachment</strong>
set to <em>13976.diff</em>
</li>
</ul>
TicketnacinSun, 11 Jul 2010 02:29:17 GMTattachment sethttps://core.trac.wordpress.org/ticket/13976
https://core.trac.wordpress.org/ticket/13976
<ul>
<li><strong>attachment</strong>
set to <em>13976.2.diff</em>
</li>
</ul>
TicketnacinSun, 11 Jul 2010 02:36:54 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/13976#comment:11
https://core.trac.wordpress.org/ticket/13976#comment:11
<ul>
<li><strong>keywords</strong>
<em>commit</em> added
</li>
</ul>
<p>
Attached patch (13976.2.diff) uses filosofo's filter, and latches on a callback to then ensure we're only using the id menu-item-* once.
</p>
TicketnacinTue, 13 Jul 2010 21:31:01 GMTstatus changed; resolution sethttps://core.trac.wordpress.org/ticket/13976#comment:12
https://core.trac.wordpress.org/ticket/13976#comment:12
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
(In <a class="changeset" href="https://core.trac.wordpress.org/changeset/15407" title="Prevent the same menu item from receiving duplicate IDs if the menu is ...">[15407]</a>) Prevent the same menu item from receiving duplicate IDs if the menu is used twice. All menu items now get a class with their post ID; only the first item now gets an ID. fixes <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/13976" title="defect (bug): wp_nav_menu() uses IDs for menu-items preventing re-use on the same page (closed: fixed)">#13976</a> for trunk.
</p>
TicketnacinTue, 13 Jul 2010 21:31:22 GMThttps://core.trac.wordpress.org/ticket/13976#comment:13
https://core.trac.wordpress.org/ticket/13976#comment:13
<p>
(In <a class="changeset" href="https://core.trac.wordpress.org/changeset/15408" title="Prevent the same menu item from receiving duplicate IDs if the menu is ...">[15408]</a>) Prevent the same menu item from receiving duplicate IDs if the menu is used twice. All menu items now get a class with their post ID; only the first item now gets an ID. fixes <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/13976" title="defect (bug): wp_nav_menu() uses IDs for menu-items preventing re-use on the same page (closed: fixed)">#13976</a> for 3.0.
</p>
Ticket