Editor Redirect Issue with Insert Pages Shortcode

[airflo]

From: Florian Andresen
Date: 18 January 2025
Plugin: Insert Pages (Version 3.11.1)

---

Personal Message

Hi Paul,

I've been using your Insert Pages plugin and encountered a bug that prevents editing pages containing the [insert] shortcode. The editor page would redirect to the inserted page instead of allowing me to edit the parent page itself. I've identified the root cause and implemented a fix that resolves the issue.

I'm using WordPress 6.8.3 with Divi 4.27.5 and the Classic Editor plugin 1.6.7. I guess that this error showed up the first time a few weeks ago.

I've tested the fix on my WordPress installation and it works. The shortcode still functions properly on the frontend, but no longer interferes with the editor. I'm sharing this with you in the hope that you can test it and incorporate it into the official plugin release.

Full disclosure: I found the cause and developed this fix using AI, so you will want to check the code critically. I'm using the classic editor instead of the Gutenberg editor, so I tested the fix only with that and the Divi editor. The suggestion for Gutenberg comes from the AI, I left it in so you can check it.

Thanks for creating and maintaining this useful plugin!

Best regards,

Florian Andresen

---

Issue Description

When a page contains the [insert] shortcode (e.g., [insert page='mypage' display='content' public]), attempting to edit that page in the WordPress admin editor causes the editor to redirect or load the inserted page instead of the parent page. This makes it impossible to edit pages that use the shortcode.

Symptoms:

• Editor appears to "forward" to the included page when opening a page for editing
• Removing the shortcode allows the page to be edited normally
• Deactivating the plugin allows the page (with shortcode) to be edited normally
• Frontend display of pages with the shortcode works correctly

Root Cause:

The shortcode handler insert_pages_handle_shortcode_insert() processes shortcodes even in the admin editor context. During processing, it manipulates several global WordPress variables:

• $post - The global post object
• $wp_query - The global WordPress query object
• $_GET and $_REQUEST - Superglobal arrays
• $GLOBALS['wp']->query_vars - WordPress query variables

When the editor loads a page containing the shortcode, these global manipulations cause WordPress to think it's editing the inserted page rather than the parent page, resulting in the redirect behavior.

Solution

The fix adds a guard clause at the beginning of the insert_pages_handle_shortcode_insert() method to prevent shortcode processing in editor contexts. The shortcode handler now checks for:

1. Classic Editor: Detects when on a post/page edit screen in the admin area
2. Block Editor (Gutenberg): Detects REST API requests for post/page content with context=edit parameter

When either condition is detected, the handler returns early (empty string) without processing the shortcode, preventing any global variable manipulation that would interfere with the editor.

Benefits:

• Pages with shortcodes can now be edited normally
• Shortcode functionality on the frontend remains unchanged
• Works with both Classic and Block editors
• No breaking changes to existing functionality

Code Change

The following code should be added at the beginning of the insert_pages_handle_shortcode_insert() method, right after the global variable declarations:

File: insert-pages.php
Method: insert_pages_handle_shortcode_insert()
Location: After line 279 (after global $wp_query, $post, $wp_current_filter;)

// Don't process shortcode in admin editor context to prevent redirecting to inserted page.
// This prevents the shortcode from manipulating global $post, $wp_query, etc. in the editor.
// Check if we're on a post/page edit screen (classic editor).
if ( is_admin() ) {
  $current_screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
  if ( $current_screen && ( 'post' === $current_screen->base || 'page' === $current_screen->base ) ) {
    // Return empty string to prevent processing in editor.
    return '';
  }
}
// Check if this is a REST API request from the block editor (REST requests may not have is_admin() true).
if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
  // Check if this is likely a block editor request for post/page content.
  $request_uri = isset( $_SERVER['REQUEST_URI'] ) ? esc_url_raw( wp_unslash( $_SERVER['REQUEST_URI'] ) ) : '';
  if ( ( strpos( $request_uri, '/wp/v2/posts/' ) !== false || strpos( $request_uri, '/wp/v2/pages/' ) !== false || 
    strpos( $request_uri, '/wp-json/wp/v2/posts/' ) !== false || strpos( $request_uri, '/wp-json/wp/v2/pages/' ) !== false ) &&
    strpos( $request_uri, '?context=edit' ) !== false ) {
    // This is a REST API request from the block editor requesting post content for editing.
    return '';
  }
}

Testing

The fix has been tested with:

• WordPress admin editor (Classic Editor)
• Divi theme editor
• Frontend display of pages with shortcodes
• Various shortcode attributes and display modes

All functionality works as expected after the fix.

Additional Notes

• The shortcode may not render in the editor preview, but this is expected and acceptable behavior, at least for me
• Frontend functionality is completely unaffected
• The fix is minimal and non-intrusive, only adding early returns in specific editor contexts
• No changes to shortcode syntax or attributes are required

---

Thank you for considering this fix!

[figureone]

You're awesome, thanks for the detailed report! We'll check this out this week and hopefully release a fix. Cheers

[figureone]

Hi, we released version 3.11.2 with a fix, can you test whether it fixes your issue?

We ended up using a more targeted approach, assuming that overwriting the global $post was the culprit (we do this to aid various page builder plugins load their custom scripts and styles). We also did not include the generated code for Gutenberg because we did not see any Gutenberg editor scenarios where the shortcode was attempted to be parsed.

Please reopen the issue if you are still seeing issues on version 3.11.2. Thanks!

[airflo]

Hi Paul,

sadly, this does not fix my issue. Same behaviour as described before.

I will set up a blank Divi 4 instance and test it there. I want to make sure that it's not a plugin conflict issue. This will take some days, I'm afraid, I'm pretty busy at the moment.

In the meantime, can I get you any further info, like logfiles? Would you like me to try out a special debug version?

[airflo]

I cannot reopen this issue as I "do not have permissions" to do so. Could you reopen it, please?

[figureone]

Darn, it might be something specific to Divi which makes this challenging since it's not open source and I don't have a test environment with it. One thing I removed from your suggested code was the check for 'page' === $current_screen->base, which is an invalid value for WordPress, but it's possible Divi uses that.

Can you add a debug line and check your logs to see what that value is? On line 280 of insert-pages.php, temporarily add this:

if ( isset( $current_screen->base ) ) { 
  error_log( 'Current screen: ' . print_r( $current_screen, true ) ); 
}

Then load the page where you experience the issue and share what gets printed to the log file. Thanks!

[airflo]

Hi Paul,

I have setup a fresh instance of WordPress and Divi, and I could not reproduce the behaviour. It seems that there is some incompatibility issue going on with other plugins or custom code. I will try to narrow it down and get back to you.

Best regards,

Florian