Remove the Custom Background Screen in Favor of the Customizer

[celloexpressions]

We can't really expect theme developers to use the customizer instead of theme options pages if we continue to rely on separate pages for core customization features. We have 90% of the custom background screen in the customizer already; once #21483 is done (media library integration), there's no reason to have all of this duplicate functionality. The customizer provides a much better experience anyway, with the live preview.

Added benefits: removing an item from the admin menu's appearance section will probably increase traffic to the customizer from users poking around to see what they can do/look for options. And we'll have even more functionality there too.

There aren't any actions in this screen (and I believe the filters are/will become irrelevant), so we don't need to worry about back-compat for that. Perhaps there are ways that plugins could break, but we can probably get away with removing most, if not all, of wp-admin/custom-background.php.

[SergeyBiryukov]

Related: #25571

[mattwiebe]

Requires #25618

[shelob9]

Related: #26386

[celloexpressions]

This could potentially happen for headers soon, so once backgrounds have recieved another iteration in the customizer, we can follow the same approach as #25571, hiding the page when the customizer is supported.

[celloexpressions]

Per this week's ​dev chat, we'd like to do this in 4.1, especially with Twenty Fifteen's emphasis on this feature and the reworking of background images in the Customizer in #21483.

Three options:

• Hide the link for users who can access the Customizer.
• Show the existing link for users who can't access the Customizer, and a deep-link into the Customizer for users who can access it. Requires #28560.
• Remove the link from the admin menu entirely, potentially removing related code/files.

We also need to decide whether we want to bother continued maintenance of these screens and whether we can close the numerous tickets related to them.

[wonderboymusic]

I am moving this into the backlog until there is a patch - there are a lot of Customizer tickets. If a patch materializes, great.

[celloexpressions]

This ticket doesn't really hinge on a patch (which will be trivial) - it's more a tracking ticket for making sure that this happens along with the work-in-progress changes here and the emphasis that Twenty Fifteen is placing on this feature. First step is to make some decisions about how we should handle this (redirecting, removing links from admin menu entirely, level of ongoing support for the existing pages, which would only be accessible in no-js and a couple other situations), which needs to happen at a dev chat in the near future (not a broad enough base at Customizer meetings for this particular issue).

[celloexpressions]

I won't be able to make it to the dev chat next week, but if someone could add this to agenda that would be great. Need a decision on the 3 options for how to kill this and the header (#25571) admin pages. Then we can make a patch.

[DrewAPicture]

Replying to celloexpressions:

I won't be able to make it to the dev chat next week, but if someone could add this to agenda that would be great. Need a decision on the 3 options for how to kill this and the header (#25571) admin pages. Then we can make a patch.

Noted.

[celloexpressions]

Link header and background to Customizer in the admin menu when it's supported, only show them in the admin bar when the Customizer isn't supported.

[celloexpressions]

It ended up making more since to do one patch for both this and #25571 to avoid conflicting patches, but we'll want to keep this one open after the initial commit for tracking since we need to add media library access to the Customizer for feature-parity, or revert this part. #21483 is waiting for commit or dev feedback from #29723 and #29572 before it can proceed.

25569-25571.diff​ should be committable now, then we can add the deep-linking once that's ready. But now would be a great time for any suggestions on alternate implementations. I went with the deep-linking approach, as that's what the consensus was during the Customizer meetings and there don't seem to be other strong opinions one way or another. Unfortunately, the best way to implement hiding the existing links when the Customizer is supported is with CSS, but I think it's reasonably clean, especially relative to the other options.

[celloexpressions]

With deep-linking.

[westonruter]

​https://github.com/xwpco/wordpress-develop/pull/50

[westonruter]

See description of changes in 25569-25571.3.diff​ in 25571#comment:12, along with an important gotcha I just realized.

[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.

[ocean90]

In 30657:

Make notices added in [30459] less ugly.

see #25569, #25571, [30505].

[johnbillion]

Follow-up: #30571

[ocean90]

In 30793:

Themes: Use Customizer deep-links inside the theme modal.

props DrewAPicture, ocean90.
see #25569, #25571.
fixes #30553.