Go back whence we came when closing the Customizer

[birgire]

It would be handy to be able to change the href attribute of the close link in the theme customizer in /wp-admin/customize.php, so you wouldn't have to use some jQuery hacking: ​http://wordpress.stackexchange.com/q/115731 or redirecting: ​http://wordpress.stackexchange.com/q/115731.

[birgire]

customize.php diff

[birgire]

customize.diff

[helen]

I'm not sure I understand this - you can pass a URL as it is and it will be used, e.g. http://example.com/wp-admin/customize.php?url=http%3A%2F%2Fexample.com%2F. I would be against filtering the return location from other links - users should have a consistent experience.

[helen]

Meant to ask - use case?

[birgire]

Hi Helen, thanks for your comment.

My user-experience is that the Theme Customizer feels like a fullscreen popup with a close button.
When I close it, I expect to go back to the previous page.

Let's say the user is on the page /wp-admin/widgets.php and clicks on the Theme Customizer link in the admin menu. The Theme Customizer opens up and when the user closes it, he's taken to the page /wp-admin/themes.php instead of the page /wp-admin/widgets.php where he started.

So this is the case when $return is empty.

By having a filter on the Close link, the user could for example use the referred page instead.

Or better yet, use the referred page instead of the default admin_url( 'themes.php' ).

I should have described this better in the first place, I hope this makes sense ;-)

[helen]

So should we be setting the url query arg, then? It does make sense to me that you should return whence you came - drives me crazy that you go from the Dashboard welcome panel to Customize to Themes.

[birgire]

I agree, the user experince should be consistent and predictable.

Few things that come to mind, like these two different approaches:

a) I wonder if it would make sense to replace customize.php with customize.php?url=#current_page_url#
in the admin-menu. Example: if we are on the admin page widgets.php then the admin menu link for Customize will be customize.php?url=widgets.php.

b) Perhaps we can use wp_get_referer(), so instead of

$return ? $return : admin_url( 'themes.php' )

in wp-admin/customize.php, we could try:

$return ? $return : $close_url

or if we want it to be filterable:

$return ? $return : apply_filters( 'wp_customize_close_url', $close_url )

where:

$close_url = ( wp_get_referer() ) ? wp_get_referer() : admin_url( 'themes.php' )

[westonruter]

This issue has been disorienting for me as well, and it is confusing since the frontend behavior—clicking Customize from the Admin Bar—results in returning the user back to that same originating page from which they clicked Customize.

So I love this approach (as birgire commented above):

a) I wonder if it would make sense to replace customize.php with customize.php?url=#current_page_url#
in the admin-menu. Example: if we are on the admin page widgets.php then the admin menu link for Customize will be customize.php?url=widgets.php.

It implements the same behavior when clicking Customize from the admin menu in the backend as when clicking Customize from the admin bar in the frontend.

[helen]

Completely forgot about this - I played with patching this live at a meetup a while ago; 25457.diff​ is where we got. Basically: customize-loader.js is supposed to do some koop-shiny magic ​acccording to nacin. We were unsuccessful in getting it to work consistently with that patch, though.

[westonruter]

Append current REQUEST_URI as return query param for Customize admin menu link. Clean up retrieval of url and return query params. Use urlencode to properly encode return URLs containing query params. PR: ​https://github.com/x-team/wordpress-develop/pull/22

[westonruter]

Using customize-loader would make it easy to return to the original URL since it would just involve the removal of the iframe overlay and restoration of the URL (manipulated via history.pushState()) via history.back() (see #28536), and this approach is also suggested in #28661 on the frontend to speed up the loading of the customizer.

But I think the fix for this issue is much simpler and straightforward. All we need to do is append the REQUEST_URI as the return query parameter for the admin menu link to the Customizer. Then when hitting Close in the Customizer, the user would be returned to the admin page from which they clicked on the Customizer.

See 25457.1.diff​.

[westonruter]

For reasons outlined in IRC above, I think that the use of customize-loader should instead be explored in #28661 and #28602. Since we don't know what may exist on the admin page from which the user clicks “Customize”, we don't know if there is media in the admin that is currently playing. If there is, then the media would keep playing when the Customizer iframe is loaded on top of it, resulting in a very confusing experience since as far as the user is concerned they left the admin page and are now on a new URL but the media from the previous page would still be playing.

[celloexpressions]

I'm not in love with the URL approach, but due to the issues with customize-loader, and the fact that this is really a bug, and customize-loader is an enhancement, let's go with 25457.1.diff​ for now. I'll open a new ticket to use customize-loader throughout the admin if I can figure out the issues there.

[helen]

In 29026:

When accessing the Customizer from the admin menu, make sure the user is returned to the originating page upon close. We should still investigate the general usage of customize-loader.js moving forward, but this approach fixes the immediate issue. props westonruter. fixes #25457.