WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#32637 closed defect (bug) (fixed)

Customizer should default to returning to the front page, not the themes page

Reported by: celloexpressions Owned by: westonruter
Milestone: 4.4 Priority: normal
Severity: normal Version: 4.0
Component: Customize Keywords: has-patch commit
Focuses: ui Cc:

Description

When closing the Customizer without a url or return param set, the user should be taken to the front page of the site rather than the themes admin page or the dashboard (for users who can't switch themes). This is based on several changes with the Customizer over the past several releases, and most generally because we'd like to emphasize the connection between the Customizer and the frontend rather than the admin.

Note that most users will probably end up in the Customizer with a url or return param but that's not always the case. With this changed users should still theoretically go back to the themes admin if they opened the Customizer from there.

See the $return var in lines 29 and 32 of wp-admin/customize.php.

Attachments (6)

32637.patch (546 bytes) - added by McGuive7 5 years ago.
Sets default customizer return screen to the site's front page instead of the admin theme page.
32637.2.patch (548 bytes) - added by McGuive7 5 years ago.
Improved patch using home_url( '/' ) instead of get_home_url()
32637.3.patch (778 bytes) - added by McGuive7 5 years ago.
Update patch to include additional check to HTTP referrer to determine whether to return to admin vs front-end.
32637.4.diff (689 bytes) - added by westonruter 5 years ago.
Unslash HTTP_REFERER; use strpos() for starts-with, not contains. Remove whitespace errors.
32637.5.diff (2.4 KB) - added by westonruter 5 years ago.
32637.6.diff (3.9 KB) - added by westonruter 4 years ago.

Download all attachments as: .zip

Change History (30)

@McGuive7
5 years ago

Sets default customizer return screen to the site's front page instead of the admin theme page.

@McGuive7
5 years ago

Improved patch using home_url( '/' ) instead of get_home_url()

#1 @McGuive7
5 years ago

  • Keywords 2nd-opinion added

I don't know enough about the ongoing customizer conversation to agree or disagree with this one, however it does seem like there's the opportunity to do one more check in case both return and url parameters are absent. We could check to see if $_SERVER['HTTP_REFERER'] exists, and if so check to see if it contains the admin url with something like this:

if ( isset( $_SERVER['HTTP_REFERER'] ) && false !== strpos( $_SERVER['HTTP_REFERER'], admin_url() ) ) {
	$return = admin_url();
} else {
	$return = home_url( '/' );
}

Happy to turn this into a patch if others think it makes sense - I'm curious to know if this seems like a warranted check for the sake of thoroughness.

#2 @McGuive7
5 years ago

  • Keywords has-patch added; needs-patch removed

Would love feedback on the above proposal (yay? nay?) so I can throw it in a patch if so desired? Anyone have an opinion?

#3 @celloexpressions
5 years ago

We could do that, although it doesn't matter much either way. There is unlikely to be a referrer if they run into this, but if there, doesn't hurt to check it.

@McGuive7
5 years ago

Update patch to include additional check to HTTP referrer to determine whether to return to admin vs front-end.

#4 @McGuive7
5 years ago

  • Keywords dev-feedback added

Okay, updated the patch to include an additional check to the HTTP referrer just to make the check a bit more full-proof. This should be ready to go, and I would love an extra set of eyes.

#5 @McGuive7
5 years ago

Anyone? Bump.

#6 @karlazz
5 years ago

Seems like this works in the trunk already???? Sorry am new to this. Went to test the patch, but remembered first to test the base code. And the base code functionality seems to work as required: customizer returns to public side when started from the public side, but to the dashboard when started from Appearance.

Please help me to test this for you. Am I mistaken in what I am testing. I am logged in as administrator.

#7 @McGuive7
5 years ago

Hey Karla!

This issue is actually for edge cases in which neither a url nor return parameter are set. By default, this is all taken care of in core for both the front-end and admin, so testing those cases will already work in core - correct.

This patch is to create a surefire return method for cases in which neither param is set, which might happen if plugin/theme devs are doing things totally by the book, for example.

So to test this, you can manually load up your customizer page without the return and url parameters in the URL, and click the close (X) button to see where it takes you. So, by default, the customizer URL looks something like:

From admin
http://local.wordpress-trunk.dev/wp-admin/customize.php?return=%2Fwp-admin%2Findex.php

From front-end
http://local.wordpress-trunk.dev/wp-admin/customize.php?url=http%3A%2F%2Flocal.wordpress-trunk.dev%2F

You can remove the entire return and url params to test, and with the patch you should be returned to the correct place after closing out the customizer again.

#8 @karlazz
5 years ago

Thank you for the clarification. I stripped off the query params. With the patch in place, when I closed the customizer by hitting the x in the upper left, I was returned to the Dashboard. Without the patch I ended up at the themes page.

#9 @celloexpressions
5 years ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Future Release to 4.4

This looks fine for 4.4.

I wonder if we could easily always detect the referer and go back to the previous page, rather than passing return query args all over the place. If that's feasible, a new ticket should be made for that.

@westonruter
5 years ago

Unslash HTTP_REFERER; use strpos() for starts-with, not contains. Remove whitespace errors.

#10 @westonruter
5 years ago

If we want the Customizer to be more closely aligned with the frontend instead of the admin, then I think this condition should be removed:

( current_user_can( 'edit_theme_options' ) || current_user_can( 'switch_themes' ) ) ||

By default every user accessing the Customizer will have edit_theme_options, as the customize capability from #28605 is a meta capability only available to users with edit_theme_options by default unless explicitly granted by plugin (see #32739). So for the vast majority of users this patch would have no effect at all, other than to redirect them to the admin dashboard as opposed to the themes page if they landed on customize.php directly (via bookmark).

Replying to celloexpressions:

This looks fine for 4.4.

I wonder if we could easily always detect the referer and go back to the previous page, rather than passing return query args all over the place. If that's feasible, a new ticket should be made for that.

Actually, we have this in the wp_get_referer() function. So given above, I think we could implement the logic for determining $return if it is not explicitly provided via:

$referer = wp_get_referer();
if ( $url ) {
	$return = $url;
} elseif ( $referer ) {
	$return = $referer;
} elseif ( current_user_can( 'edit_theme_options' ) || current_user_can( 'switch_themes' ) ) {
	$return = admin_url( 'themes.php' );
} else {
	$return = home_url();
}

But to me, I think that the redirect to admin_url() might as well be removed altogether given the above reasoning:

we'd like to emphasize the connection between the Customizer and the frontend rather than the admin

This ticket was mentioned in Slack in #core by sergey. View the logs.


5 years ago

#12 @SergeyBiryukov
5 years ago

  • Owner set to westonruter
  • Status changed from new to assigned

#13 @westonruter
5 years ago

Any patch here will need to be refreshed once #33898 lands.

@westonruter
5 years ago

#14 follow-up: @westonruter
5 years ago

I've refreshed the patch in 32637.5.diff and implemented the change where I think the link to themes.php can be removed altogether. I think the reason why the themes.php link is there to begin with is because the Live Preview links on the Themes page lack the return parameter, so they link to URLs like <http://src.wordpress-develop.dev/wp-admin/customize.php?theme=twentyeleven>. If the user then reloaded the page while in the Customizer which was opened by the loader, then clicking Close would take the user back to the Themes page in Core's current state. This assumes that the Customizer will normally be accessed via the Live Preview button on the Themes admin page, which I don't think is true. So I think the change there is that the Live Preview links just need to open the Customizer with the return param provided.

Thoughts?

This ticket was mentioned in Slack in #core by sergey. View the logs.


4 years ago

#16 in reply to: ↑ 14 @SergeyBiryukov
4 years ago

Replying to westonruter:

So I think the change there is that the Live Preview links just need to open the Customizer with the return param provided.

Makes sense to me.

For reference, the themes.php link was added in [20476], changed in [21028] and [29170].

@westonruter
4 years ago

#17 @westonruter
4 years ago

  • Keywords good-first-bug removed

OK, 32637.6.diff adds the return param to the URLs used in the Live Preview links on the Themes admin page. The return is set to the current REQUEST_URI. I was initially thinking this would help users return to the search that they had been making, but I realize that the search UI now uses replaceState to dynamically update the URL so including the REQUEST_URI would only reflect the initial URL requested. I think this is fine, as this is really just a edge case. We might as well just do:

- 'return' => urlencode( esc_url_raw( wp_unslash( $_SERVER['REQUEST_URI'] ) ) ),
+ 'return' => urlencode( admin_url( 'themes.php' ) ),

#18 @westonruter
4 years ago

  • Keywords commit added; dev-feedback removed

Any objections to commit?

#20 @westonruter
4 years ago

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

In 35483:

Customize: Return user to referring URL when leaving Customizer in absence of return query param.

When referring URL is not available, default returning user to frontend URL instead of admin URL. Themes page is updated to include the return path in Customizer links.

Props McGuive7, westonruter.
Fixes #32637.

#21 @westonruter
4 years ago

In 35635:

Customize: Exclude referer URL from being used for Close link if it is customize.php.

This fixes an edge case where the Close button could never link the user out of the Customizer, if the user initially accessed it without a url param and then clicked a link (provided by a plugin) that took them to another customize.php URL.

See #32637.

#22 @celloexpressions
4 years ago

Additional follow-up bug: #35355.

#23 @westonruter
4 years ago

In 36261:

Customizer: Prevent erroneously directing user to login screen when closing.

Fixes issue where user gets stuck at login screen after trying to close the app if previously they had to first login to access the Customizer. Prevents WP_Customize_Manager::get_return_url() from using wp-login.php as a referer.

Props chandrapatel.
See #32637.
Fixes #35355.

#24 @dd32
4 years ago

In 36363:

Customizer: Prevent erroneously directing user to login screen when closing.

Fixes issue where user gets stuck at login screen after trying to close the app if previously they had to first login to access the Customizer. Prevents WP_Customize_Manager::get_return_url() from using wp-login.php as a referer.

Merges [36261] to the 4.4 branch.
Props chandrapatel.
See #32637.
Fixes #35355.

Note: See TracTickets for help on using tickets.