Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
http://drupalcode.org/project/provision.git/blob/refs/heads/6.x-2.x:/pla... checks both boxes on the install configure form. This enables the update module and there's no way to sidestep this behavior.
I strongly feel that both of those values should be set to FALSE, and then let installation profiles handle adding update module as a dependency + configuring it. This is a much cleaner way to handle it.
Setting to needs review, as I want feedback on this before I roll a patch.
Comment | File | Size | Author |
---|---|---|---|
#6 | provision-2266997-6-install_settings_alter.patch | 1.15 KB | helmo |
#5 | install_settings_alter.patch | 454 bytes | cweagans |
Comments
Comment #1
cweagansThis same behavior exists in 3.x for installation of both D7 and D8 as well.
Comment #2
ergonlogicSince we already know the versions of all the packages in the Aegir front-end, I'd like to optionally add update status checks there. That could show us which modules require updating at the platform level, rather than getting emails from each of the sites. I'd thought there was already a feature request for that, but I couldn't find one. So, I created #2267303: Track package update status.
That said, I agree. Ideally we'd check a Drush option, so we can easily override this. For 7.x-3.x, defaulting to 'false' makes sense. But for 6.x-2.x, I think we'd be better off keeping the current behaviour, while allowing overrides.
Comment #3
omega8cc CreditAttribution: omega8cc commentedTry to set this to FALSE and you will get failed install with error:
WD form: Illegal choice in update_status_module element.
Comment #4
cweagansMight be able to just do `'update_status_module' => array()`
In any case, I'm happy to roll a patch for this if you agree that the update module shouldn't be enabled when the site is first installed. The other solution is to just allow altering the entire array (http://drupalcode.org/project/provision.git/blob/refs/heads/6.x-2.x:/pla...) with a drush hook like we do with hook_provision_drupal_create_directories_alter().
I wrote a module for a client recently that handles fetching update data for packages on a platform. I'm currently working on cleaning it up and generalizing it, and it will be open sourced when I get to it.
Comment #5
cweagansHm, could have sworn I already uploaded this, but here's a patch to allow other drush commands to alter the settings array. This works very well in my environment.
In my case, setting `'update_status_module' => array()` works great.
This is against 2.x, but the same change can be applied to 3.x in both install_7.inc and install_8.inc.
Comment #6
helmo CreditAttribution: helmo commentedHere's an updated patch which includes an addition to provision.api.php to demonstrate this example.
Comment #8
helmo CreditAttribution: helmo commentedComment #11
Jon PughWould there be any reason not to backport this to 2.x? It still cleanly applies, and I'd love to start using this functionality now.
I'm dealing with custom install profiles that have required fields on this form, and I cannot install them with aegir.
Sadly, I can install it just fine with `drush site-install key:value`.
There is no way to make this work without this hook invocation.
Comment #12
Jon PughComment #13
helmo CreditAttribution: helmo commentedGO ahead, I see no problems with it.
Comment #14
Jon PughGreat thanks!
Pushed to 6.x-2.x