I downloaded Drupal Commons, and successfully added it as a platform in via hostmaster. Great!

However, when I try to provision a site in the commons platform, several fatal errors come up during module initialization. Frown!

In my case, this worked out OK, because I can still use the platform's install.php to manually install a new commons site.
However, it made me think: why does manual install work OK, even with hook_requirements errors, but provisioning fails?

Is there a flag to throw at the provision commands that will allow hook_requirements() runtime errors to be ignored?

I believe these are the relevant lines from debug output:

The getID3() module cannot find the getID3 library used to read and write ID3 tags. The site administrator will need to verify that it is installed and then update the settings. [31.42 sec, 6.91 MB] [error]
An error occurred at function : drush_provision_drupal_provision_install_backend [31.42 sec, 6.91 MB] [error]

and

Running profile specific task : profile [31.42 sec, 6.9 MB] [notice]
WD imagecache: non-existant action canvasactions_definecanvas [31.42 sec, 6.9 MB] [notice]
WD imagecache: non-existant action canvasactions_definecanvas [31.42 sec, 6.9 MB] [notice]
WD features: Rebuilding commons_core / content. [31.42 sec, 6.9 MB] [notice]
WD features: Rebuild completed for commons_core / content. [31.42 sec, 6.9 MB] [notice]
WD features: Rebuilding commons_core / fieldgroup. [31.42 sec, 6.9 MB] [notice]
WD features: Rebuild completed for commons_core / fieldgroup. [31.42 sec, 6.9 MB] [notice]
WD commons: Welcome to Drupal Commons from Acquia! [31.42 sec, 6.9 MB] [notice]
WD actions: Action 'Publish comment' added. [31.42 sec, 6.9 MB] [notice]
WD actions: Action 'Unpublish comment' added. [31.42 sec, 6.9 MB] [notice]
WD actions: Action 'Publish post' added. [31.42 sec, 6.9 MB] [notice]
WD actions: Action 'Unpublish post' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Make post sticky' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Make post unsticky' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Promote post to front page' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Remove post from front page' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Save post' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Block current user' added. [31.42 sec, 6.91 MB] [notice]
WD actions: Action 'Ban IP address of current user' added. [31.42 sec, 6.91 MB] [notice]
WD rules: An error occured during rule evaluation. It follows the evaluation log: 0 ms "User account details have been updated" has been invoked. [error]
0.128 ms Executing the rule "Heartbeat: when user edits a profile, log user activity" on rule set "User account details have been updated"
1.004 ms Action execution: "Logs user activity for single users"
1.09 ms Unable to find "action" of name "heartbeat_rules_default_action" with the label "Logs user activity for single users". Perhaps the according module has been deactivated.
1.149 ms Evaluation of "User account details have been updated" has been finished.

This is filed as a support request because I have not researched enough to figure out if this is an actual bug.

Comments

skwashd’s picture

Issue tags: +Drupal Commons

The fix for the ID3() library problem is to follow the steps below. The commands should be run as the aegir user and assume that Drupal Commons is installed in /var/aegir/platforms/drupal_commons-1.1

$ cd ~/platforms/drupal_commons-1.1
$ mkdir sites/all/libraries
$ ln -s /var/aegir/platforms/drupal_commons-1.1/profiles/drupal_commons/libraries/getid3/ /var/aegir/platforms/drupal_commons-1.1/sites/all/libraries/
skwashd’s picture

I have spent some more time digging through the installation profile. The setting of the path to the ID3 library occurs too late and this causes the install to fail on aegir. I have opened an issue ( #937864: getID3 chokes when being installed via Aegir ) against Commons with a patch that solves the problem. Testing welcome.

skwashd’s picture

deleted - commented on wrong issue

aaronbauman’s picture

Thanks for looking at this.
Does the patch also address to Commons also address the actions error described in the OP?

skwashd’s picture

From what I have seen the actions error isn't fatal. I have no idea what wider impact that may have.

Anonymous’s picture

So.

Is this our problem to fix or not?

So far there has not been such a case. If the profile can't be automated, we can't help that.

I'd like to close this if we can't do anything about it.

omega8cc’s picture

Drupal Commons works with Aegir. The fix was really simple. Just a symlink. Or you can use skwashd's method.

It depends, but for example I spent a few hours to debug Open Scholar to get it to work with Aegir and my changes and suggestions has been introduced (at least partially).

Fixing different distros for Aegir is my personal hobby, but I agree it should be distros Authors job if they wish to be compatible with Aegir.

skwashd’s picture

@omega8cc the symlink is a work around, not a fix. This still needs to be fixed - either in Drupal Commons or getID3.

@mig5 I would close this - DUPE #937864: getID3 chokes when being installed via Aegir

Anonymous’s picture

Status: Active » Closed (duplicate)