You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
More conservative number of retry attempts for failed requests #42400
While testing to see if Core-13779 was still happening in WordPress 6.0, I found that it was, and actually causes potentially greater problems in the block editor.
TLDR of that ticket: When the WordPress files are in a directory and a site is set up to run as such (site.com/wp) and the site is changed to instead be visible from the site's root (site.com), all users who are logged in will not be properly authenticated. This is because the cookie set on login does not exist for the new location.
In the past, this caused issues with the Classic Editor and previewing posts. However, in WordPress 6.0, if you open the block editor, there are repeated requests to the REST API that return 403 responses. After opening the editor with my browser console open, ~500 requests were made in 30 seconds.
Regardless of the root cause of the 403 responses, the editor should not continually retry the same requests infinitely.
Step-by-step reproduction instructions
Create a WordPress install in a subdirectory (/wp for example).
Thanks @desrosj! As you noted in #13509, this is the same endless retry loop: apiFetch keeps refreshing the nonce and retrying the 403 responses. Carrying over to #13509: another reliable way to reproduce it is moving a WordPress install from a subdirectory (/wp) to the site root, so the existing login cookie no longer matches and the editor sends hundreds of failing requests within seconds. Thanks also to @desaiuditd for #32475, which already references #13509, so it continues there. Closing as a duplicate of #13509.
Activity
Mamaduka commentedon Jul 14, 2022
Probably related to #13509.
Mamaduka commentedon Dec 11, 2024
Created a PR with possible fix #67812.
youknowriad commentedon Oct 20, 2026
Thanks @desrosj! As you noted in #13509, this is the same endless retry loop: apiFetch keeps refreshing the nonce and retrying the 403 responses. Carrying over to #13509: another reliable way to reproduce it is moving a WordPress install from a subdirectory (
/wp) to the site root, so the existing login cookie no longer matches and the editor sends hundreds of failing requests within seconds. Thanks also to @desaiuditd for #32475, which already references #13509, so it continues there. Closing as a duplicate of #13509.