WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 9 months ago

#25457 closed enhancement (fixed)

Go back whence we came when closing the Customizer

Reported by: birgire Owned by: helen
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: has-patch commit
Focuses: ui Cc:

Description

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.

Attachments (4)

customize.diff (1.2 KB) - added by birgire 18 months ago.
customize.php diff
customize_v2.diff (1.1 KB) - added by birgire 18 months ago.
customize.diff
25457.diff (2.3 KB) - added by helen 10 months ago.
25457.1.diff (2.0 KB) - added by westonruter 9 months ago.
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

Download all attachments as: .zip

Change History (25)

@birgire18 months ago

customize.php diff

comment:1 @SergeyBiryukov18 months ago

  • Component changed from General to Appearance

@birgire18 months ago

customize.diff

comment:2 @helen18 months ago

  • Keywords close added

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.

comment:3 @helen18 months ago

  • Keywords reporter-feedback added

Meant to ask - use case?

comment:4 @birgire18 months ago

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

comment:5 @birgire18 months ago

  • Keywords reporter-feedback removed

comment:6 @helen18 months ago

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.

Last edited 18 months ago by helen (previous) (diff)

comment:7 follow-up: @birgire18 months ago

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

comment:8 @ircbot14 months ago

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

comment:9 @ircbot11 months ago

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

comment:10 in reply to: ↑ 7 @westonruter10 months ago

  • Focuses ui added
  • Keywords needs-patch added; has-patch close removed
  • Milestone changed from Awaiting Review to 4.0
  • Version changed from 3.6.1 to 3.4

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.

@helen10 months ago

comment:11 @helen10 months ago

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.

comment:12 @ircbot10 months ago

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

comment:13 @helen10 months ago

  • Summary changed from Add a filter to the Close link in wp-admin/customize.php to Go back whence we came when closing the Customizer

comment:14 @ircbot9 months ago

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

@westonruter9 months ago

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

comment:15 @westonruter9 months ago

  • Keywords has-patch added; needs-patch removed

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.

comment:16 @ircbot9 months ago

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

comment:17 @westonruter9 months ago

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.

comment:18 @celloexpressions9 months ago

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.

comment:19 @westonruter9 months ago

  • Keywords commit added

comment:20 @ircbot9 months ago

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

comment:21 @helen9 months ago

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

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.

Note: See TracTickets for help on using tickets.