Fails to recognise 'profile' on imported old sites
| Project: | Hosting |
| Version: | 6.x-0.4-alpha2 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
When importing a site that was set up originally on a codebase from before install profiles were used, such as 4.7 (even if the site has been later updated to a newer codebase), aegir (of course) doesn't recognise the install profile.
In general this doesn't matter - until the user needs to add an alias for the site (the site's node edit form can't be submitted without a valid install profile, but it can't be user edited), or the user wants to migrate the site to a newer codebase (aegir says no platforms are available to upgrade to if there is no stored profile value).
The workaround I have used is to manually edit the hosting_site table in the hostmaster table. The 'profile' field for the site in question was shown as '0'. I set it to the nid of (in this case) the acquia profile (as the site is now on an acquia codebase - setting it to the 'default' profile didn't work).
Possible solution ideas:
1. detect if the imported site's DB doesn't have install_profile variable set. Search for a .profile file and set the profile to that, or offer the user a choice.
2. make 'profile' not required on site nodes (but then how to select platforms to allow migration to?)
This will only affect importing of very long established sites.
#1
This reminds me of #534302: installation profile requires writable settings.php for one step further than expected/advised. Is this related to the install_profile variable in the site database (in the variables table) or is this only in the frontend database (the hosting_site table you mention)?
I'm not sure we support 4.7 at all, is this aegir importing 4.7 sites?
#2
This isn't about importing 4.7 sites, but importing sites that were once, in the dim mists of time, created on 4.7 and then have been upgraded (probably many times) since - mine were started on 4.7, but are now on acquia drupal (based on 6.10 codebase). I'm now importing them and plan to migrate to latest acquia codebase - but aegir can't do the migrate until i manually set the profile in the hostmaster DB.
One of my sites did have the install_profile variable (in the sites DB) set to 'default', the other wasn't set at all. but neither would work under Aegir until I set it to 'acquia' in the Aegir/Hostmaster DB.
#3
Thank you for your feedback, it clarifies the issue for me and makes it worthwhile to fix this: it's not just a problem with 4.7.
#4
No problem. Let me know if I can help with further information or any testing. I think the work you guys are doing is fantastic and would like to help in any way that I can, as I seek to learn and become more active in the community.
#5
it seems i have the same issue..
i imported my drupal 6.13 sites in aegir and set up another platform for acquia drupal 1.2.16...
when i go the the migrate task for one of the 6.13 sites the acquia platform doesn't show up. only the drupal 6.14 platform with the same installation profile called "default" is visible there.
any advise on this?
#6
this is because acquia doesn't ship with the default profile it seems.
this is by design.
module visibility is defined by the install profile.
if we don't know which install profile, we can't detect which modules are visible to the site when upgraded.
In each of those cases a variable_set in the site you want to MOVE TO A DIFFERENT INSTALL PROFILE (which is what you are doing) , and then re-verifying the platform will work.
#7
We tried changing the profile variable in the to-be-migrated site, and even adding an empty /profiles/default/default.profile file in the to-be-migrated site.
-- EDITED --
In the end, I had to change the hosting_site table. I edited the hosting_site table directly in phpmyadmin. I found the row that corresponded to the acquia-platform site node, and I changed the profile package ID - changed it to the profile ID that corresponded to 'default' in the packages table.
#8
as of drush 2.1, there is a variable set command.
you can use drush variable set install_profile $newprofile , before you import the site.