Roots Discourse

Bedrock Multisite 500 Error Redirect wp-signup.php


#1

Hi,

first of all thank you for this great tools and this nice community. I’ve been reading the posts here for some time now and they have almost always solved my problems.
But now I am stuck with a problem I can’t explain and decided to sign up here to ask for help.

I’ve a local dev environment (with Vagrant and Scotch Box as LAMP stack) in which I had a normal Bedrock installation running. Then I converted the site into a multisite installation (domain-based) and added a new sub-site. After this I mapped a new local domain to the sub-site. So everything looks like this:

Main-site: myfirstdomain.local
Sub-site: mysubdomain.myfirstdomain.local then changed to myseconddomain.local

Everything is working fine locally. The main-site is available under myfirstdomain.local and the second site is available under myseconddomain.local

Now for testing I’ve uploaded all the needed files to the live server (hosted on SiteGround). I’m not using Trellis or something else. I do it by hand at the moment.
I replaced the local domain names in the database via “wp search-replace” like this:

Main-site: myfirstdomain.local -> myfirstdomain.example. com
Sub-site: myseconddomain.local -> myseconddomain.example. com

(Please ignore the space before “com”. I had to put them there because there is no way to remove the link and as a new user I’m only allowed to post four links)

I modified the .env and changed the variables. I changed the webroot of both subdomains to the /web/ directory.

Then I opened myfirstdomain.example. com in my webbrowser and got immediately redirected to myfirstdomain.example. com/wp-signup.php?new=myfirstdomain.example. com. Same for myseconddomain.example. com which got redirected to myseconddomain.example. com/wp-signup.php?new=myseconddomain.example. com.
Both show a 500 Internal Server Error and backend and frontend are not working.

Some additional information:

  • There is no www
  • There is no SSL
  • I use the multisite-url-fixer mu-plugin

This is what I tried so far:

  • I’ve checked the error logs (empty)
  • I’ve checked the file permissons
  • I’ve checked the PHP version
  • I’ve checked the application.php for misconfiguration
  • I’ve checked the .htacces in /web/ for misconfigruation
  • I’ve set the webroot to the directory below /web/ and used a .htaccess in there to rewrite to the /web/ folder because I thought the webserver can’t read the .env file due to the fact that it was below the webroot before
  • I’ve cleared my cookies and cache
  • Removed all plugins and themes

It seems like WordPress is doing something because of the redirect but I can’t find the problem.
As I mentioned I’ve changed the domains from local second-level domains (e. g. myfirstdomain.local) to live third-level domains (e. g. myfirstdomain.example. com). Could this be a conflict with the multisite functionallity because it is a domain-based installation which normally uses subdomains? Please take a look again how I changed the domains.

I hope you understand my problem. If you need more information please ask.

Kind regards,

Tim

Just to clearify: The mentioned (sub-)domains are not the domains I use.


#2

Hi there! Can you please share the contents of the config where you’ve made your changes for multisite, along with your .env file?

We’re mostly used to Nginx based setups over here, would it be possible for you to try something besides Scotch Box? Trellis, Valet, Local by Flywheel, etc


#3

Sure, here are the files I modified:

.env

DB_NAME=mydatabase
DB_USER=mydatabaseuser
DB_PASSWORD=mydatabasepassword

# Optional variables
DB_HOST=localhost
DB_PREFIX=mydatabaseprefix_

WP_ENV=development
WP_HOME=http://myfirstdomain.example.com
WP_SITEURL=${WP_HOME}/wp
DOMAIN_CURRENT_SITE=myfirstdomain.example.com

# Generate your keys here: https://roots.io/salts.html
AUTH_KEY='mysalt'
SECURE_AUTH_KEY='mysalt'
LOGGED_IN_KEY='mysalt'
NONCE_KEY='mysalt'
AUTH_SALT='mysalt'
SECURE_AUTH_SALT='mysalt'
LOGGED_IN_SALT='mysalt'
NONCE_SALT='mysalt'

application.php (added these lines)

/**
 * Multisite Setup
 */
Config::define('WP_ALLOW_MULTISITE', true);
Config::define('MULTISITE', true);
Config::define('SUBDOMAIN_INSTALL', true);
Config::define('DOMAIN_CURRENT_SITE', env('DOMAIN_CURRENT_SITE') ?: 'myfirstdomain.example.com');
Config::define('PATH_CURRENT_SITE', env('PATH_CURRENT_SITE') ?: '/');
Config::define('SITE_ID_CURRENT_SITE', env('SITE_ID_CURRENT_SITE') ?: 1);
Config::define('BLOG_ID_CURRENT_SITE', env('BLOG_ID_CURRENT_SITE') ?: 1);

Config::define('COOKIE_DOMAIN', $_SERVER['HTTP_HOST']);

.htaccess

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp/
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) wp/$1 [L]
RewriteRule ^(.*\.php)$ wp/$1 [L]
RewriteRule . wp/index.php [L]
</IfModule>

# END WordPress

I don’t have much experience with Nginx setups. And in the local environment (Vagrant and Scotch Box) everything is working like a charm. The only difference I see is the domain thing described here:

Thank you


#4

Okay, I tried something out.

In my local environment I added the following local third-level-domains:

site1.testsite.local and site2.testsite.local

Then I modified the .env and the application.php (even tho its not necessary).

After this I replaced myfirstdomain.local with
site1.testsite.local and myseconddomain.local with site2.testsite.local in the database (via wp search-replace).

And tada :tada:, same behavoir in my local environment now.

So I think this could be the problem like I mentioned here:

I will try some more things now to fix this problem.


#5

Okay, some days ago I figured out what caused the problem. The type of problem is kinda embarrasing but I want to share the solution if somebody else stumbles over this.

I replaced the the domains from local to staging environment with the protocol (http:// or https://). But I did not think about that there could be some more database entries without the protocol.

So after I run search and replace there were still some references to the local environment.

The (obvious) solution: If the protocol doesn’t change from the two environments just replace the domains without it.

As I wrote, this is kinda embarrasing because it’s such a obvious problem. But it happens. :crazy_face: