When you put a Drupal site in maintenance mode, non-administrators see the standard maintenance mode page (assuming you clear caches after doing so). If you examine the response, you will see that it is sent back with a HTTP status code of 503, which from RFC 2616 is:
503 Service Unavailable
The server is currently unable to handle the request due to a ...
You can change the settings for the access to the database that are contained in the settings.php file used by your Drupal site to something similar to the following one (replace the values between brackets with the correct values for your site):
$databases['default']['default'] = array(
'driver' => '[Your database engine]',
'database' => '[Your ...
Sharing users and content between different domains is what the Domain Access module is for. Essentially, it allows you to run multiple Drupal sites out of the same database, and share content.
When you install, enable, and configure the module, a new tabs shows up on the node edit page which allows you to target a node for particular domains. It also ...
You have a few questions there, so I'll hit them individually:
How serious is deprecation in 8.x and removal plan of multi-site in
drupal 9? the topic is in category of plan for two years.
It's hard to say. Controversial topics like that can go in circles for years in the open source community. As you can see, that topic started over three years ago, ...
In a multisite setup anything in sites/all is shared.
This means sites/all/modules, sites/all/themes, sites/all/libraries are all shared.
In addition to that, if you have things that are specific to a subsite, for example, a sub-theme, or a module or library, you can add them in sites/subsite_name/modules, sites/subsite_name/themes, sites/subsite_name/...
Drush has the ability to interact with each site within a multi-site installation via the @sites argument. Anytime you are within the directory structure of your platform, the drush @sites command will target all sites rather than a single/no site. In this way, any drush task can be accomplished across all sites.
Some concrete examples:
Disable the ...
Take a look at Aegir:
It's probably a bit more than what you are looking for, since it manages your web server vhosts (apache or nginx), which means that it kind of takes over part of the system configuration. It also works much better on Debian (with Debian packages, installation/upgrades ...
I use the Themekey module. This allows me to give each area a distinct look without even touching any code. It also integrates with the Print, Revisioning, Organic Groups, and other major modules out-of-the-box.
Some of the things this module enables you to do (from the module page):
a front-page / "splash" screen
The main problem that Drupal 7 has with nginx is that Drupal is designed for Apache, and so many modules assume that Apache is installed (and you will always have a little blue entry on your "Status Report" that tells you that you can't use Upload Progress because mod_php isn't installed — annoying).
That being said, thanks to perusio and others, many ...
In the settings.php file used for the site, you can specific a different prefix for each database table.
$databases['default']['default'] = array(
'driver' => 'mysql',
'database' => 'databasename',
'username' => 'username',
'password' => 'password',
'host' => 'localhost',
'prefix' => array(
'default' => ...
There is no single management utility (maybe some managed cloud solutions) which can easily manage your all Drupal instances, so you have to learn how to mix different tools together (e.g. Puppet + drush). Most of it can be done by drush.
Ansible is a flexible and extensible automation tool which definetly can help with multisite deployment.
When you say "core site", do you mean the site in sites/default? Is it an option to just delete the settings.php file at sites/default/settings.php?
If you'd like to manage your aliases in an alias file, create a file ~/.drush/mysite.aliases.drushrc.php:
$root = '/path/to/root';
$aliases['site1'] = array(
'root' => $root,
'uri' => 'site1.com',
Per table-sharing is a relict of the past, deprecated and will be removed in Drupal 9. With all the layers on top that dynamically create tables for fields, cache invalidation and so on, this is never going to work.
If you want to have a shared authentication system, then look into an actual single sign on projects.
These are some links to get ...
So, I just realized that updating disabled modules is possible through Drush provided that you've set the check box for Check for updates of disabled modules and themes in the settings of your Update manager manager module (at admin/reports/updates/settings).
Then it's a matter of issuing the command drush up modulename to update the module.
You can use drush for it. First, you have to get the list of all modules that you've, for it you use drush pm-list like this drush pm-list --no-core --pipe --type="module" you'll get a list of all modules (enabled, disabled and uninstalled).
After, when you get all list of your modules, you can use drush dl [modules - list] with this command drush gonna ...
If you want to do it this way then you have to symlink the folder to the root of the drupal install:
ln -s . site1
Then within sites.php use the following:
$sites = array(
"example.com.site1" => "site1",
Yes! But maybe no! Be careful!
If you run pm-updatecode on any code in a given Drupal site, it is necessary to run updatedb afterwards in order to make the database schema(s) match the current schema in code. So, while drush -l mysite1.com will in fact correctly run pm-updatecode followed by updatedb on mysite1, if you have any modules in sites/all/...
I think the key here is to limit the total number and size of your PHP scripts. You've already taken the first step by running them off a shared codebase. The next step is to make sure you're not duplicating modules or themes that are shared. For example, you should have sites/all/modules/views, not sites/site1.com/modules/views and sites/site2.com/modules/...
I run several multi-sites and nothing is being shared between them except core and the modules and themes below sites/all/. If more than this is shared (your question specifies "everything"), then you've not set up your multi-site right.
I've written a tutorial about setting up a multi-site here. I hope the instructions are clear enough to follow.
Unless you've done something custom to allow it, Google can't crawl your site in maintenance mode.
Because you need to be logged in to view, googlebot will see the designated maintenance page.
For additional guidelines from Google see the following links:
Webmaster Guidelines: https://support.google.com/webmasters/answer/35769?hl=en
SEO Guidelines (multi-...
Instead of applying the updates to each individual site by using @sites which never worked, I was able to achieve it by running the updates on one specific site. Here is the code that worked for me:
drush -l example.com pm-update
example.com being the name of my symlink. Side note: I did not have to create a drush alias for this to work.
After much research, I've found out the following:
Can Commerce Kickstart be added to a multi-site installation?
The answer is No.
As Clive pointed out, CK ships with patches to Drupal core, so it's definitely not unmodified. Additionally, CK will break if one tries to migrate an already existing, stand alone installation to be one of the sites in an ...
Technically, there shouldn't be. But even if I had enough server resources, I'd reconsider my approach. A few problems I can think about. Note that they are really small annoyances and there are workarounds. If each site of your network has to be a very serious site, and all you are expecting is less files on the server and ease of updates, I think it's a ...
You need to run updatedb on each site individually. Note that as soon as you update the shared code, any site that has not had updatedb run could show errors or otherwise fail to function. You should therefore take all of the sites offline prior to updating the code, and bring each site back online again after updatedb completes.
coleopterist is right.
Let's say you want mydomain.com and sub.mydomain.com to share the same codebase, you will have to put two folders in sites/ :
If you want modules and themes to be available to all domains defined in sites/, all you have to do is to put them in all/ :
Yes it is possible to setup a multiple sites in Drupal 7 using one database.
All though its not optimale. compared to the other option to run it in different databases.
Drupal multiple sites tutorial
Complete tutorial on setting up sites in Drupal 7
Hope it helps :)
Well, I found out something that is quite useful:
Instead of trying to import the color.less file in each 'basic' theme css file, I do it the other way around: I import all the basic theme css files in colors.less, like this:
Then I had to remove all the stylesheet ...
This worked for me:
drush @site1,@site2,@site3,@site4 cc all --concurrency=4
I'm not sure how concurrent it actually was; the last message about site1 came immediately after the first message for site2, and all other messages were printed sequentially. I did not measure to what extent each cc operation happened concurrently, or to what extent the system ...