Forwarded to devs Error 500 exceeding 10 redirects after WordPress toolkit cloning

[Xav2c]

Username:

TITLE

Error 500 exceeding 10 redirects after WordPress toolkit cloning

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Plesk Obsidian
Version 18.0.45
Ubuntu 20.04.5

PROBLEM DESCRIPTION

After cloning a WordPress instance to another domain, I get random 500 errors on whole page or on some resources.
Everything checks out on the cloned WordPress instance, no htaccess misconfiguration, no redirects in database.

Until I restart the Apache service then everything is fine and fixed.

STEPS TO REPRODUCE

Clone WordPress instance to another domain using WordPress toolkit cloning feature.

ACTUAL RESULT

Visit the cloned website, open the dev console on your browser and navigate a bit between pages : random 500 errors on multiple resources and some pages won't load randomly.
error.log will show multiple messages:
Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: Example Domain

EXPECTED RESULT

Expected no 500 errors

ANY ADDITIONAL INFORMATION

Fixes itself when Apache is restarted.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug

 

[Bitpalast]

There may be image files with absolute URLs in the site's content that are either still pointing to the old URL or that are mismatching the www/non-www or https/http spelling of the URL. Cloning does not cover all such content changes, specifically when URLs have been stored as fully qualified paths. Another thing could be "includes" that are used by a plugin. In many cases includes that try to access the wrong URL create a 404, which again may be redirected to a page that does not exist so than another 404 is caused and another redirect etc. It's probably something like that.

 

[Xav2c]

I checked for the errors you mentionned, in the database, there are none (I never use full http references in my code).
As far as I can tell, cloning does look for fullpath URL references and rewrites them in the DB.
I also tried to clear the transients, did not fix the issue.
Also, these errors would not magically fix themselves by simply restarting Apache, and in this case, once Apache is restarted, there are no errors anymore.

 

[Xav2c]

Visit the cloned website, open the dev console on your browser and navigate a bit between pages : random 500 errors on multiple resources and some pages won't load randomly.

And by random I mean that for example a specific page wont load: error 500,
refresh : tadaaa it loads,
refresh again, some images are not here,
refresh again : some ressources (CSS, JS) are absent, but the images not loading previously are visible.

It's really random.

 

[Bitpalast]

Does your website use a plugin that generates images on-the-fly, meaning that these images are no physically existing files on disc but are created as a stream through a PHP output? What are the "some resources" you are mentioning in your initial post?

 

[Xav2c]

Does your website use a plugin that generates images on-the-fly,

No.

What are the "some resources"

Please read all my messages, the answer is there, I can't make myself clearer.
Everything you suspect would not magicaly be fixed by an Apache restart if it was true.

 

[Bitpalast]

The reason why I am asking about the on-the-fly resource generation and the specific resources that are affected is that is is very likely that the issue is caused by some sort of caching which leads to a mismatch between the web server URL and the actual, physical resource location. It's always been that in similar cases. However, if this is not the case for you, I think that hands-on support by a Plesk staff member (official Plesk support) will be required to get to the root cause of the issue.

 

[Evgeny]

@Xav2c, could you share debug logs of these redirections? It can help to determine which rules affect http requests.

 

[Xav2c]

@Evgeny this is a sample of the subscription's error.log since when the issue started and before I restarted Apache, for confidentiality purpose I replaced the domain by

subscription-domain

and also the name of the Wordpress theme and client IPs. This is not the first time it happens, happened everytime I clone a wp website since I migrated this server two month ago.

Do you need something else?

 

[Evgeny]

This file contains only records about the errors themselves. Sorry, I meant debug logs that describe how Apache processes a request.

mod_rewrite - Apache HTTP Server Version 2.4

How to debug Apache mod_rewrite

I have two main problems with mod_rewrite: There is no meaningful error reported when I have an invalid rule To reliably test each modification, I have to erase Google Chrome's cache. This isn't ...

stackoverflow.com

There should be something like:

[Mon Sep 12 10:43:22.987046 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial] [perdir honeypot1.html/] strip document_root prefix: /path-to-file/honeypot2.html -> /honeypot2.html
[Mon Sep 12 10:43:22.987055 2022] [rewrite:trace1] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial] [perdir honeypot1.html/] internal redirect with /honeypot2.html [INTERNAL REDIRECT]
[Mon Sep 12 10:43:22.987130 2022] [rewrite:trace3] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#1] [perdir honeypot2.html/] applying pattern '.*' to uri '/path-to-file/honeypot2.html'
[Mon Sep 12 10:43:22.987160 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#1] [perdir honeypot2.html/] rewrite '/path-to-file/honeypot2.html' -> '/path-to-file/honeypot1.html'
[Mon Sep 12 10:43:22.987169 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#1] [perdir honeypot2.html/] strip document_root prefix: /path-to-file/honeypot1.html -> /honeypot1.html
[Mon Sep 12 10:43:22.987177 2022] [rewrite:trace1] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#1] [perdir honeypot2.html/] internal redirect with /honeypot1.html [INTERNAL REDIRECT]
[Mon Sep 12 10:43:22.987226 2022] [rewrite:trace3] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#2] [perdir honeypot1.html/] applying pattern '.*' to uri '/path-to-file/honeypot1.html'
[Mon Sep 12 10:43:22.987236 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#2] [perdir honeypot1.html/] rewrite '/path-to-file/honeypot1.html' -> '/path-to-file/honeypot2.html'
[Mon Sep 12 10:43:22.987244 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#2] [perdir honeypot1.html/] strip document_root prefix: /path-to-file/honeypot2.html -> /honeypot2.html
[Mon Sep 12 10:43:22.987257 2022] [rewrite:trace1] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#2] [perdir honeypot1.html/] internal redirect with /honeypot2.html [INTERNAL REDIRECT]
[Mon Sep 12 10:43:22.987321 2022] [rewrite:trace3] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#3] [perdir honeypot2.html/] applying pattern '.*' to uri '/path-to-file/honeypot2.html'
[Mon Sep 12 10:43:22.987332 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#3] [perdir honeypot2.html/] rewrite '/path-to-file/honeypot2.html' -> '/path-to-file/honeypot1.html'
[Mon Sep 12 10:43:22.987341 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#3] [perdir honeypot2.html/] strip document_root prefix: /path-to-file/honeypot1.html -> /honeypot1.html
[Mon Sep 12 10:43:22.987356 2022] [rewrite:trace1] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#3] [perdir honeypot2.html/] internal redirect with /honeypot1.html [INTERNAL REDIRECT]
[Mon Sep 12 10:43:22.987409 2022] [rewrite:trace3] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#4] [perdir honeypot1.html/] applying pattern '.*' to uri '/path-to-file/honeypot1.html'
[Mon Sep 12 10:43:22.987420 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#4] [perdir honeypot1.html/] rewrite '/path-to-file/honeypot1.html' -> '/path-to-file/honeypot2.html'
[Mon Sep 12 10:43:22.987437 2022] [rewrite:trace2] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#4] [perdir honeypot1.html/] strip document_root prefix: /path-to-file/honeypot2.html -> /honeypot2.html
[Mon Sep 12 10:43:22.987445 2022] [rewrite:trace1] [pid 1] mod_rewrite.c(483): [client 127.0.0.1:52303] 127.0.0.1 - - [......][rid#.../initial/redir#4] [perdir honeypot1.html/] internal redirect with /honeypot2.html [INTERNAL REDIRECT]