I have tried several options like setting 'container' => false and registering the theme_location and searching on forums but I am unable to get rid of the "div" coming with the wp_nav_menu in my page:

<?php get_nav_menu();?>

function get_nav_menu() {
    $navMenuDefaults = array(
    'theme_location'  => 'header-nav',
    'menu'            => '',
    'container'       => false,
    'container_class' => '',
    'container_id'    => '',
    'menu_class'      => '',
    'menu_id'         => '',
    'echo'            => true,
    'fallback_cb'     => 'wp_page_menu',
    'before'          => '',
    'after'           => '',
    'link_before'     => '',
    'link_after'      => '',
    'items_wrap'      => '<ul id="%1$s" class="%2$s">%3$s</ul>',
    'depth'           => 0,
    'walker'          => ''
    return wp_nav_menu($navMenuDefaults);

and in functions.php:

function register_top_nav() {
  register_nav_menu('header-nav',__( 'Header Nav' ));
add_action( 'init', 'register_top_nav' );

I am not sure why I am getting the following output:

<div class="">
        <li class="page_item page-item-2">
            <a href="url">Sample Page</a>

How can I get something like following:

<ul class="abc">
        <a href="#">dfdf</a>


  • 1
    What does the call look like in template? The markup might just be there and not coming from the function at all.
    – Rarst
    Commented Sep 12, 2015 at 14:32

6 Answers 6


FYI :container => '' is a string operation and it's default set by div you can't use true or false like bool expression.

Just change the container => 'ul' then i hope you will get what you want to see. for more details please read this : https://developer.wordpress.org/reference/functions/wp_nav_menu/

Thanks Musa

  • 1
    Technically false would work just fine and it's semantically more clear (unwanted option) than empty string (container of nothing?).
    – Rarst
    Commented Sep 12, 2015 at 14:33
  • @md.musa: I have tried with string literals too, but no effect Commented Sep 12, 2015 at 15:01


You have not created a menu on the Appearance > Menus panel in the WordPress admin dashboard.

My reasoning is based on a bug which occurs under the following conditions:

  • No navigation menus have been created
  • wp_nav_menu() was called with the default 'fallback_cb' argument 'wp_page_menu'
  • wp_nav_menu() was called with a 'container' argument intended to eliminate the container (anything which the empty() function returns true for)


Either of the following should remove the <div> container.

  • Create a menu in the Appearance > Menus panel. The extraneous <div> should disappear even if you don't associate the new menu with your registered 'header-nav' theme location.
  • Change the 'fallback_cb' argument to a custom function that returns some default markup - or even an empty string - i.e.

    'fallback_cb' => function() { return ''; },


In the event that the wp_nav_menu() function is unable to locate the indicated menu, it then tries two more things to produce menu markup:

  1. Display the first populated menu found.
  2. Display menu markup generated by the function indicated by the 'fallback_cb' argument (by default, wp_page_menu()).

Your posted markup is for a page post-type with a post ID of 2 and the title "Sample Page", possibly indicating a new WordPress installation, for which it would be reasonable to assume no menus have been created. This indicated that your wp_nav_menu() call is likely falling back to wp_page_menu(), as the fallback function will create an impromptu menu from any number of pages in your installation.

When the 'fallback_cb' function is called, it is passed the same arguments that were given to wp_nav_menu() (merged with default arguments). Here the Codex documentation on the wp_page_menu() function is a little out of date, since as of WordPress 4.4.0 the function does actually accept and handle a 'container' argument. So wp_page_menu() is getting called with the same 'container' argument you handed to wp_nav_menu(), that being '' (empty string literal) or false.

The meat of the problem is a contradictory behavior that stems from these lines in wp_page_menu():

// Fallback in case `wp_nav_menu()` was called without a container.
if ( empty( $container ) ) {
    $container = 'div';

So, since empty() evaluates both boolean false as well as '' to true, this little fail-safe thinks you're crazy for not wanting a container and adds one back in "for" you.

  • 1
    This should be marked as the correct answer.
    – MrVanilla
    Commented Sep 13, 2020 at 5:58

Yes you can use this code

$nav_menu = array(
       'title_li'        => '', 
       'container'       => '',
       'theme_location'  => 'header-nav',   
        'menu_class'     => '',
        'menu_id'        => '',

wp_nav_menu( $nav_menu );

The above code will display the menu in ul and li format without having any class and id to both ul and li tag

  • Is it possible to remove ul as well? Commented Dec 20, 2016 at 11:18

As you set "container" to false this should work unless there's a bug in anywhere either on the environment or a conflict with something else.

In fact I've tested this in Twenty Fifteen and one of My themeforest Themes.

Can you check if you have any internal cache that's not reflecting your changes right away?



You can try with this scenario.

Step 1:

Put this code in your theme's functions.php file:

add_action( 'after_setup_theme', 'theme_nav_setup' );

if ( ! function_exists( 'theme_nav_setup' ) ){
  function theme_nav_setup() {  
    register_nav_menu( 'header-nav_new', __( 'Main Menu', 'text-domain' ) );

Step 2:

Then call this where you can see this menu output:

wp_nav_menu( array(
  'menu' => 'header-nav_new',
  'theme_location'    => 'header-nav_new',
  'depth'             => 6,
  'container'         => 'ul',
  'fallback_cb'       => 'wp_page_menu',
  'menu_class'        => 'abc'
  • Why do you believe these changes will address the question?
    – bosco
    Commented Jul 19, 2016 at 3:34
  • @bosco Changes were not made by the poster; they were a suggested edit by another user.
    – Tim Malone
    Commented Jul 19, 2016 at 3:41
  • @TimMalone Not the post edits - I meant MD's proposed solution, though I definitely worded it poorly; pardon the confusion :P . I.e. changing header-nav to header-nav_new seems unnecessary as well as changing the 'depth' argument to 6... There's no reason for a theme_exists() check as PHP would already be throwing an error in the event of a collision. The switch to the 'after_setup_theme' action makes sense - but the rest of the answer feels nonsensical to me without further elaboration
    – bosco
    Commented Jul 19, 2016 at 3:47

From my own experience, if you haven't yet assign menu to the registered menu location, all argument settings prefixed with container won't work. you have to assign your created menu to the registered menu location before see the change.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.