Let me tell you why this is a major headache. When you use
wp_nav_menu()to create a navigation menu in a theme, it creates a nice menu using all the options you set with regards to classes, IDs, format – it allows you to style it nicely with CSS.
If for whatever reason there is no menu defined, WP attempts to create a menu based on a function in the
fallback_cboption, the default is
wp_page_menu()which generates completely different markup and classes, most of which cannot be edited at this point from the
wp_nav_menu(), thus rendering any styles for the proper menu redundant.
The only way around this is to effectively style your menu twice, or create a new fallback-callback which emulates
wp_nav_menubut with he default pages.
And? Why is this a problem? It’s relatively easy to add the extra classes to your CSS.
It may be to some extent, but picture this scenario:
// Creating a menu with the most default of settings:
// header.php wp_nav_menu( array('theme_location' => 'my_theme_top_menu') ); // functions.php register_nav_menus( array('my_theme_top_menu' => 'Top Menu' ) );
Here’s the markup produced with a menu defined:
<div class="menu-main-menu-container"> <ul id="menu-main-menu" class="menu"> <li id="menu-item-102" class="menu-item menu-item-type-post_type menu-item-object-page menu-item-102"> <a href="http://www.domain.co.uk/">Home</a></li>
Notice lots of useful class names and IDs on the menu items, and the
.menuclass on the
<ul>tag. Now take a look at what happens if you don’t define a menu in wp-admin:
<div class="menu"> <ul> <li class="page_item page-item-51"> <a href="http://www.domain.co.uk/bligs/">About Us</a>
All the CSS has completely changed, what really throws a spanner in the works is the
.menuclass is now on the outer
<div>instead of the the
<ul>, and there is no way to pass optinos to wp_page_menu through wp_nav_menu. It’s an absolute mess consistency wise.
That is what I’m doing as I need to get this task done across 10 different themes.
But this basically means that everyone who has ever (properly) made a theme is having to directly emulate some of the WordPress core, and this really should not have to be done, surely you see that?
I’ve made dozens of themes and I’ve not had any problems with this myself. I think I’ve only used custom callback once or twice where I wanted to provide backwards compatibility.
Well you’ve either made very simple themes or not tested them properly with and without custom menus. I am sitting here with 10 themes with CSS drop downs. They all worked fine until I de-selected the menu and WP “default” kicked in, which is actually not very default at all.
It doesn’t make sense that 2 functions that are both supposed to create menus create different and conflicting markup.
Well you’ve either made very simple themes or not tested them properly with and without custom menus.
I beg your pardon! That’s some assumption! FWIW, four of them are in the Theme Repo, so not only have I tested them thoroughly with (and without) custom menus) but so will have at least one theme reviewer.
If you cannot style the menus in both situations, then I suggest that you consider honing your CSS skills before passing judgement on the abilities of others.
I checked out your themes, the menus on them are actually pretty basic, but that’s besides the point.
This is not a “help me I’m stuck” post, but a “WTF why does this do this” post.
This is not a “help me I’m stuck” post
Then drop the personal comments.
but a “WTF why does this do this” post.
For backwards compatibility. wp_page_menu() existed long before wp_nav_menu().
- The topic ‘wp_nav_menu() and wp_page_menu() generate completely different markup’ is closed to new replies.