• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Question too may redirects on wordpress sites

®
If
www.mydomain.tld
then change to
mydomain.tld

else
if
mydomain.tld
then change to
www.mydomain.tld

But if it is now working, can it be that after changing the default hosting setting (www/non-www/none) WAS the reason and you simply did not wait on the server restart interval to pass before?

Nope still not working :) Meant to say all seems to be correct, wp_options siteurl and home got the value of the corresponding site it must go to. I can also see htaccess file is in place. What you mean by www/non-www/none?

I have also replaced the *main_subscriptiondomain mentioned earlier with new htaccess and that is working. Now just to get the WordPress sites up and running again.

Can this also be because of permissions? The last thing that changed on the server was the permissions. I have been troubleshooting this since last night so not sure what else can be the problem.

Also, I had a look at the access logs and all seems to run stable, here is extract from the log:
2016-12-19 14:47:16 Access {myip} 301 GET /index.php HTTP/1.0 334 Apache access
 
Last edited:
Manually reset permissions and owner of a subscription
Code:
# chown [username]:psaserv /var/www/vhosts/SUBSCRIPTIONNAME
# chmod 755 /var/www/vhosts/SUBSCRIPTIONNAME
# chown -R [username]:psacln /var/www/vhosts/SUBSCRIPTIONNAME/httpdocs
or Plesk file system permissions repair tool:
Code:
# plesk repair fs

The log entry of your post only says that a 301 redirect was initiated. Maybe a security software is doing it when index.php is opened?[/code]
 
Thank you Peter! I ran the plesk repair but still the same thing. Still getting the ERR_TOO_MANY_REDIRECTS error message. Also ran the 'plesk repair web' mydomain.com command, no luck :( Here is my access log, I don't have anything in my error logs.

2016-12-19 18:43:54 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:54 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:54 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:54 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:55 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:55 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:55 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:56 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:56 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:57 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:57 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:57 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:57 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:58 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:58 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:58 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:59 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:59 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:43:59 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:04 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:05 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:05 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:06 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:06 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:06 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:07 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:07 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:08 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:09 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:09 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
2016-12-19 18:44:10 Access 301 GET /index.php HTTP/1.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 237 Apache access
 
Last edited:
Let's sum it up:
- It is not .htaccess.
- It is not the "hosting settings" configuration.
- It is not the wp_options configuration.
- It is not file permissions.
- It is not nested WP installations.

Very, very, very unlikely.

Maybe it is a security software/plugin of Wordpress that is malfunctioning? If all other settings are correct, have to looked inside index.php? Is that even a Wordpress file? Does it have an http-equiv Refresh line in the <head>-section? What happens if you remove all files from the /[otherdomain] subdirectory and only put an index.html file with "OK" as content into it? Just to rule out that the Wordpress installation itself is malfunctioning.

I am out of ideas. A 301 redirect is something that must explicitely configured. It can't just happen.
 
I know it is not making sense at all.

The thing nothing was done on any of the WordPress sites at all that can affect this.
Yes all looks good inside the index.php file, here is gist: https://gist.github.com/stephangriesel/d8a9aa0125eef508b7b7af45bfa229d8#file-gistfile1-txt.
Moved all files/folders to backup folder and created index.html file with 'ok' and it is working.

I can access the backend (wp-admin) though, so can maybe try backup and restore. Thats the last resort I can think of.

UPDATE: I tried the restore, not working either :(
 
Last edited:
Ended up spinning up new VPS, reconfigure and just backup and restore sites. I don't know until now what causes this. I have a feeling it might have been permissions, because the last thing I did on the server was create FTP user and next thing I saw the new FTP was owner of all folders, not sure why that happened? I explicitly set the user to only access certain folder but all just went haywire after this. Anyway, so new VPS set up, sites restored and all working again. At least I have DR site now I can use to mirror my sites. Learned alot in the process but happy all working again.
 
Back
Top