Incorrect automatic redirects caused by an intermediate post slug during save in WordPress 7.1+
There appears to be a compatibility issue between WordPress 7.1+ and Redirection's automatic monitoring of post permalink/slug changes.
Since WordPress 7.1, the post slug/permalink can apparently pass through an intermediate state during the save process. Redirection may detect this intermediate value as a real slug change and create an automatic redirect before WordPress has finalized the post's actual permalink.
For example, the final and valid permalink of a post is:
/محمد-مهيوب-خمس-سنوات-في-مطاردة-العط
However, during the save process, Redirection may detect the following percent-encoded representation as the new destination:
/%d9%85%d8%ad%d9%85%d8%af-%d9%85%d9%87%d9%8a%d9%88%d8%a8-%d8%ae%d9%85%d8%b3-%d8%b3%d9%86%d9%88%d8%a7%d8%aa-%d9%81%d9%8a-%d9%85%d9%83%d8%a7%d9%81%d8%ad%d8%a9-%d8%a7%d9%84%d8%b9%d8%b7
Redirection then creates a redirect such as:
/محمد-مهيوب-خمس-سنوات-في-مطاردة-العط
→
/%d9%85%d8%ad%d9%85%d8%af-%d9%85%d9%87%d9%8a%d9%88%d8%a8-%d8%ae%d9%85%d8%b3-%d8%b3%d9%86%d9%88%d8%a7%d8%aa-%d9%81%d9%8a-%d9%85%d9%83%d8%a7%d9%81%d8%ad%d8%a9-%d8%a7%d9%84%d8%b9%d8%b7
But that percent-encoded value was never actually committed as the final slug/permalink. After the save is complete, the post still has this canonical permalink:
/محمد-مهيوب-خمس-سنوات-في-مطاردة-العط
As a result, Redirection can create a redirect from the current permalink to an intermediate representation of the same permalink, or to a permalink state that was never actually committed.
This is not necessarily an Arabic-specific problem. Arabic makes the issue particularly easy to observe because the difference between Unicode and percent-encoded forms is obvious, but the underlying problem appears to be related to how permalink/slug changes are detected during the WordPress save lifecycle.
The key issue seems to be timing:
- WordPress begins saving the post.
- The post slug/permalink temporarily has an intermediate value.
- Redirection detects that value as a permalink change.
- Redirection creates an automatic redirect.
- WordPress subsequently finalizes the post with a different slug/permalink.
- The intermediate value was never the actual final permalink, but the redirect remains in Redirection.
This can result in incorrect, redundant, or unnecessary redirects, including redirects whose destination was never actually used by the post.
The problem appears to be related to detecting the permalink change too early in the save lifecycle rather than waiting until WordPress has completely finalized the post.
It would be useful to compare the permalink/slug values seen at different points in the save lifecycle, for example:
pre_post_update
post_updated
wp_after_insert_post
The important question is whether Redirection is detecting an intermediate post_name/permalink state before WordPress has finished finalizing the post.
Ideally, automatic redirect creation should compare the previous permalink with the final canonical permalink only after the post save operation has fully completed, so that intermediate slug states are not treated as real permalink changes.
Incorrect automatic redirects caused by an intermediate post slug during save in WordPress 7.1+
There appears to be a compatibility issue between WordPress 7.1+ and Redirection's automatic monitoring of post permalink/slug changes.
Since WordPress 7.1, the post slug/permalink can apparently pass through an intermediate state during the save process. Redirection may detect this intermediate value as a real slug change and create an automatic redirect before WordPress has finalized the post's actual permalink.
For example, the final and valid permalink of a post is:
However, during the save process, Redirection may detect the following percent-encoded representation as the new destination:
Redirection then creates a redirect such as:
But that percent-encoded value was never actually committed as the final slug/permalink. After the save is complete, the post still has this canonical permalink:
As a result, Redirection can create a redirect from the current permalink to an intermediate representation of the same permalink, or to a permalink state that was never actually committed.
This is not necessarily an Arabic-specific problem. Arabic makes the issue particularly easy to observe because the difference between Unicode and percent-encoded forms is obvious, but the underlying problem appears to be related to how permalink/slug changes are detected during the WordPress save lifecycle.
The key issue seems to be timing:
This can result in incorrect, redundant, or unnecessary redirects, including redirects whose destination was never actually used by the post.
The problem appears to be related to detecting the permalink change too early in the save lifecycle rather than waiting until WordPress has completely finalized the post.
It would be useful to compare the permalink/slug values seen at different points in the save lifecycle, for example:
The important question is whether Redirection is detecting an intermediate
post_name/permalink state before WordPress has finished finalizing the post.Ideally, automatic redirect creation should compare the previous permalink with the final canonical permalink only after the post save operation has fully completed, so that intermediate slug states are not treated as real permalink changes.