Multisite forcing login for every site

I think you’re up against the current restrictions on 3rd party cookies. When you redirect to a new domain, the auth cookies from the main domain cannot be passed along, forcing a new login. Maybe such a scheme worked in the past before CSP restrictions became more stringent. To avoid repeated logins, you probably need an authentication scheme completely removed from cookies. Perhaps through transients or something. Such a departure could introduce serious security vulnerabilities unless it is studied very carefully.

My advice is to live with the repeated login necessity. The options are not good.

To get the domain mapping working, I would switch to a subdirectory style network and utilize virtual hosts (.htaccess rules if you cannot do virtual hosts) to send domain requests to the correct network subdirectory. Switching from subdomain to subdirectory network is rather messy, but it is doable. I’ve only gone the other way so far, so I can’t offer further insight.

You definitely need another installation to practice on. A local installation is most convenient. You may not need an identical clone, the underlying data doesn’t need to match if you are working on the workings of WP itself and not editing content. If you do clone for whatever reasons, I suggest adding the domains to your local machine’s hosts file so your installation behaves locally just like the live site with the same domains and all. This means you cannot access the actual live domains anymore from this machine without first taking the domains back out of hosts. You shouldn’t need access if you have a clone, right? ??

I’m right concerned about those 120+ plugins. Just the wasted space of a plugin that’s not being used disturbed my afternoon nap. How could you do that to me? <GRIN>

I’d fire up my laptop or something with a decent spreadsheet on it and start with number one plugin in the roster do a look through for the first site to use it and make an X under that sites column. You get all the way to the last site without a check or X then you can make the decision to keep or delete. They make paper with columns for doing this kind of stuff, too.

If it’s a useful plugin ‘of good report’ then keep it if you wish but now it’s a conscious decision on your part. If you’re not sure then rename it with something like an added number (I use ‘1234’ a lot for stuff like this) or the word ‘hold’ or ‘bak’.

You can do the same with themes but I’d keep all the ‘Twenty’ series themes and any child themes someone may have created. Remember, with child themes there’s a dependency on the parent theme so keep the parent themes, too.

What I’d do next is to find a new server. No windows based host either. Linux and Apache! No Nginx or Lightspeed either. Same specs as what you have already hardware-wise or upgradeable to those specs.

You’ll need a domain name for that new host. Install a current WordPress and turn it into a network. You won’t need the domain mapper plugin or sunrise either (unless you need sunrise for something else but that’s a whole other story).

Take your time and export content then import each website as you go. You have the life of the contract to get this done not accounting for expense or necessity.

I usually move my servers around about every three years anyway so this is probably something that needs doing by now.

@bcworkz, Ugh, the repeated login thing is not great news. However, my boss has been leaning towards breaking these all out as individual sites sometime down the line, in which case we’d be logging into them all separately anyway. But in your next paragraph, you implied that if I went to a subdirectory install, this might all work without the extra logging in. Am I understanding you correctly there? If that’s the case, I might be able to pull that off.

@jnashhawkins, sorry for disturbing your nap haha — believe me, it doesn’t help my sleep much either! I’ve done a lot of cleanup and managed to get it down to 111 plugins so far, and removed several themes as well (still have 55 of those). The network is on AWS, not my own hosting, and frankly the server sucks. It hasn’t been maintained as far as updates, has many issues (the symlinks alone, OMG) and reboots itself anywhere from 6-12 times a day. Oh and did I mention, there are at least 2 or 3 other multisite networks on here that I haven’t even delved into yet? I’m trying to whip everything into shape but holy cow is this a mess. I definitely like your idea of changing up servers and as I understand it we are looking to upgrade soon.

Oh, my you do have a right heavy task handed to you.

You might want to try advertising somewhere like https://jobs.wordpress.net for a little more help to whip those beasts into line.

As to moving sites off the multisite completely? I probably wouldn’t do that but I’m very comfortable with multisite.

Discrete sites just look like more work to me!

A subdirectory install will not be any help with the multiple login issue. Sorry to get your hopes up. The issue is client side security. Due to the different domains, the browser will not send the necessary auth cookie to a different domain. It has no way of knowing the domain leads to the same server. The two sites could be on different continents for all it knows.

The reason I suggest a subdirectory installation is WP isn’t really setup to handle different primary domains. It’s intended for subdomain based sites. The various primary domains takes a dedicated plugin or some code finagling to get them to work. OTOH, virtual hosts and subdirectories are a natural fit. Aside from defining the virtual host, nothing special needs to be done.

Thank you for the extra info, @bcworkz and @jnashhawkins. Not the resolution I hoped for but all good information to know.

Wow! I am so glad you posted this and a big thank you to @bcworkz for explaining what’s going on. I have posted about EXACTLY this issue on my own site several times since June, including a bug report to Trak, and got no solid answers. I knew I was not alone, because there were several reports in mid-June about the exact same issue — but no one could explain the cause. Just broken websites and no answers.

So what happened in the universe? Did all the browsers change their security protocols at the same time? That’s the only thing that makes sense to me, because it was working just fine and then “BOOM”. I did not make any changes to my site, it just broke.

I was using the WPMUDEV domain mapping plugin (which is now legacy but still works) and so far it is the only one that seems to fix the issue of multiple logins, because it has a “cross-domain login” setting.

However, I had that plugin, with that setting on, installed and working PRIOR to the day everything went BOOM, so at the time I thought that was the cause of failure — now I think it is the only solution.

I suspect that there may have been some other plugin that initially reacted badly to whatever happened in the universe (e.g., we had some early symptoms involving WMUDEV’s Defender plugin, which is for security). Then some cascade of events led to a conflict with domain mapping. Or perhaps both problems happened at the same time, and I didn’t realize it.

You might want to give that plugin a try! It’s on github now as open source, but without support (unless you’re a member of WPMUDEV, which I recommend, since they provide support for everything WP). I’m going to try using it again, with the Defender plugin disabled. I have tested it on a sandbox site, and so far it is the only solution to the multi-login problem.

Security question:

Our larger problem is that we long ago bypassed the use of wp-login for greater security. We were getting slammed by bots trying to hack their way into our site via the standard page, so we disabled it and created a custom login page with a different URL. But all the plugin options I have considered to avoid logging in on each subsite (e.g., turning WP into an Oauth client/server) have failed because they rely on the standard wp-login page.

Do you all have any recommendations about using or not using the standard login page? Does everyone have as much trouble with it as we do, or are we doing something wrong? Is there a better option than using a different page?

One other comment: to @singer74 — You earlier mentioned that your site is “in a subdirectory”. I wanted to be sure you don’t confuse that with a “subdirectory installation” of WP Multisite.

Putting all of WP into a subdirectory of your webroot is a thing. You could have a non-WP website at example.com, which lives in the webroot on index.html (/path/to/webroot/index.html) AND a WP blog in a subdirectory of the website at example.com/blog — where your entire WP codebase lives in the literal subdirectory /path/to/webroot/blog on the server.

But a WP Multisite has two options for how the URLs are formed for all the sub-sites (a.k.a. “blogs”) within the multisite are fashioned. In a “subdomain installation” the URLs are formatted as subdomains (blog1.example.com, blog2.example.com, etc.). In a “subdirectory installation” the blog URLs are formatted as virtual subdirectories: example.com/blog1, example.com/blog2, etc. They do not literally live in subdirectories on the server named blog1 and blog2.

You could potentially have a WP Multisite running in a subdirectory path of your SERVER, but it could be set up as a “subdomain installation” or a “subdomain multisite”. Not that I recommend such a wild configuration, but I’m just trying to show the difference between them. Subdomain vs subdirectory in multisite is just referring to the configuration of multisite blog URLs NOT the location of files on the server.

If you knew all that, hopefully it will help someone else who stumbles on this ??

• This reply was modified 5 years, 3 months ago by kalico.

Thanks @kalico for clarifying, that makes more sense now. Yes the network as a whole is installed in a subdirectory so I guess that’s not a problem.

Just as an update to this issue, we (the server admin and I) did finally solve this. The server admin did something to change the way cookies are processed…. not entirely sure what it was but the sites are functional now. We have to suck it up as far as logging into every site individually, but that’s not so bad.

We are now working on a plan to plow through all these networks (there are 6 I believe) and distribute the clunkier ones to their own servers. I’m probably looking at about 6 months until we get through it and it is all healthy, but hey, good for my pocketbook. $$ Thanks everyone.