Posted by korontari on Mon, Sep 16, 2019 - 8:16am

Hello,

I am running 3 small sites with similar functionality (designers portfolios) on the same server and under the same domain. Each site has its own subdomain. So they are adressed as sitename.mydomain.com, anothername.mydomain.com etc.

On my host server I have the following folder structure:

mydomain.com

- htdocs

-- sitename

-- anothername

-- othersubdomains

Each folder created in 'htdocs' automatically creates a subdomain with the same name as folders'. Right now I have a separate instance of a CMS installed in each of these folders to run each site. I wonder how should I configure multisite feature to run these site with one instance of Backdrop?

Should the Backdrop itself be installed in the root directory(i.e. htdocs)? Should I create symlinks in \sites directory pointing to subdomain directories? Should there be any extra server configuration done in .htaccess files? I would very much appreciate an advice from experienced users.

 

Accepted answer

In my server setup (I use Apache and virtual hosts) I have DocumentRoot  /var/www/backdrop1. Maybe you need to do something similar (e.g. for each site, point the server to Backdrop root, rather than the individual site directory). That way Backdrop can use its multisite feature to find the appropriate site when the (sub)domain is accessed (via /sites/sites.php).

Failing that, can you tell more about your server setup? Are you using Apache or Nginx? How does the automatic subdomain thing work?

Most helpful answers

Glad you got it working

Glad you got it working @korontari! Multisites are a very useful and underrated feature in my opinion.

Yes, 'settings.php' needs to be in each /sites/* folder to work (see the README.md in /sites for details).

To (try and) answer your questions:

  1. I have no experience with using a single, prefixed DB for multiple sites, so I can't really speak to that re. performance. But I believe separate databases for each site is better for security...
  2. You can either install all projects (modules, themes, layouts, etc.) in the root directories (e.g. /modules, /themes, etc.) and then just enable specific projects on specific sites (if you don't mind all of them showing up as options for each site); or you can install site-specific projects in the site-specific directories (e.g. /sites/[SITE]/modules) and they'll only show up as an option for that site. Also, if you have a project in the root directory available to all sites, but need a different version (e.g. patched, dev, etc.) for a specific site, you can install the different version in the site-specific directory and it'll override the root directory one.
  3. I'm not sure what you mean by the "core part of DB" (unless this is something related to a single, prefixed DB...) but I'd recommend backing up all DBs before doing any updates. I'd further recommend automating this by having a system that backs up all DBs and site code daily, as a further security measure.
  4. I'm not that familiar with symlinks to CMS installs to know about this, but I would imagine the security revolves around the file permissions (e.g. read/write) you have for Backdrop and its various files/folders. See https://backdropcms.org/file-permissions-and-ownership for details.
  5. As multisites aren't widely used (unfortunately), sometimes things go wrong as something was designed to work for a normal setup and not a multisite setup (e.g. I had a few issues with Drush because of this). Usually finding or opening a new issue will help get it sorted (I believe most of my multisite-related Drush issues have been fixed), but my point is to seek help as needed and don't give up. More people should use multisites, and the more that do, the better! I personally run 8 Backdrop sites currently, all as multisites from one Backdrop install. So hit me up anytime you need help :-)

If you are going to use

If you are going to use symlinks, they should go from your Backdrop root's sites directory to the outside directories, not from the outside directories in, but symlinks are not at all necessary.

The individual sites directories are for the individual site's configuration and any modules, themes, etc. that are not shared among the sites.

All shared code stays in the Backdrop root directory, i.e., the core, modules, themes, etc. directories.

/htdocs
  /backdrop
    /sites
     /a -> ../../site-a (or /full/path/to/site-a)
     /b -> ../../site-b (or /full/path/to/site-b)
  /site-a
  /site-b

(I might not have the relative link positioning exactly correct, but I think it is right.)

Your sites.php configuration, as you have posted it, looks correct.

For the Apache vhost files, create one vhost for each site and point them all to the Backdrop root directory (/htdocs/backdrop). Backdrop will do the rest.

Interesting question

Interesting question @korontari!

I'm a big fan of multisites, though I've never used them in quite the way you're suggesting.

My multisites are setup as follows:

/backdrop
  /sites
    /site1
    /site2
    /site3
  sites.php

(i.e. the default way suggested in /sites/README.md)

In your case, if your server is entirely dedicated to running Backdrop sites, then it sounds logical that you'd install Backdrop into /htdocs. If you have (or want) non-Backdrop sites on your server as well, then you could install Backdrop into its own directory in /htdocs.

For example:

/htdocs
  /core
  /files
  /layouts
  ...
  /sites
  /themes
  etc.

(Backdrop installed in /htdocs)

Or

/htdocs
  /backdrop
    /core
    /files
    /layouts
    ...
    /sites
    /themes
  /drupal
  /wordpress

(Backdrop installed in its own directory)

Once you've installed Backdrop how you want it, you can work out how to setup your individual sites. If whatever system you're using for automatically creating subdomains based on folders works for folders other than those directly inside /htdocs, then maybe you could configure it to apply instead to folders inside /sites. Then you can just use Backdrop multisites as normal and let whatever that other system is worry about the subdomain part. If that's not an option however, then symlinks sound like they could work. In that case, you'd have something like this:

/htdocs
  /backdrop
    /core
    /files
    /layouts
    ...
    /sites
      site1 -> ../../site1
      site2 -> ../../site2
      site3 -> ../../site3
    /themes
  /site1
  /site2
  /site3

As you can see, it looks like in this case you'd be better off having Backdrop installed in its own directory. That'll mean you'll also have a backdrop.mydomain.com subdomain setup automatically, but I think that's better than installing Backdrop in /htdocs and having core.mydomain.com, files.mydomain.com, layouts.mydomain.com, etc.

I'd be interested to hear how you go with this, especially if symlinks work in this case. I don't believe you'd need any additional configuration in .htaccess, but then this is all in theory, I haven't tried any of it myself...

Comments

Mon, Sep 16, 2019 - 11:25am by BWPanda (not verified)

Interesting question @korontari!

I'm a big fan of multisites, though I've never used them in quite the way you're suggesting.

My multisites are setup as follows:

/backdrop
  /sites
    /site1
    /site2
    /site3
  sites.php

(i.e. the default way suggested in /sites/README.md)

In your case, if your server is entirely dedicated to running Backdrop sites, then it sounds logical that you'd install Backdrop into /htdocs. If you have (or want) non-Backdrop sites on your server as well, then you could install Backdrop into its own directory in /htdocs.

For example:

/htdocs
  /core
  /files
  /layouts
  ...
  /sites
  /themes
  etc.

(Backdrop installed in /htdocs)

Or

/htdocs
  /backdrop
    /core
    /files
    /layouts
    ...
    /sites
    /themes
  /drupal
  /wordpress

(Backdrop installed in its own directory)

Once you've installed Backdrop how you want it, you can work out how to setup your individual sites. If whatever system you're using for automatically creating subdomains based on folders works for folders other than those directly inside /htdocs, then maybe you could configure it to apply instead to folders inside /sites. Then you can just use Backdrop multisites as normal and let whatever that other system is worry about the subdomain part. If that's not an option however, then symlinks sound like they could work. In that case, you'd have something like this:

/htdocs
  /backdrop
    /core
    /files
    /layouts
    ...
    /sites
      site1 -> ../../site1
      site2 -> ../../site2
      site3 -> ../../site3
    /themes
  /site1
  /site2
  /site3

As you can see, it looks like in this case you'd be better off having Backdrop installed in its own directory. That'll mean you'll also have a backdrop.mydomain.com subdomain setup automatically, but I think that's better than installing Backdrop in /htdocs and having core.mydomain.com, files.mydomain.com, layouts.mydomain.com, etc.

I'd be interested to hear how you go with this, especially if symlinks work in this case. I don't believe you'd need any additional configuration in .htaccess, but then this is all in theory, I haven't tried any of it myself...

Tue, Sep 17, 2019 - 3:17am by korontari

Thank you very much for your response @BWPanda! Very structured and comprehensive!

Here is what I have done so far:

1. I have installed fresh Backdrop in a dedicated directory in /htdocs.

2. I have created symlinks pointing from root directory to /sites directory. The links seem to work fine for the subdomain automatic creation - I have checked this by placing generic index.html in the target directory and it shows up when I open site in browser.

3. I have set up sites.php:

$sites['a.mydomain.com'] = 'a';
$sites['b.mydomain.com'] = 'b';

The folder structure looks like this:

/htdocs
  /backdrop
    /sites
     /a
     /b
  /a -> backdrop/sites/a
  /b -> backdrop/sites/b

4. I have also put default settings.php in each of the sites directory.

At this point I am stuck. I have read in Drupal 7 multisite guide that I should run install script from each of the sites domain. So I tried entering a.mydomain.com/install.php and simply a.mydomain.com in browser but recived '404 not found' and '403 forbidden' errors respectively. At the same time any file I put inside directories can be opened without issues (i.e. a.mydomain.com/index.html etc.). It seems to me there should be something with server settings but this is a subject where my knowledge is almost at zero level. I would appreciate any ideas on this.

 

 

 

 

Tue, Sep 17, 2019 - 3:23am by BWPanda (not verified)

In my server setup (I use Apache and virtual hosts) I have DocumentRoot  /var/www/backdrop1. Maybe you need to do something similar (e.g. for each site, point the server to Backdrop root, rather than the individual site directory). That way Backdrop can use its multisite feature to find the appropriate site when the (sub)domain is accessed (via /sites/sites.php).

Failing that, can you tell more about your server setup? Are you using Apache or Nginx? How does the automatic subdomain thing work?

oadaeh's picture

Tue, Sep 17, 2019 - 7:07am by oadaeh

If you are going to use symlinks, they should go from your Backdrop root's sites directory to the outside directories, not from the outside directories in, but symlinks are not at all necessary.

The individual sites directories are for the individual site's configuration and any modules, themes, etc. that are not shared among the sites.

All shared code stays in the Backdrop root directory, i.e., the core, modules, themes, etc. directories.

/htdocs
  /backdrop
    /sites
     /a -> ../../site-a (or /full/path/to/site-a)
     /b -> ../../site-b (or /full/path/to/site-b)
  /site-a
  /site-b

(I might not have the relative link positioning exactly correct, but I think it is right.)

Your sites.php configuration, as you have posted it, looks correct.

For the Apache vhost files, create one vhost for each site and point them all to the Backdrop root directory (/htdocs/backdrop). Backdrop will do the rest.

Wed, Sep 18, 2019 - 2:05am by korontari

I have finally made it work the way @BWPanda suggested! I have Apache server and virtual hosts.  I have put Backdrop files directly into the root /www folder so that I could access it just via domain name. Then I made symlinks for each subdomain that pointed to the root folder. So the folder structure looks like this:

/htdocs
  /a -> www
  /b -> www 
  /www
    /sites
     /a
       settings.php
     /b
       settings.php
     sites.php

I noticed that the default settings.php file should be placed in each site's folder to initiate installation, otherwise it just launches the core site.

After some experimenting I found that I can place backdrop folder anywhere on my virtual host and just make symlinks to it. So it looks like it is possible to run all the sites via a single backdrop instance no matter what folder configuration you have. Very cool!

I did have problems when installing Backdrop sites but the issue turned out to be not related to multisite configuration. But I think I would better share it here anyway:

For one of the domains I had a Cloud Flare SSL set. It secured only traffic that comes from CloudFlare to visitors. The origin to CF connection was via a simple http. On CF this is called 'Flexible' mode. With that mode I couldn't perform even a single Backdrop installation, getting multiple errors on the way. The solution was to install an SSL on the origin server and switch to 'Full' mode on CF. After that the installation process ran flawlessly.

I am very grateful to @BWPanda and @oadaeh for help and resposes! I am glad I invested some time in multisite feature and after playing a bit with it I found it to be very convenient.

I also have a few 'best-practice' questions regarding multisite configuration:

  1. From the point of maximum site speed performance what would be the best way to set up database(s): single DB for all sites with prefix for each site or one DB per site?
  2. If I want to install a theme or module that is available only to one site, should I do it only manually by placing it to the site's /module (or /theme) folder or are there any means to control it via admin UI?
  3. Before updating Backdrop core to a new version should I back up only the core part of DB or should I save all the DB(s)?
  4. Can there be any security issues if I keep Backdrop installation folder out of the root/domain folders while having symlinks from different sites pointing to it?
  5. Any other advice you may have for a newbie regarding multisite configuration?

Wed, Sep 18, 2019 - 2:30am by korontari

I have finally made it work the way @BWPanda suggested! I have Apache server and virtual hosts.  I have put Backdrop files directly into the root /www folder so that I could access it just via domain name. Then I made symlinks for each subdomain that point to the root folder. So the folder structure looks like this:

/htdocs
  /a -> www
  /b -> www 
  /www
    /sites
     /a
       settings.php
     /b
       settings.php
     sites.php

I noticed that the default settings.php file should be placed in each site's folder to initiate installation, otherwise it just launches the core site.

After some experimenting I found that I can place backdrop folder anywhere on my host and just make symlinks to it. So it looks like it is possible to run all the sites via a single backdrop instance no matter what folder configuration you have. Very cool!

I did have problems when installing Backdrop but the issue turned out to be not related to multisite configuration. But I think I would better share it here anyway:

So for one of the domains I had a Cloud Flare SSL set. It secures only traffic that comes from CloudFlare to visitors. The origin to CF connection was via a simple http. On CF this is called 'Flexible' mode. With that mode I couldn't perform even a single Backdrop installation, getting multiple errors on the way. The solution was to install an SSL to the origin server and switch to 'Full' mode on CF. After that the installation process ran flawlessly.

I am very grateful to @BWPanda and @oadaeh for help and resposes! I am glad I invested some time in multisite feature and after playing a bit with it I found it to be very convenient.

I have also got a few 'best-practice' questions regarding multisite configuration:

  1. From the point of maximum site speed performance what would be the best way to set up database(s): single DB for all sites with prefix for each site or one DB per site?
  2. If I want to install a theme or module that is available only to one site, should I do it only manually by placing it to the site's /module (or /theme) folder or are there any means to control it via admin UI?
  3. Before updating Backdrop core to a new version should I back up only the core part of DB or should I save all the DB(s)?
  4. Can there be any security issues if I keep Backdrop installation folder out of the root/domain folders while having symlinks from different sites pointing to it?
  5. Any other advice you may have for a newbie regarding multisite configuration?

Wed, Sep 18, 2019 - 3:08am by BWPanda (not verified)

Glad you got it working @korontari! Multisites are a very useful and underrated feature in my opinion.

Yes, 'settings.php' needs to be in each /sites/* folder to work (see the README.md in /sites for details).

To (try and) answer your questions:

  1. I have no experience with using a single, prefixed DB for multiple sites, so I can't really speak to that re. performance. But I believe separate databases for each site is better for security...
  2. You can either install all projects (modules, themes, layouts, etc.) in the root directories (e.g. /modules, /themes, etc.) and then just enable specific projects on specific sites (if you don't mind all of them showing up as options for each site); or you can install site-specific projects in the site-specific directories (e.g. /sites/[SITE]/modules) and they'll only show up as an option for that site. Also, if you have a project in the root directory available to all sites, but need a different version (e.g. patched, dev, etc.) for a specific site, you can install the different version in the site-specific directory and it'll override the root directory one.
  3. I'm not sure what you mean by the "core part of DB" (unless this is something related to a single, prefixed DB...) but I'd recommend backing up all DBs before doing any updates. I'd further recommend automating this by having a system that backs up all DBs and site code daily, as a further security measure.
  4. I'm not that familiar with symlinks to CMS installs to know about this, but I would imagine the security revolves around the file permissions (e.g. read/write) you have for Backdrop and its various files/folders. See https://backdropcms.org/file-permissions-and-ownership for details.
  5. As multisites aren't widely used (unfortunately), sometimes things go wrong as something was designed to work for a normal setup and not a multisite setup (e.g. I had a few issues with Drush because of this). Usually finding or opening a new issue will help get it sorted (I believe most of my multisite-related Drush issues have been fixed), but my point is to seek help as needed and don't give up. More people should use multisites, and the more that do, the better! I personally run 8 Backdrop sites currently, all as multisites from one Backdrop install. So hit me up anytime you need help :-)

Fri, Sep 20, 2019 - 1:03am by korontari

Oh, I have just realized that you don't have to run root installation in order to use multisite feature. For some reason I thought that common settings are store in 'root' DB while individual data is kept in each site's DB. Now I understand that my #3 question doesn't make sense. :)

@BWPanda, thank you very much for your help! I will keep you in mind and contact if I have more questions regarding multisite usage.