Have you looked at the URL monitoring option here:
https://redirection.me/support/options/
It should handle this situation.
Yes, I have that option activated. But it doesn’t work for child paths. I see there is another option to asociate a child path, i.e. “/amp”. But what if it needs to be dynamic or if there are more than one, i.e. for amp and for all attachements of the parent post?
This situations are handled by WordPress, why your plugin replace this core functionality? Is there any reason?
I’m not entirely sure what the question is. The plugin changes WordPress core redirections as it clashes with the plugin.
You have one post that change the slug:
example.com/old-post-slug to example.com/new-post-slug
Then you need to redirect
example.com/old-post-slug/amp to example.com/new-post-slug/amp
AND
example.com/old-post-slug/some_attachmet to example.com/new-post-slug/some_attachmet
AND
example.com/old-post-slug/other_attachmet to example.com/new-post-slug/other_attachmet
AND
example.com/old-post-slug/feed to example.com/new-post-slug/feed
AND so on
I hope you understand now what I mean.
Can your plugin automatically redirect a modified post and all its children paths?
I’m actually handling this by adding a regex redirection, post by post, but it should be handled by your plugin automatically the same way it is handled by WordPress core, otherwise I see a broken core functionality when your plugin is active.
I’ve made a very quick test modifying ‘redirection/modules/wordpress.php`, lines 26-30, from:
add_action( 'template_redirect', array( $this, 'template_redirect' ) );
// Remove WordPress 2.3 redirection
remove_action( 'template_redirect', 'wp_old_slug_redirect' );
To:
add_action( 'template_redirect', array( $this, 'template_redirect' ), 11 );
// Remove WordPress 2.3 redirection
// remove_action( 'template_redirect', 'wp_old_slug_redirect' );
By hooking your functions with priority of 11 in template_redirect, they will be triggered after the core wp_old_slug_redirect() function (it is hooked with a default priority of 10), it seems that the core old slug redirection works as expected and your plugin still work as expected too, have you tried this? Could you?
Thanks, but that doesn’t really do much as it’s only used for detecting 404s. I will look at attachment redirects separately.
Yes, but they are detected after WordPress has handled them and has performed the old-slug redirection itself, and so your plugin doesn’t break it because it enters in the scene only in case of “true” 404s that WordPress couldn’t handle itself and not before.
I hope it makes sense.
I’m still testing that change and still everything seems to work as expected, please, give a try. I really think you should leave the core functionality untouched unless you are going to introduce a improvement or something different from the core, which doesn’t seem to be the case. Correct me if I’m wrong.
