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

[celloexpressions]

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.

[McGuive7]

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

[McGuive7]

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

[McGuive7]

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.

[McGuive7]

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

[celloexpressions]

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]

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

[McGuive7]

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.

[McGuive7]

Anyone? Bump.

[karlazz]

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.

[McGuive7]

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.

[karlazz]

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.

[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.

[westonruter]

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

[westonruter]

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

[westonruter]

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

[westonruter]

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?

[SergeyBiryukov]

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]

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

[westonruter]

Any objections to commit?

[wonderboymusic]

Go ahead.

[westonruter]

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.

[westonruter]

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.

[celloexpressions]

Additional follow-up bug: #35355.

[westonruter]

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.

[dd32]

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.