It would be nice if there was a global variable accessible so that modules could know they are running in Aegir.
For example: if you want to use boost in your website, you should use the provision_boost submodule in order to configure the rewrite rules in the vhost declaration. If you're not using that submodule, you have to always put the rewrite rules in your .htaccess (globally for the platform).
Either way, you will want the boost module to hide some configuration options from the UI, since they cannot be applied. So if the module had a global variable to check, i.e. if (variable_get('aegir_managed_site', FALSE))
, it could avoid confusing the user as to why once the settings have been changed, boost complains that the htaccess is not up to date.
Suggested implementation: put a conf variable in the settings.php template.
There are surely other cases where it may be useful for the module to know that it is managed by Aegir.
If you agree with the general idea, I can provide a patch.
Thanks,
matt (bgm on freenode)
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedI've no problem with this idea.
A few thoughts:
1) Needs to go into the settings.php template as a $conf
2) Needs to go into each of the provision/drupal/install_$.inc as variable_set's
3) possibly the deploy.inc's too? not sure.
4) Should probable be *unset* when we do a backup of a site. That way if you take the tarball to a non-aegir-managed site, it should not be set to TRUE there.
5) How would we go about setting this for all existing sites? We don't set this stuff in Verify (maybe we should). We only set them on install. We could do a hook_update to get all available sites, but we need to bootstrap each one and edit their database, and we don't store the database creds for each site in the db. So it might have to be a `drush @site vset aegir_managed_site, TRUE` but that's ugly and i don't want to execute drush from a hook_update.. ideas?
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedMaybe we can just list it in version-specific release notes in the UPGRADE.txt for the next release. 'if you wish to make use of this variable for previous sites, you will need to run this vset command. Here is a handy shell script to loop over existing sites and set this variable.' Cheating, but might be easier :)
Comment #3
anarcat CreditAttribution: anarcat commentedIf we set it in verify and deploy, eventually all sites will have the variable, I wouldn't force it down.
Comment #4
anarcat CreditAttribution: anarcat commentedWe should probably kick this in 1.0's API before release... marking for next release.
Comment #5
anarcat CreditAttribution: anarcat commentedthis is now done - there is now a $conf['aegir_api'] setting set directly in the settings.php that is set t the major version (1 for 1.x).
Comment #6
omega8cc CreditAttribution: omega8cc commentedThis looks wrong because in the Nginx based install it results with
$conf['aegir_api'] = 0;
So maybe instead of:
$conf['aegir_api'] = <?php print $this->cloaked ? $this->api_version : 0 ?>;
It could be:
$conf['aegir_api'] = <?php print $this->api_version ? $this->api_version : 0 ?>;
Comment #7
anarcat CreditAttribution: anarcat commentedThe problem with this approach is that it will *always* set that variable... Maybe we need a secondary variable to be set there?
Comment #8
Steven Jones CreditAttribution: Steven Jones commentedIf we're just trying to detect when we're doing a backup, then we can just see if
$backup_file = drush_get_option('backup_file');
is empty and react accordingly?Comment #9
anarcat CreditAttribution: anarcat commentedBrilliant. Let's do it. Steven, do I let you do the honors? :)
Comment #10
Steven Jones CreditAttribution: Steven Jones commentedTested my approach and seemed to be working correctly on backup and clone.
Pushed this fix in commit:386bb0a.
Comment #11
anarcat CreditAttribution: anarcat commentedTwo quick comments on that patch, mostly cosmetic:
1. please keep whitespace separated from regular commits
2. in the ternary operator (?:) there is a double-negation, might as well remove the negation and reverse the second part
3. i'm not sure why we don't just pass the backup file itself to the backend and use it as a truth value ...
But if this works, that's fine with me.