Headers, Backgrounds, and Widgets in the Customizer are not discoverable from their separate admin screens.

[topher1kenobe]

Both the Header and Background Appearance areas should be deprecated in favor of the customizer. Ticket #25569 proposes removal of the Background area, and I'm in favor of that in the long term, but a less abrupt path is to put notices at the top of the Header and Background pages pointing out that the Customizer is a better way.

[topher1kenobe]

Places deprecation notices on header and background, alert notice on widgets.

[westonruter]

It would also be great if the links from the Header Image, Background Image, and Widgets admin pages would be able to auto-expand (or highlight) their corresponding sections in the Customizer when it loads.

[celloexpressions]

We could consider #28650 as either a dependency or a potential future enhancement. I think we'll probably need to do this soon, though, because we're getting closer to the point where it would make more since to just hide all of the separate pages entirely. I think once we have deep-linking we'll probably link the admin menu links to the customizer directly (except for widgets, which still have some functionality missing in the Customizer).

So I'd say we should probably either do this in 4.0 without deep-linking or bypass this entirely.

[westonruter]

Patch needs to be updated to add return parameters to the links to the Customzer as was done in #25457.

[celloexpressions]

Softer language, place the notice directly in each page, hide-if-no-customize.

[celloexpressions]

To summarize our decision during customize office hours, we need to act on this as soon as possible. New users continue to hit and use these pages regardless of whether they know they can do these things in the Customizer or not. Too many existing users (and developers) don't even know what the Customizer is, more than 2 years after its initial release.

28032.diff​ adds notices to headers, backgrounds, and widgets pages, with widgets being slightly less warning-looking (.update-nag for headers and backgrounds, .updated for widgets). Also mentions the live-previewing functionality. Note that while we use Customize in the admin menu & bar, we're using Customizer here since it's explicitly referring to the thing.

We're not yet hiding these pages as they don't all have full feature parity. And Widgets may wait longer than the others. Headers offer a better and complete implementation in the Customizer, backgrounds need media library access (coming, hopefully in 4.1), and widgets need access to inactive & trashed widgets/sidebars.

If/when we implement deep-linking in the Customizer, we'll probably deep-link headers and backgrounds from the admin menu and admin bar at that time, effectively hiding those pages (for customizer-supported users). Once Menus and Themes make their way in and everything has feature-parity, we'll probably eventually remove the appearance sub-menus entirely (likely to happen sooner for the admin bar) in favor of more prominent Customize access.

[ocean90]

We should come up with a more general message, which should be dismissable and/or added via admin_notices hook.

[celloexpressions]

Headers and Backgrounds are soon-to-be hidden when the Customizer is supported, so this is only relevant to widgets now and needs a new patch per ocean90.

[westonruter]

See https://core.trac.wordpress.org/ticket/28650#comment:10

With that patch, the URL needing to be supplied on the widgets admin page is admin_url( 'customize.php?autofocus[panel]=widgets' )

[rzen]

Add notice of customizer with deep links to specific controls.

[rzen]

Change widgets notice to button

[rzen]

Eliminates notice from Widgets page

[rzen]

28032.2.diff​ take's @topher1kenobe's and @celloexpressions work and add's the deep links recommended by @westonruter.

28032.3.diff​ changes the Widgets screen notice into a button.

28032.4.diff​ skips adding the notice/button to the Widgets screen entirely.

Context:
After talking with @westonruter during WCSF14 we both agreed that an un-dismissible notice would be super annoying and also agreed that reminding and encouraging administrators to use the customizer using a more permanent fixture seems extremely prudent here.

@westonruter and I briefly pondered making notice dismissible and quickly landed on how that quality makes it a WP pointer and adding a new pointer is unnecessary because one already exists from the 3.9 upgrade. So, we opted to add a single button added to the widget page. We added the button to the page title because it seemed out of place (or invisible) everywhere else. I chatted briefly with @helen about this and she wasn't certain if this space was explicitly reserved for an "Add [thing]" type action or if that's only coincidentally the case.

After a few more hours thought I now think adding this button, or an un-dismissible notice, or a new pointer, or anything else seems like a bad (as in unnecessary) idea. We don't need another button on the Widgets screen, especially with the "Customize" link readily available in the already-open Appearance menu.

Maybe adding one more button to this page is the best temporary win right now, though, which is why I included 28032.3.diff​ rather than abandoning it outright.

[celloexpressions]

I think a button is probably a good idea, and it'll definitely be temporary since we're going to eventually remove the admin page entirely. 28032.3.diff​ looks good to me.

[westonruter]

Remove the Widgets admin page entirely? I thought we only talked about removing the Header and Background admin pages.

[celloexpressions]

Replying to westonruter:

Remove the Widgets admin page entirely? I thought we only talked about removing the Header and Background admin pages.

Keyword eventually :) Once all of the missing features like inactive sidebars are implemented in the Customizer, and definitely not any time soon.

[topher1kenobe]

I prefer the button, the one placed in the normal "New" location.

[ocean90]

.3.diff is clever and nice! Should we do the same for the header and background too?

Anyway, all patches have to check current_user_can( 'customize' ).

[rzen]

Just chatted with @melchoyce and she says she also likes the button. It's far less obnoxious than a notice that cannot be dismissed and has "a nice visual parity with the rest of the admin interface".

I'll make a new patch that includes the current_user_can() check that @ocean90 just mentioned.

I think the custom header and custom background sections should keep the obnoxious warning because they are being eliminated and we should do our best to discourage their use whatsoever. Widgets admin is sticking around for a fair bit of time yet, and we shouldn't make that experience any more obnoxious than it already is :)

[ocean90]

In 30102:

Improve/introduce Customizer JavaScript models for Controls, Sections, and Panels.

• Introduce models for panels and sections.
• Introduce API to expand and focus a control, section or panel.
• Allow deep-linking to panels, sections, and controls inside of the Customizer.
• Clean up accordion.js, removing all Customizer-specific logic.
• Add initial unit tests for wp.customize.Class in customize-base.js.

​https://make.wordpress.org/core/2014/10/27/toward-a-complete-javascript-api-for-the-customizer/ provides an overview of how to use the JavaScript API.

props westonruter, celloexpressions, ryankienstra.
see #28032, #28579, #28580, #28650, #28709, #29758.
fixes #29529.

[rzen]

Confirm current_user_can( 'customize' )

[celloexpressions]

28032.5.diff​ is ready for commit. To be followed by commit of the latest patch on #25571, removing core links to the header and background pages. There are a few cases where users who can access the Customizer could make their way into the old pages, so the notices there won't hurt.

[westonruter]

Replying to celloexpressions:

28032.5.diff​ is ready for commit. To be followed by commit of the latest patch on #25571, removing core links to the header and background pages. There are a few cases where users who can access the Customizer could make their way into the old pages, so the notices there won't hurt.

Shouldn't autofocus[section] be replaced with autofocus[control]? There's no guarantee that the section will be present, or the control may be moved to another section.

Also, the cap check for customize is redundant because if the user cannot, then the hide-if-no-customize class will remain in force.

[celloexpressions]

Replying to westonruter:

Shouldn't autofocus[section] be replaced with autofocus[control]? There's no guarantee that the section will be present, or the control may be moved to another section.

Yeah, that'd probably be safer.

Also, the cap check for customize is redundant because if the user cannot, then the hide-if-no-customize class will remain in force.

hide-if-no-customize is just based on the JS checks for Customizer support, right? That being said, users should be able to access the Customizer equivalents if they can see these pages, so we shouldn't need the cap checks.

[westonruter]

The no-customize-support body class gets removed in the wp_customize_support_script function, and this only gets called if current_user_can( 'customize' ). So if the user can't customize then any CSS that hides elements with selectors like .no-customize-support .hide-if-no-customize should continue to be hidden as expected without additional PHP-based checks for the ability to customize.

[ocean90]

In 30459:

Customizer: Use deep-links for Backgrounds, Headers, and Widgets.

Replace links in admin menu and toolbar to Custom Background/Header screen with deep-links to the Customizer section.
On the Widgets screen display a link to the Customizer widgets panel.

props topher1kenobe, rzen, celloexpressions, westonruter
fixes #25569, #25571, #28032.