Site Editor: Redirect old urls to the new path based ones

[youknowriad]

This backports the change introduced in Gutenberg in this PR WordPress/gutenberg#67199
It includes:

• Redirection of old site editor urls to the new correct ones.
• Removing of condition to prevent loading the site editor.
• Always pass the dashboard link option to the site editor.

Trac ticket: https://core.trac.wordpress.org/ticket/62585

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props youknowriad, peterwilsoncc, joemcgill, mukesh27.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[youknowriad]

This patch will have to wait for the next package update to be able to get committed. As the new urls won't work until the package update.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[joemcgill]

@youknowriad I left one question about the inclusion of an __experimental setting. Otherwise this looks ok to me, though I'm unsure how to confirm that this is doing what is expected. From what I can tell, when I go to a URL like:

/wp-admin/site-editor.php?path=/wp_template

It redirects to a URL like:

/wp-admin/site-editor.php?p=%2Ftemplate

Is this the intended behavior? If so, it would be good to add a set of unit tests for _get_site_editor_redirection_url() that cover this intended behavior.

[youknowriad]

Is this the intended behavior? If so, it would be good to add a set of unit tests for _get_site_editor_redirection_url() that cover this intended behavior.

Yes, this is the intended behavior. Unfortunately, I don't have time to add unit tests or work on PRs at the moment.

[peterwilsoncc]

Unfortunately, I don't have time to add unit tests or work on PRs at the moment.

@youknowriad I've taken the liberty of pushing to your branch and will continue to do so ;)

• documented global
• fixed access annotation
• switched to use wp_safe_redirect() in 6e2a8d8

I'll add some unit tests once I've caught up on the ticket and am clear what they out to be.

[youknowriad]

Thanks @peterwilsoncc

Just want to add that any change you make to these "backport PRs" should ideally also be made in the Gutenberg repository.

[joemcgill]

Thanks for the assist, @peterwilsoncc. I think we can commit this and add tests as a follow-up.

[joemcgill]

Noticed that there was one existing test that was failing due to the new block editor setting being added. Addressed in 8da7a26.

[peterwilsoncc]

@joemcgill Another thing I'd like is to use a wp prefix on the function (because of course I would), are you happy if I rename it _wp_get_site_editor_redirection_url() prior to commit. Otherwise, I'm happy to commit and add tests later.

[joemcgill]

@peterwilsoncc I'm not opposed, but it's worth noting that there already :alot: of private functions in the global space not using this prefix (examples below).

Can you also take a look at updating the relevant code in the GB repo based on your previous changes?

===

Some examples:

26 results - 4 files

WP Dev • src/wp-includes/block-patterns.php:
   17   */
   18: function _register_core_block_patterns_and_categories() {
   19  	$should_register_core_patterns = get_theme_support( 'core-block-patterns' );

  215   */
  216: function _load_remote_block_patterns( $deprecated = null ) {
  217  	if ( ! empty( $deprecated ) ) {

  262   */
  263: function _load_remote_featured_patterns() {
  264  	$supports_core_patterns = get_theme_support( 'core-block-patterns' );

  303   */
  304: function _register_remote_theme_patterns() {
  305  	/** This filter is documented in wp-includes/block-patterns.php */

  348   */
  349: function _register_theme_block_patterns() {
  350  

WP Dev • src/wp-includes/block-template-utils.php:
  237   */
  238: function _filter_block_template_part_area( $type ) {
  239  	$allowed_areas = array_map(

  267   */
  268: function _get_block_templates_paths( $base_directory ) {
  269  	static $template_path_list = array();

  305   */
  306: function _get_block_template_file( $template_type, $slug ) {
  307  	if ( 'wp_template' !== $template_type && 'wp_template_part' !== $template_type ) {

  359   */
  360: function _get_block_templates_files( $template_type, $query = array() ) {
  361  	if ( 'wp_template' !== $template_type && 'wp_template_part' !== $template_type ) {

  461   */
  462: function _add_block_template_info( $template_item ) {
  463  	if ( ! wp_theme_has_theme_json() ) {

  484   */
  485: function _add_block_template_part_area_info( $template_info ) {
  486  	if ( wp_theme_has_theme_json() ) {

  509   */
  510: function _flatten_blocks( &$blocks ) {
  511  	$all_blocks = array();

  540   */
  541: function _inject_theme_attribute_in_template_part_block( &$block ) {
  542  	if (

  557   */
  558: function _remove_theme_attribute_from_template_part_block( &$block ) {
  559  	if (

  577   */
  578: function _build_block_template_result_from_file( $template_file, $template_type ) {
  579  	$default_template_types = get_default_block_template_types();

  816   */
  817: function _build_block_template_object_from_post_object( $post, $terms = array(), $meta = array() ) {
  818  	if ( empty( $terms['wp_theme'] ) ) {

  870   */
  871: function _build_block_template_result_from_post( $post ) {
  872  	$post_id = wp_is_post_revision( $post );

WP Dev • src/wp-includes/block-template.php:
   13   */
   14: function _add_template_loader_filters() {
   15  	if ( isset( $_GET['_wp-find-template'] ) && current_theme_supports( 'block-templates' ) ) {

  231   */
  232: function _block_template_render_title_tag() {
  233  	echo '<title>' . wp_get_document_title() . '</title>' . "\n";

  314   */
  315: function _block_template_viewport_meta_tag() {
  316  	echo '<meta name="viewport" content="width=device-width, initial-scale=1" />' . "\n";

  327   */
  328: function _strip_template_file_suffix( $template_file ) {
  329  	return preg_replace( '/\.(php|html)$/', '', $template_file );

  341   */
  342: function _block_template_render_without_post_block_context( $context ) {
  343  	/*

  367   */
  368: function _resolve_template_for_new_post( $wp_query ) {
  369  	if ( ! $wp_query->is_main_query() ) {

WP Dev • src/wp-includes/blocks.php:
  1885   */
  1886: function _filter_block_content_callback( $matches ) {
  1887  	return '<!--' . rtrim( $matches[1], '-' ) . '-->';

  2097   */
  2098: function _excerpt_render_inner_blocks( $parsed_block, $allowed_blocks ) {
  2099  	$output = '';

  2312   */
  2313: function _restore_wpautop_hook( $content ) {
  2314  	$current_priority = has_filter( 'the_content', '_restore_wpautop_hook' );

[peterwilsoncc]

but it's worth noting that there already :alot: of private functions in the global space not using this prefix (examples below).

Yeah, I know. It's not something we committers have been consistent catching in the past but it's only possible to fix code going forward.

[peterwilsoncc]

Sorry, I just noticed it's using a 301 redirect rather than a 302. I think wp tends to use 302's within the admin as 301s are cached by the browser so it may produce unexpected results once the user is logged out.

[peterwilsoncc]

I think this is good to go in to Core but it will need to be committed shortly after the first package update so the redirected URLs work.