Multisite support

[swalkinshaw]

There's a few features of Bedrock that might make some Multisite setups a problem:

• WP installed in subdirectory
• Custom content folder

Looking at some issues regarding this, it seems like MS support is still a bit of a mess. Related issues:

• https://core.trac.wordpress.org/ticket/27287
• https://core.trac.wordpress.org/ticket/23221
• https://core.trac.wordpress.org/ticket/26969

Here's a potential mu-plugin we may want to consider adding in Bedrock by default: https://gist.github.com/danielbachhuber/9379135

/cc @ddebernardy I'm hoping you can speak to/summarize some of the issues you've ran into and potential solutions.

[etcook]

Scott - I've actually solved this issue two ways.

Using a filter to rewrite the urls, or actually using the rewrite rules for nginx that I was asking about in another issue and posted a solution for. Once those rewrite rules are in place, multisite works as intended, and you don't need the /wp portion in the url any longer.

[etcook]

http://discourse.roots.io/t/recommended-subdomain-multisite-nginx-vhost-configuration-with-new-web-layout/1429/9

[swalkinshaw]

@etcook I actually used your rewrite rules for a MS test install and they worked. But that was when I installed WP normally, then activated multisite from within wp-admin.

I also tried a fresh install through wp core multisite-install (via WP-CLI) and couldn't get it working. Seems like there's a difference between the two install methods which might have to do with the bugs mentioned above.

[etcook]

In both cases, was there a disparity with your home and site url settings? /wp should be removed from both.

[swalkinshaw]

Probably was since with a standard Bedrock install it would be:

• home: http://example.com
• site: http://example.com/wp

I'll have to do more testing

[etcook]

That's correct - but with the rewrite rule, the /wp subdirectory is no longer necessary. Makes for a cleaner multisite install overall, but admittedly takes a bit of human intervention depending on how you're setting it up.

I'd make the rewrite plugin optional, however. Adding such a filter would create unexpected behavior, at least until the bug is resolved. The issue doesn't seem to really be taken seriously at this time.

I don't mind showing you my current setup if you have any interest.

[ddebernardy]

@swalkinshaw: I got it to work fine, yeah, albeit not necessarily the way you'd want it to work.

In essence, I filter siteurl so it returns the home url, and I mess around with the WP rewrite rules and cookies so that nothing breaks when doing so. In doing so, WP in /wp will always return admin urls like /wp-admin, multisite or not, and that fixes all of the problems indirectly.

The code involved is here:

https://gist.github.com/ddebernardy/10529951

The actual bug fixes plugin it's part of should get released shortly as a composer package — I basically need to write a whole bunch of unit tests for it, for my mu-plugin loader and for the wordpress bridge and wordpress bundle packages that they both depend on. ;-)

An alternative approach, which I also tried, is to filter the network admin urls so that they point to e.g. /wp/wp-admin/network instead of the incorrect /wp-admin/network values returned by WP. The main merit of doing so is simplicity; personally, I prefer getting /wp-admin urls.

[swalkinshaw]

@ddebernardy that's a lot of code! Ideally Bedrock would support MS as easily/simply as possible. And it really isn't far off from that now. In fact I think the only main issue is how WP-CLI does multisite installs from scratch. Although the "simplest" method requires rewrites.

Looking forward to seeing your Composer packages though and thanks for checking :)

[ddebernardy]

In that case, a simple filter on the network admin urls (and user admin urls) so as to fix the folders' directory is the way to go. I'm pretty sure I documented a (partial) fix to that in one of the tickets you referenced.

Re the packages, it's in unreleased alpha state, but you can try the package here:

git clone git@mesoconcepts.com:wordpress/app.git

Then run composer install in there, or ./bin/update. Configure by renaming and then editing the dist files in app/config as appropriate. (And yes, it's very much like bedrock or the Mark's WP Skeleton). :-)

[sebastiaandegeus]

I can't seem to get this working. I cannot login on the main website in a multidomain multisite installation. I used this .htaccessfile:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
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 . index.php [L]

The login on the main page just comes back to the same page without any errors.

[francescolaffi]

I'm using this .htaccess on litespeed and it works fine

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
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 . index.php [L]

I dont see much difference other than the slashes before wp/$1, try without it but I dubt that is the problem

stuff you could try:

• clean cookies and go directly to wp-login.php and try logins (in case you are in a reauth loop / cookie problem)
• check in wp_sites and wp_blogs tables if the domains and/or paths are correct

[sebastiaandegeus]

Our situation is that we have a multidomain multisite with domain mapping plugin.

I don't think we can get it working for now... Multidomain multisite is still way too buggy to start moving around the structure of wordpress itself.

[francescolaffi]

well i'm using it with https://wordpress.org/plugins/wordpress-mu-domain-mapping/ and it works although it needs some configuration, but i didn't have login problems (both with remote logins and logins on main site)
I had some issues with plugin urls since the domain mapping plugin use a deprecated constant to rewrite those urls, you can workaround it with define('PLUGINDIR', 'app/plugins'); hoping other plugins dont use it in other ways, or unhook that specific filter if you provide a correct WP_CONTENT_URL for all sites. Remember that on multisite wp ignores WP_HOME and WP_SITEURL constants.

There are some quirks with bedrock+multisite+mapping but its not broken, some documentation could help, @swalkinshaw how about enabling the wiki for this repo?

[swalkinshaw]

@francescolaffi wow didn't even realize it wasn't. Enabled now.

[sebastiaandegeus]

@francescolaffi That sounds interesting. Do you have an example configuration / setup somewhere?

On the main website we keep getting errors about cookies being blocked on the browser. But it's possible to login in a subsite in the network. So that's weird.

[francescolaffi]

I dont have a public repo for that project but I'll make a wiki page with a working config

Cookies blocked probably means it cant set or verify the test cookie, I guess its a misconfiguration of the cookie domain.

Anyway you should check with browser tools or curl if the domain for wp cookies is correct by http standards: try maindomain.tld/wp-login.php it should be something like .maindomain.tld if it is a subdomain install

I had a similar problem when I misconfigured DOMAIN_CURRENT_SITE inserting the scheme (should be bare domain)

[danielck]

For reference, in case this helps someone, these are the steps I took to get multisite working with Bedrock correctly:

1. Add WP_ALLOW_MULTISITE to config/application.php
2. Start the multisite install process in the admin normally.
3. Copy the generated .htaccess rules into your htaccess file
4. Add the required multisite constants to development.php, staging.php or production.php, taking care to remove references to subdirectories. At least DOMAIN_CURRENT_SITE should probably be defined as an environment variable in your .env file.
5. Check the home and siteurl values in wp_options and wp_sitemeta, removing any reference to subdirectories (yoursite.com/wp should be changed to yoursite.com). This is because the .htaccess rewrite rules already take care of hiding the wp/ part.
6. Login to your site at yoursite.com/wp-login.php (NOT yoursite.com/wp/wp-login.php).
7. Enjoy!

[frebro]

The steps above work nicely. Thanks @danielck !

[danielck]

Glad to hear it! You're welcome.

On 21 Oct 2014, at 15:22, Fredrik Broman notifications@github.com wrote:

The steps above work nicely. Thanks @danielck !

—
Reply to this email directly or view it on GitHub.

[etcook]

Why would you put the multisite constants in three different environment files rather than application.php?

[danielck]

Question of workflow. You can't put everything at once in the config, before you've run network setup. And I assume you'd want to test first in development before starting the process in staging or production. But it all depends on how you do deployments (we don't use Capistrano) and in the end you can just move everything into application.php anyway.

Daniel

On 21 Oct 2014, at 21:45, E.T.Cook notifications@github.com wrote:

Why would you put the multisite constants in three different environment files rather than application.php?

—
Reply to this email directly or view it on GitHub.

[alexleonard]

@etcook Presumably you could just set this in application.php

define('DOMAIN_CURRENT_SITE', getenv('DOMAIN_CURRENT_SITE'));

And then make sure to add the new line to your .env

[alexleonard]

@francescolaffi Did you ever get a chance to share your working multi-site multidomain configuration tweaks? I'd be intrigued to see them as I'm about to try setting one up.

[etcook]

@alexleonard I'm not sure what you're referring to in your first post.

Re the second: I have zero issues with multi-site, multi-domain, and I rewrite away the wp directory.

I'm using the same htaccess as @francescolaffi posted above on Apache, and have a similar config for nginx working. Nothing fancy needs to be done.

[starise]

I'm trying to configure a bedrock multisite and the @danielck solution works for me. However i think there's an issue with bedrock autoloader, all the mu-plugins loaded in composer.json as mu-plugins that are located in subdirectories are loaded correctly but not listed in the admin page (roots/soil for example). Moreover i can't see anymore the asterisks next of the plugin name.

[robganly]

I'm creating a multisite implementation and was wondering if the above posts are generally referring to sub-directory or sub-domain mode? I'm going to use the domain mapping plugin eventually but want to get it working without this first.

[alexleonard]

@robganly I went with sub-domain mode. My first attempts with sub-folder mode didn't seem to work, but that said, I didn't spend too long on it. Domain mapping worked well. The setup is a little ungainly and moving from local -> staging -> production is a bit of a pain in the ass (you need to step by step work through database changes - I do wish WP just handled domain settings in config files - or at least had an option to).

@etcook Heh, I can't remember exactly - I think you'd asked a question about why was config stuff spread around various files.

[nathanielks]

I can confirm that the rewrite rules suggested in #58 (comment) work just fine, as evidenced by roots/trellis#116. After adding the necessary multisite constants, Bedrock works with aplomb.

[olivierhaustrate]

I'm encountering the same problem as described by @starise : the plugins' files are in the mu-plugins folder, but not listed in admin (plugin page).
I've updated the bedrock-autoloader.php based on the fix of @starise , but it's not solving my problem because I'm not using a multisites instal; I'm working on a subdomain (dev) for staging on the production server.
So the problem occurs because I have my wordpress install on a subdomain.
Did someone already found a way to solve that problem?

[zairl23]

How about nginx rewirte codes??

[swalkinshaw]

@zairl23 https://github.com/roots/bedrock-ansible/blob/master/roles/nginx/templates/wordpress_multisite_subdirectories.conf.j2