Make WordPress Core

Opened 3 years ago

Closed 2 years ago

#21413 closed enhancement (fixed)

Add Customizer to Appearance submenu as first item

Reported by: jane Owned by: markjaquith
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.4.1
Component: Customize Keywords: has-patch commit
Focuses: ui Cc:


I suggest we add the customizer to the Appearance section as its own submenu, and make it first in the list (above Themes). It serves as a one-stop shop for the Appearance section anyway, the main thing that would be needed would be to add in some links in the customizer back to individual Appearance screens.

For label we could go with Customize (should still use Live Preview on Themes screen for not-activated themes), or some other suggestion that's better. Wouldn't be too hard to do some testing to see what label gets the idea across the best.

Attachments (8)

add_customizer_to_menu.patch (1.2 KB) - added by ryanhellyer 3 years ago.
Adds customizer link at beginning of Appearances menu in WordPress
21413.diff (5.0 KB) - added by obenland 3 years ago.
21413.2.diff (7.3 KB) - added by DrewAPicture 3 years ago.
Refreshed and cleanup on themes.php
21413.3.diff (6.7 KB) - added by DrewAPicture 3 years ago.
remove admin-header.php change
21413.4.diff (7.0 KB) - added by DrewAPicture 3 years ago.
Remove gap from first li on themes.php
21413.5.patch (527 bytes) - added by ethitter 3 years ago.
21413.6.patch (619 bytes) - added by SergeyBiryukov 3 years ago.
21413.7.diff (1001 bytes) - added by MikeHansenMe 2 years ago.
switch customizer and themes in menu

Download all attachments as: .zip

Change History (33)

comment:1 @ryanhellyer3 years ago

I have a plugin that almost does this, but does not place the link first in the list. I'm working on rewriting it to be first in the list for you at the moment. I'll post a link when it's ready.

comment:2 @scribu3 years ago

  • Cc scribu added

comment:3 follow-up: @ryanhellyer3 years ago

This adds the link, but does not detect whether the customizer is being used or not (I'm not sure how to detect that):

I'm not entirely sure where this should go in core either, hence it's still only a plugin instead of a patch.

comment:4 in reply to: ↑ 3 @ryanhellyer3 years ago

It turns out there is no need to detect if the customizer is loaded or not, as it is always used regardless of whether a theme adds anything to it or not.

@ryanhellyer3 years ago

Adds customizer link at beginning of Appearances menu in WordPress

@obenland3 years ago

comment:5 @obenland3 years ago

21413.diff adds a (pretty bad) hack to maintain 'themes.php' as the top level menu location. This would maintain easy backwards compatibility with add_theme_page() etc.

Since it looks like we get a Menu overhaul anyway this release, maybe we should wait for the new API to be ready?

Somewhat related: #21404, since part of it is adding a "Customize" menu item.

comment:6 @scribu3 years ago

Since it looks like we get a Menu overhaul anyway this release, maybe we should wait for the new API to be ready?

Yes, please: #12718

comment:7 @nacin3 years ago

Our current menu paradigm (beyond just the API) is that the top-level link must be the same as the first submenu item.

Aside from being a well-established paradigm, this is also important for accessibility purposes. You click the first item to open the submenu (if you don't use the flyout), as an alternative to the old click-to-expand.

A few issues with this. One, this means clicking "Appearance" will open the customizer — this isn't good, because it opens a completely different workflow. While assuming you want to customize your theme is a safe assumption more often than it is wrong, the separate workflow can be jarring if you did want to end up on themes.php.

Two, the Customizer isn't always available. At the moment, this means you:

  1. have JS enabled, which we need to detect in the browser, client-side.
  2. you are not using IE7, which we *could* detect server-side, but currently use feature detection in JS, which is preferred.
  3. are not using IE8 or IE9 if you have a domain-mapped front-end (and your plugin doing the domain mapping does not un-map for the customizer). We currently detect this server-side (to check the URLs) and then feature detection in JS.

That the Customizer isn't always available means "Appearance" will sometimes open up a regular window and other times the customizer, and it won't be easy to establish when exactly it should link to one or the other. ryanhellyer's code works around this to some extent, but overall the request ain't pretty to implement.

comment:8 @DrewAPicture3 years ago

  • Cc xoodrew@… added

What about _not_ setting it as the first submenu item? It would be a nice-to-have since we can currently access it directly via:

  • The frontend Toolbar
  • The Welcome area
  • Appearance > Themes

But if Welcome is hidden, it takes two steps to get there from anywhere in the Dashboard (other than those screens). We can still hide it if no-js in the admin menu, correct?

Last edited 3 years ago by DrewAPicture (previous) (diff)

comment:9 @jane3 years ago

Never saw @nacin's comment 5 months ago, oops! Appearance and Themes are not the same thing, we put Themes first because it was the most important, but Customizer is the closest thing to an overal Appearance view/editor. Yes, it would change the flow. Most UI changes do that to some degree or another, so having to click to click to Themes doesn't bother me if that's specifically where someone wants to be. The real problem is that the customizer takes you out of the dashboard and there are no navigations links. At the time I proposed it, the customizer was supposed to get some 'round 2' attention to make it better than our first release of it. That would need to happen before I'd want it to be a default screen. In meantime, just getting it in the submenu would be a tangible improvement.

comment:10 @DrewAPicture3 years ago

  • Component changed from UI to Appearance
  • Keywords ui-focus added
  • Milestone changed from Awaiting Review to 3.6

Would be nice to get this resolved in 3.6.

comment:11 follow-up: @prionkor3 years ago

  • Cc sisir@… added
Version 0, edited 3 years ago by prionkor (next)

comment:12 in reply to: ↑ 11 @DrewAPicture3 years ago

  • Keywords has-patch added; needs-patch removed

21413.2.diff refreshes 21413.diff. It also cleans up the options list on themes.php to be more uniform: http://cl.ly/image/0H142h3k3M3d

Replying to prionkor:

We could append the link with js/jq. So, any user who don't have js enabled won't see the menu item.

For customizer links we apply the .hide-if-no-customize class which handles both no-js and any Customizer filters. This is covered in 21413.2.diff.

@DrewAPicture3 years ago

Refreshed and cleanup on themes.php

comment:13 @lancewillett3 years ago

  • Keywords commit added

Can we get this into beta-1? Patch looks good in testing.

@DrewAPicture3 years ago

remove admin-header.php change

comment:14 @lancewillett3 years ago

Discussing in IRC today log we discussed addressing Nacin's concerns above, re older IEs and mapped domains. This menu item acts exactly like previous menu items, 3.5 shipped with the link under the currently active theme.

So this new menu item just adds another link with same CSS class for hide-if-no-customize for hiding the menu item if the browser doesn't support it.

@DrewAPicture3 years ago

Remove gap from first li on themes.php

comment:15 @DrewAPicture3 years ago

21413.4.diff removes the gap from the hidden Customize link on themes.php if no-customize-support. Note the gap that was between the 'Options:' label and the 'Widgets' link: http://cl.ly/image/38090N0Z1T3U

comment:16 @lancewillett3 years ago

Per r20918 we do need the admin-header.php checks in place (was in .2 patch, now reverted in .3 patch).

comment:17 @lancewillett3 years ago

For later testing notes: try with IE8/9 and http://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/ (thanks to ethitter for the reference).

comment:18 @markjaquith3 years ago

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

In 23871:

Add "Customize" as first item under Appearance menu.

fixes #21413. props ryanhellyer, obenland, DrewAPicture

@ethitter3 years ago

comment:19 @ethitter3 years ago

  • Cc erick@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

As Lance noted, without the change in wp-admin/admin-header.php, the Customize link only appears when viewing themes.php.

21413.5.patch contains just the change to admin-header.php that should ensure the Customize link shows consistently.

@SergeyBiryukov3 years ago

comment:20 @SergeyBiryukov3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 23879:

Consistently show "Customize" item in the admin menu. props ethitter. fixes #21413.

comment:21 @nacin3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm trying to figure out if there was any final reasoning on why Customize ended up being the first link. I couldn't find anything in the linked IRC logs.

Best I can tell, the current situation — Appearance not going to the customizer, but Customize being the first link anyway — seems worse than the alternatives (Appearance opening the customizer, or Customize being the second link) in of terms of consistency. My comment 8 months ago discussed both paradigms and accessibility. Jen (jane) did reply that a change is okay, but I think she was saying that it was okay that Appearance opened the customizer, not that the links were out of order.

Also, [23871] moved the Customize link on themes.php from before "OPTIONS:" to being one of the options. I imagine that was done simply because that code pulls from $submenu — but it should probably be switched back.

comment:22 @markjaquith2 years ago

I can't think of a good reason it would have to be first.

@MikeHansenMe2 years ago

switch customizer and themes in menu

comment:23 @nacin2 years ago

In 24048:

Revert [23871] - Customize should be added to the menu, but not hacked in as first. see #21413.

comment:24 @nacin2 years ago

[24048] was supposed to be a straight revert so I could apply a second changeset. Anyway, the patch (as would be applied with [23871] reverted) was simply adding 'customize.php' == $item[2] to themes.php and adding Customize as $submenu['themes.php'][6].

comment:25 @nacin2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 24049:

Customize requires edit_theme_options. If you only have switch_themes (rare, but a case that core supports), you should not have access. fixes #21413.

Note: See TracTickets for help on using tickets.