Chris Moates authored Mar 07, 2014 and Christopher Gervais committed Mar 11, 2014

When the subdir module is enabled and subdirs are used, the template
that generates sites.php has a logic bug that causes it to unset()
aliases which are not subdir aliases. This patch checks each alias
before deciding whether to munge and unset it, thereby eliminating
the underlying bug.

Signed-off-by: Christopher Gervais <chris@ergonlogic.com>

Conflicts:
	debian/aegir2-provision.postinst

This reverts commit abc9ac9c.

This reverts commit ec247161.

Issue #2020089 by ergonlogic - Allow example.com and example.com/foo domains (improved to fix a few dangerous errors) plus comments.

Fix the check for parent site existence - we should look for drush alias file and not a vhost (which can be dummy subdir vhost).

Running the parent site re-verify more than once (which would happen when there are two or more aliases) via backend while updating subdir site configuration results with semi-disaster, since it writes parent site db credentials into subdir site config. Not nice. But when auto-running this re-verify via frontend with hosting-task, it results with total disaster - it destroys hostmaster database! The workaround is to use a counter in the aliases loop, to make sure that we run parent site re-verify to update its vhost and add include line for sites in subdirs, if they exist, only once. By the way, DigitalOcean backups s*cks!

Undefined offset: 1 Subdir.php:46
Undefined offset: 1 Subdir.php:46
Undefined variable: parent_site SubdirVhost.php:61
unlink(/var/aegir/config/server_master/nginx/vhost.d/): Is a directory FileSystem.php:122
Undefined variable: parent_site SubdirVhost.php:61

Issue #2157785 by helmo: Remove unused variables, these get written to the site's settings.php anyway.

sites need to be reverified to take effect.

we also take care of regenerating the .htaccess even though it's not
actually necessary. this is because core status will warn us if the file
is out of date

the rationale for upgrades is obvious: even if the next package will
restore the link, the upgrade may fail and then all sites go
down. even if it doesn't fail, sites go down for the duration of the
upgrade: bad. this affects 1.x to 2.x upgrades.

the rationale for remove is that we don't completely destroy the data,
so the sites are expected to remain.

we also cleanup after ourselves in special corner cases
(abort-install, disappear) as well.

this is to allow more flexibility during upgrades (and even installs,
actually). for example it allows the admin to change the location of
the aegir home to be (say) /srv/aegir instead of /var/aegir

see https://drupal.org/node/2118857

see https://drupal.org/node/2002114