WordPress.org

Make WordPress Core

#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: Appearance Keywords: has-patch commit
Focuses: ui Cc:

Description

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 21 months ago.
Adds customizer link at beginning of Appearances menu in WordPress
21413.diff (5.0 KB) - added by obenland 21 months ago.
21413.2.diff (7.3 KB) - added by DrewAPicture 14 months ago.
Refreshed and cleanup on themes.php
21413.3.diff (6.7 KB) - added by DrewAPicture 13 months ago.
remove admin-header.php change
21413.4.diff (7.0 KB) - added by DrewAPicture 13 months ago.
Remove gap from first li on themes.php
21413.5.patch (527 bytes) - added by ethitter 13 months ago.
21413.6.patch (619 bytes) - added by SergeyBiryukov 13 months ago.
21413.7.diff (1001 bytes) - added by MikeHansenMe 12 months ago.
switch customizer and themes in menu

Download all attachments as: .zip

Change History (33)

comment:1 ryanhellyer21 months 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 scribu21 months ago

  • Cc scribu added

comment:3 follow-up: ryanhellyer21 months 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):
http://pixopoint.com/products/customizer-link/

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 ryanhellyer21 months 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.

ryanhellyer21 months ago

Adds customizer link at beginning of Appearances menu in WordPress

obenland21 months ago

comment:5 obenland21 months 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 scribu21 months 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 nacin21 months 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 DrewAPicture18 months 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. We can still hide it if no-js in the admin menu, correct?

Version 0, edited 18 months ago by DrewAPicture (next)

comment:9 jane16 months 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 DrewAPicture15 months 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: prionkor14 months ago

  • Cc sisir@… added

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

Last edited 14 months ago by prionkor (previous) (diff)

comment:12 in reply to: ↑ 11 DrewAPicture14 months 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.

DrewAPicture14 months ago

Refreshed and cleanup on themes.php

comment:13 lancewillett13 months ago

  • Keywords commit added

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

DrewAPicture13 months ago

remove admin-header.php change

comment:14 lancewillett13 months 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.

DrewAPicture13 months ago

Remove gap from first li on themes.php

comment:15 DrewAPicture13 months 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 lancewillett13 months ago

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

comment:17 lancewillett13 months 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 markjaquith13 months 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

ethitter13 months ago

comment:19 ethitter13 months 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.

SergeyBiryukov13 months ago

comment:20 SergeyBiryukov13 months 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 nacin13 months 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 markjaquith12 months ago

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

MikeHansenMe12 months ago

switch customizer and themes in menu

comment:23 nacin12 months ago

In 24048:

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

comment:24 nacin12 months 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 nacin12 months 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.