WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#28032 closed enhancement (fixed)

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

Reported by: topher1kenobe Owned by: ocean90
Milestone: 4.1 Priority: normal
Severity: normal Version: 3.9
Component: Customize Keywords: has-patch
Focuses: ui, administration Cc:
PR Number:

Description

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.

Attachments (11)

28032.patch (4.0 KB) - added by topher1kenobe 6 years ago.
Places deprecation notices on header and background, alert notice on widgets.
28032.diff (2.1 KB) - added by celloexpressions 5 years ago.
Softer language, place the notice directly in each page, hide-if-no-customize.
28032.header.png (106.6 KB) - added by celloexpressions 5 years ago.
28032.background.png (6.1 KB) - added by celloexpressions 5 years ago.
28032.widgets.png (10.5 KB) - added by celloexpressions 5 years ago.
28032.2.diff (2.2 KB) - added by rzen 5 years ago.
Add notice of customizer with deep links to specific controls.
28032.3.diff (702 bytes) - added by rzen 5 years ago.
Change widgets notice to button
28032.4.diff (1.5 KB) - added by rzen 5 years ago.
Eliminates notice from Widgets page
28032.widgets_button.png (38.1 KB) - added by rzen 5 years ago.
28032.5.diff (2.3 KB) - added by rzen 5 years ago.
Confirm current_user_can( 'customize' )
28032.6.diff (2.4 KB) - added by ocean90 5 years ago.

Download all attachments as: .zip

Change History (46)

@topher1kenobe
6 years ago

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

#1 @SergeyBiryukov
6 years ago

  • Summary changed from Make Customizer more visible with visual queues on deprecated areas of the admin to Make Customizer more visible with visual cues on deprecated areas of the admin

#2 @SergeyBiryukov
6 years ago

  • Component changed from Themes to Appearance

#3 @westonruter
6 years ago

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.

#4 @celloexpressions
5 years ago

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.

#5 @westonruter
5 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in IRC in #wordpress-dev by westonruter. View the logs.


5 years ago

#7 @westonruter
5 years ago

  • Milestone changed from Future Release to 4.0

#8 @westonruter
5 years ago

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

@celloexpressions
5 years ago

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

#9 @celloexpressions
5 years ago

  • Summary changed from Make Customizer more visible with visual cues on deprecated areas of the admin to Headers, Backgrounds, and Widget in the Customizer are not discoverable from their separate admin screens.
  • Type changed from enhancement to defect (bug)

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.

#10 @celloexpressions
5 years ago

  • Summary changed from Headers, Backgrounds, and Widget in the Customizer are not discoverable from their separate admin screens. to Headers, Backgrounds, and Widgets in the Customizer are not discoverable from their separate admin screens.

#11 @ocean90
5 years ago

  • Milestone changed from 4.0 to Future Release
  • Type changed from defect (bug) to enhancement

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

Last edited 5 years ago by ocean90 (previous) (diff)

#12 @celloexpressions
5 years ago

  • Keywords needs-patch added; has-patch removed

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.

#13 @westonruter
5 years ago

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
5 years ago

Add notice of customizer with deep links to specific controls.

@rzen
5 years ago

Change widgets notice to button

@rzen
5 years ago

Eliminates notice from Widgets page

#14 @rzen
5 years ago

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.

#15 @rzen
5 years ago

  • Keywords has-patch added; needs-patch removed

#16 @celloexpressions
5 years ago

  • Milestone changed from Future Release to 4.1

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.

#17 follow-up: @westonruter
5 years ago

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

#18 in reply to: ↑ 17 @celloexpressions
5 years ago

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.

#19 @topher1kenobe
5 years ago

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

This ticket was mentioned in Slack in #core by rzen. View the logs.


5 years ago

#21 @rzen
5 years ago

  • Keywords ui-feedback added

#22 @ocean90
5 years ago

.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' ).

#23 @rzen
5 years ago

  • Keywords ui-feedback removed

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 :)

#24 @ocean90
5 years ago

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
5 years ago

Confirm current_user_can( 'customize' )

#25 follow-up: @celloexpressions
5 years ago

  • Keywords commit added

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.

#26 in reply to: ↑ 25 ; follow-up: @westonruter
5 years ago

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.

#27 in reply to: ↑ 26 @celloexpressions
5 years ago

  • Keywords needs-refresh added; commit removed

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.

#28 @westonruter
5 years ago

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.

This ticket was mentioned in Slack in #core by ocean90. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by westonruter. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by ocean90. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by westonruter. View the logs.


5 years ago

@ocean90
5 years ago

#33 @ocean90
5 years ago

  • Keywords needs-refresh removed

This ticket was mentioned in Slack in #core by celloexpressions. View the logs.


5 years ago

#35 @ocean90
5 years ago

  • Owner set to ocean90
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.