[wp-trac] [WordPress Trac] #13779: Preview doesn’t work - WP installed in its own directory

WordPress Trac noreply at wordpress.org
Wed Jul 13 17:05:22 UTC 2022


#13779: Preview doesn’t work - WP installed in its own directory
-------------------------------------+-----------------------------
 Reporter:  antares19                |       Owner:  SergeyBiryukov
     Type:  defect (bug)             |      Status:  reviewing
 Priority:  normal                   |   Milestone:  Future Release
Component:  General                  |     Version:  2.9.2
 Severity:  normal                   |  Resolution:
 Keywords:  2nd-opinion needs-patch  |     Focuses:
-------------------------------------+-----------------------------
Changes (by desrosj):

 * keywords:  2nd-opinion => 2nd-opinion needs-patch
 * milestone:   => Future Release


Comment:

 I came across this one going through tickets missing milestones.

 In my testing, this issue still exists, and is actually much worse with
 the block editor.

 Using the steps above, if you open the block editor without logging out
 and logging back in, there are several endpoints that are repeatedly
 retried without stopping. The repeated requests are:

 - `/wp/v2/block-patterns/patterns`
 - `/wp/v2/block-patterns/categories`
 - `/wp/v2/themes
 - `/wp/v2/users`
 `index.php?rest_route=/&_fields=description,gmt_offset,home,name,site_icon,site_icon_url,site_logo,timezone_string,url&_locale=user`
 - `/wp/v2/templates/twentytwentytwo//single` (not sure why the double
 slash there. Something seems missing, but this is a separate problem).

 Since the root of this bug has resurfaced several years later in a
 different form, it's reasonable to think that it will continue to cause
 issues in the future and I think that it would be best to fix this issue.

 I think a good way forward would be to:
 - Add a note to the Site Address field that if the setting's value is
 changed the user will be logged out.
 - Call `wp_clear_auth_cookies()` after all needed operations have
 completed.
 - Redirect them to the login screen with a `redirect_to` parameter
 pointing back to the general options page with a success message asking
 them to log back in.

 This will fix the issue for the current user, but theoretically this will
 happen for all users actively logged in. So it's not a full fix.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/13779#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list