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

Anonymous’s picture

I'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?

Anonymous’s picture

Maybe 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 :)

anarcat’s picture

If we set it in verify and deploy, eventually all sites will have the variable, I wouldn't force it down.

anarcat’s picture

Priority: Normal » Critical

We should probably kick this in 1.0's API before release... marking for next release.

anarcat’s picture

Version: » 6.x-1.0-rc3
Status: Active » Fixed

this 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).

omega8cc’s picture

Status: Fixed » Needs work

This 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 ?>;

anarcat’s picture

The problem with this approach is that it will *always* set that variable... Maybe we need a secondary variable to be set there?

Steven Jones’s picture

If 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?

anarcat’s picture

Brilliant. Let's do it. Steven, do I let you do the honors? :)

Steven Jones’s picture

Status: Needs work » Fixed

Tested my approach and seemed to be working correctly on backup and clone.

Pushed this fix in commit:386bb0a.

anarcat’s picture

Two 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 386bb0a on 6.x-1.x, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by Steven Jones:
    Issue #1027358 by Steven Jones
    
    Change the method of detecting if we...
  • Commit 113d9c9 on debian, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x authored by Steven Jones, committed by anarcat:
    Issue #1027358 by Steven Jones
    
    Change the method of detecting if we...