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 ...
Installing sites in sub-directories is supported in Aegir 2+ without any such hacking. Just enable the "Site subdirectories" feature, under the 'experimental' group at admin/hosting/features.
That said, to answer your question, DB credentials are available via drush_get_context('site').
Yes there is: it's a two or three step process, but automatable.
Step 1) Create a Drush alias, or in Aegir terminology, 'context' for the site using drush provision-save (arguments)
Step 2) Install the site using drush @(site context name goes here) provision-install
Step 3) (optional but recommended) Verify the platform in the Aegir interface to have it ...
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-...
You can follow the example from the profiles/standard/standard.install file and use code like this inside your implementation of hook_install():
// Create a Home link in the main menu.
$item = array(
'link_title' => st('Home'),
'link_path' => '<front>',
'menu_name' => 'main-menu',
I would recommend that you avoid multisite, and clone the code into a separate codebase -- then copy the database. This is much easier to manage for simple use cases, and would entirely avoid your problem above, as you would only have one copy of each module present in your code base, so Drupal would not be able to load any of them twice.
I am not sure ...
Here is an issue on Drupal Groups: http://groups.drupal.org/node/96639.
Check if your system is Ubuntu (the installation script assumes that
Remove everything in /var/aegir and run the installation script again.
Run 'mysql_secure_installation' command and finish it successfully. Aegir
checks for security flaws during installation ...
Is this error displaying on the site's front-end? Or in your apache logs? And are you planning to run many more OpenAtrium instances?
If you're getting that error on the front-end, and aren't planning to run very many more OA installs, just up the memory_limit in php.ini, as it looks like you've actually got RAM to spare, and individual processes are ...
Sounds like you might be looking for the Domain Access module
The Domain Access project is a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database.
The cause of above error is that @sites is returning no sites.
Try drush sa @sites too, and see what it says.
Note, however, that @sites refers to all of the sites in a multisite install; it does not refer to all of the sites in your aliases.drushrc.php. If you rename your aliases file to foo.aliases.drushrc.php, then @foo will reference all of the ...
You can try drush archive-dump default,example.com,foo.com command to archive the DB and codebase. If it is not possibel through it, then you can create a shell script, which creates backup of the codebase and database.
If you edit edit /var/aegir/config/includes/global.inc, as mig5 is proposing, and the sites are running on remote servers (not on Aegir master), then you should additionally verify the remote servers in Aegir, in order to get the changes in /config synchronised on remote servers.
The whole server doesn't restart when a site is added, only Apache, and it's just a graceful restart, so no real downtime..
Also, if what you mean by 'subsite' is http://example.com/subsite1, /subsite2, /subsite3, Aegir doesn't support that at this stage. Subdomains will work fine, but not 'subfolder' sites. See http://community.aegirproject.org/faq#...
Aegir is a powerful tool to manage hosting environments, deploy new versions of your site, clone a live site to a testing environment... Stuff like that. I don't know which kind of users you're talking about, but I would only give access to experienced Drupal developers. If you want 'normal' end users of a site to be able to setup their own subsite, maybe ...
I figured out a work around, actually it is quite simple. First ssh in as root. Then switch users su - aegir. Now drush will work. then simply use the drush command with the @sitename, so for instance drush @sitename.com dl themename. now this downloads to sites/all/modules, if you want you can move it to sites/sitname/modules. Either way it's a pretty fast ...
The problem turned out to be the PHP version on the server. The Rest Server had a line of code that requires PHP 5.3.
There is an issue at https://drupal.org/node/2003396 and a patch at https://drupal.org/files/ServicesRESTServerFactory.inc_.patch
Installing the patch solved the problem without the need to upgrade the php version on the server
If you do not know whether maintenance mode is blocking "everything you want blocked" by 100% (!) -- but at the same time are very concerned about "whether someone like google might still access it".
... then maintenance mode might be a bad choice for blocking your development site in the first place.
Personally, I recommend ...
Here's the recommended way for Barracuda/Aegir by Omega8:
The recommended (and also more advanced) way to manage your Sites code
is to use Makefiles (and then Drush Make) to build your Platforms,
apply patches to contrib or custom modules etc, then using Profiler
module to create your custom Installation Profile and manage in your
Git repo just ...
You can use Domain access module.
The Domain Access project is a suite of modules that provide tools for
running a group of affiliated sites from one Drupal installation and a
single shared database. The module allows you to share users, content,
and configurations across a group of sites such as:
The 'Drush make option' field in the Aegir user interface (when creating a new platform based on a makefile) simply determines whether or not the --working-copy option is passed to Drush make.
The --working-copy option for Drush make "preserves VCS directories, like .git, for projects downloaded using such methods." (source: Drush.org)
Passing the --...
Disclaimer: I use Aegir 2.x and never use the Drupalgap but I use root base files.
Create a new platform in Aegir (don't mess with the current platform) and create a new site.
After that you must have something like: /var/aegir/platforms/platform_name/sites/new_site.com/
If you put your files in /var/aegir/platforms/platform_name/my_folder/my_script.js you ...
In general, you shouldn't use Drush for that. Instead, use a build process, and one of the steps in the build would be drush make.
There are a number of existing build systems that can be used to achieve what you're looking for, including (but not limited to):
Phing - https://www.phing.info/
Jenkins - https://jenkins-ci.org/
Grunt Drupal Tasks - https://...
Consider starting from a Base theme, such as Omega, Zen, Bootstrap, etc. Or build your own (custom) theme that you can use as a Base theme (that would be youru "core theme".
And then create Sub-themes (that would be what you named "their custom themes").
Note: the question about "Right way to start with a Bootstrap subtheme?" contains a lot of details to ...
This is a great question! I maintain both Aegir and Drush Make, but I'm not certain that I have a really good answer for you.
I think that you're suggestion in (1) is probably the best bet at
the moment. It has the virtue of already working, as you've
mentioned. The issue with accidentally merging these [branch]
attributes is still valid though. The ...