Aegir still sets the default install profile as 'default', Drupal 6's install profile. I suspect that at this point in time it's worth updating this to use Drupal 7's 'standard' install profile, and for the sake of doing it the Drupal way, letting people choose which profile they would like to use as the default.
There is already a variable available for this purpose (hosting_default_profile), just no interface to modify the value.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | default_profile-1980136-5.patch | 2.18 KB | deciphered |
| #4 | default_profile-1980136-4.patch | 2.26 KB | deciphered |
| #1 | default_profile-1980136-1.patch | 621 bytes | deciphered |
Comments
Comment #1
decipheredPatch attached to change the default to 'standard'.
Not sure where the best place to put the settings for to set this value is at this stage, so haven't attempted that side of things.
Comment #2
anarcat commentedWouldn't that fail to return 'default' as a default install profile if D7 is not installed?
From what I can see, this would just return 'null' in such a case...
Comment #3
decipheredYes, you're probably right.
I suppose the more important thing is to have the settings form so that it can be configured, and have some logic so that if the default install profile is removed it will fallback to 'default', which given Aegir is D6 will always exist.
Comment #4
decipheredOk, improved the patch:
- Added a settings option on the 'General hosting settings' form so the user can choose their own default.
- Kept the default as standard, with some additional logic, it already had logic to check the default value, so I re-ordered it, it will now check the variable value, defaulting to 'standard', followed by a normal check for 'standard', then a check for 'default' before falling back to the default value supplied to the function.
This means that the default will be 'default' if there are no other platforms other than Hostmaster, but once a D7 platform comes about it will default to 'standard', unless of course a user configures their own default install profile via the settings form.
Comment #5
decipheredDoh, left a tiny bit of unnecessary logic in, fixed.
P.S., Sorry about the lack of interdiffs, being naughty.
Comment #6
ergonlogicThis is a nice improvement. Thanks for working on it @Deciphered.
I think this check is redundant, since 'standard' is the default for the variable_get just above.
Comment #7
decipheredNah, it's not redundant, it works like this:
If the profile defined by the variable exists, or if a variable hasn't been defined manually, the standard profile exists:
if ($p = hosting_get_package(variable_get('hosting_default_profile', 'standard'))) {Else, if the standard profile exists:
elseif ($p = hosting_get_package('standard')) {Else, if the default profile exists:
elseif ($p = hosting_get_package('default')) {So while it does look like it's redundant, if someone had changed their preferred default profile to something else ('myprofile'), and then since deleted all platforms that that profile exists in, the first line would fail, therefore the second check for standard would be called to return standard as the default profile.
Comment #8
ergonlogicAh yes, I see.
Tested and committed in d98e929c3b7006
Comment #10
omega8cc commentedThis new feature destroyed ability to migrate sites between profiles with
old_short_name = fooComment #11
omega8cc commentedUh, wait, we are still debugging this and while reverting this patch initially helped, we are no longer sure it is the real/sole source of the problem with migrations between profiles we experience.
Comment #12
omega8cc commentedScratch that. It was because we have tried to map
uberdrupal->standardinold_short_namein the standard.info which is not going to work because of the map hardcoded already in Provision to provide D6->D7 upgrade path: