WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 3 years ago

#28661 closed enhancement (wontfix)

Improve loading of Customizer from front-end by leveraging `customize-loader.js`

Reported by: celloexpressions Owned by:
Milestone: Priority: low
Severity: normal Version: 3.4
Component: Customize Keywords: needs-refresh
Focuses: ui, javascript Cc:

Description

The Customizer loads "instantly" from the themes screen via customize-loader.js (loading via an iframe and displaying an animation as soon as it starts loading). This also means that the customizer can be exited instantly. With #25457, we're looking at doing this throughout the admin.

It turns out, we can also load the customizer more seamlessly from the front-end with customize-loader. It's just a matter of enqueuing the necessary (<10kb) resources for users who can customize and adding the customize-loader class.

This is a good first step that would enable us to better consider:

  • Making the customize link more prominent in the admin bar (front-end and back-end, potentially), with a top-level text and icon placement.
  • Changing the customize-load animation so that the controls slide-in, or similar, to better show the purpose of the customizer's front-end context (along with #28655).
  • Improving customize-loader on the front-end by showing the existing page DOM in place of the iframe until the iframe loads (making it feel much quicker).

Attachments (1)

28661.diff (5.5 KB) - added by celloexpressions 6 years ago.
Make customize-loader work on the front-end; a bit hacky.

Download all attachments as: .zip

Change History (12)

@celloexpressions
6 years ago

Make customize-loader work on the front-end; a bit hacky.

#1 @celloexpressions
6 years ago

  • Keywords has-patch dev-feedback added

We could probably do it more elegantly (not sure what the best approach would be), but 28661.diff does this and shows how little it would require.

#2 @celloexpressions
6 years ago

Screencast demonstrating this: https://cloudup.com/cYpS76qTAk5.

As you can see, this is a good first step and my points above would make the experience much better once this is in place (especially temporarily treating the existing page as the preview, but preventing users from interacting with it).

#3 @westonruter
6 years ago

Using customize-loader to load up the Customizer is similar to #28602 (Transparently route frontend browsing through Customizer for logged-in editors).

Making the customize link more prominent in the admin bar (front-end and back-end, potentially), with a top-level text and icon placement.

I did something like this in the Customizer Everywhere plugin, at least in the admin bar.

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


6 years ago

#5 follow-up: @celloexpressions
6 years ago

  • Keywords needs-patch added; has-patch dev-feedback removed

We probably shouldn't use the old DOM that triggered/loaded the Customizer if we do this. It won't have any of the customizations applied to it, so a new pageload would be necessary. Might as well do a full reload when exiting the Customizer, and switch to the most-recently-previewed page.

That being said, this is still a viable shorter-term solution while work on more experimental approaches like #28602 progresses.

#6 in reply to: ↑ 5 @westonruter
6 years ago

Replying to celloexpressions:

We probably shouldn't use the old DOM that triggered/loaded the Customizer if we do this. It won't have any of the customizations applied to it, so a new pageload would be necessary. Might as well do a full reload when exiting the Customizer, and switch to the most-recently-previewed page.

Actually, I don't think so. When you first load the customizer, the settings haven't been changed yet so they should be the same as the settings that were already applied to the page without the customizer being loaded. So I think the DOM can be re-used as the initial state for the Customizer preview, if possible.

This ticket was mentioned in Slack in #core-customize by valendesigns. View the logs.


5 years ago

#8 @valendesigns
5 years ago

  • Keywords needs-refresh added; needs-patch removed

This is something that would be very nice to have, but is not a priority right now. I'm also going to assume that the patch needs a refresh due to the age of it. We can circle back for an in-depth discussion after some of the more important features of 4.3 are sorted.

#9 @celloexpressions
5 years ago

  • Priority changed from normal to low

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


3 years ago

#11 @westonruter
3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing since I think we've concurred that we want to see less of customize-loader, not more (see #28536).

Note: See TracTickets for help on using tickets.