Aegir 2 is currently in its alpha cycle, and we hope to have 2.0 released by DrupalCon Portland. It'd be great to have provision_civicrm support track that.

I'll be working on this in tandem with #1097496: Support to install CiviCRM in a separate database.

Comments

ergonlogic’s picture

Status: Active » Needs work

It looks like provision_civicrm doesn't work on Aegir 2.x. I'd appreciate feedback from others who might have tested it, to confirm that this isn't just something odd about my local dev deployment. From what I can tell so far, drush_get_option('packages', array('modules' => NULL)) in _provision_civicrm_get_package_info() isn't finding any packages.

... actually, it looks like it's only finding 'packages' on the first of 5 calls to _provision_civicrm_get_package_info() calls during the building of a site.

ergonlogic’s picture

ergonlogic’s picture

Status: Needs work » Postponed (maintainer needs more info)

This was indeed an upstream bug. No other change was needed in provision_civicrm to install a site with CiviCRM.

I'm marking as postponed, since this'll need more testing to confirm all the other tasks work, before we close it.

ergonlogic’s picture

Status: Postponed (maintainer needs more info) » Needs work

In discussions with @bgm, we decided for the sake of backward compatibility and providing a smoother upgrade path, that we'd move almost all code into subdirectories:

  • v0/ for current code, and
  • v1/ (for re-factoring, new features, &c.)

We then selectively include the appropriate code in our drush_hook_init(). I'm working on getting tests to work for this.

ergonlogic’s picture

Also worth noting is that newer functionality (in /v1) will support CiviCRM >= 4.2. Among other reasons for this, is that we'll be calling the CiviCRM API rather than writing directly into the database when needed, in support of optional #1097496: Support to install CiviCRM in a separate database. Also, for some of these settings, we'll likely be moving to writing the various URL settings directly in civicrm.settings.php, so that they cannot be overridden in the UI.

Since we now have a more generic front-end module (http://drupal.org/project/hosting_civicrm),we're able to save the CiviCRM version into the site context (alias) directly, rather than looking it up in the platform's drushrc.php (though that may remain a good place for a sanity check) or from the DB. The latter was required to get the patch version number (4.3.x) So, I submitted a patch to CiviCRM core's build scripts to re-write the version in the various modules' .info files (https://github.com/civicrm/civicrm-core/pull/645). Once it's accepted into master/4.3, I'll backport it to the new community-supported 4.2 'long-term support' release (https://github.com/civicrm42).

ergonlogic’s picture

The provision_civicrm 6.x-2.x branch supports Aegir 2.x well. The only issue we're seeing is #2133493: Error: Cannot redeclare civicrm_drush_command().

bgm’s picture

Issue summary: View changes
Status: Needs work » Needs review

#2133493: Error: Cannot redeclare civicrm_drush_command() is mostly resolved. Tested install, very and migrate in Aegir 2.x, seemed OK.

bgm’s picture

Status: Needs review » Closed (fixed)

Closing issue, seems all OK.