adding theme support for 'custom-header' or 'custom-background' results to duplicate admin menu items

[edville101]

Wordpress 4.1 shows double 'Header' and 'Background' menu items in admin navigation menu on front-end when using
add_theme_support( 'custom-header', $args );
add_theme_support( 'custom-background', $args );

Here is a screenshot of Twentyfourteen theme.

​http://snag.gy/djDFm.jpg

This issue also exists in other themes I tested using the above hooks.
This issue is not seen in previous WordPress version using the Twentyfourteen theme.

[SergeyBiryukov]

Related: [30459]

[celloexpressions]

@edville101: what broswer and version are you using? Is JavaScript enabled? Can you reproduce with all plugins deactivated?

For some reason, hide-if-customize OR hide-if-no-customize isn't working.

[edville101]

Replying to celloexpressions:

@edville101: what broswer and version are you using? Is JavaScript enabled? Can you reproduce with all plugins deactivated?

For some reason, hide-if-customize OR hide-if-no-customize isn't working.

Thank you.
I was able to confirm that a popup form plugin's javascript is causing this problem

$( '#wpadminbar' ).appendTo( 'html' ).show();

[johnjamesjacoby]

I just ran into this. ⏳

I think it is strange that WordPress hides these submenu items with CSS, when it could simply prevent them from ever being added in the first place.

I did some research, and it seems like Custom_Background::init() and Custom_Image_Header::init() could both have the same relative conditional logic inside of menu.php to not add the pages, in turn not adding the submenu items.

Header:

if ( current_theme_supports( 'custom-header' ) && current_user_can( 'customize' ) ) {
    return;
}

Background:

if ( current_theme_supports( 'custom-background' ) && current_user_can( 'customize' ) ) {
    return;
}

Are there any un'obvious reasons to add these pages, even though they are not directly visited by a user anymore? The Customizer appears to work normally without them, as do the themes and theme settings.

[celloexpressions]

The history here is that these pages were kept for compatibility for users with JavaScript disabled when we deprecated the pages in favor of the customizer. The JS runs in the browser on load to hide the menu items with CSS. If they don't get hidden, it's actually probably because there's a JS error somewhere. There are several places sprinkled throughout wp-admin where similar logic applies for showing customizer links.

hide-if-customize is essentially used as hide-if-has-js. The customize user capability is mapped to edit-theme-options by default, so users with access to the header and background should have access to the customizer also.

At this point, can lose all of that logic and remove the links entirely? How many pages in wp-admin work at all with JS disabled?