a simple workaround for some cases of http://drupal.org/node/1170362
If you already know about this problem, just skip to the solution I used.
Drupal install profiles can save you a significant amount of time and effort for project setup and management – combined with the Aegir project you can easily reduce the amount of time involved in starting a new Drupal project to almost nothing.
Recently, I decided to try a variant of the base install profile I’ve set up for new Drupal projects. It was designed to be a one-off for a new project. Because some of the module stack was significantly different ( Panels based instead of Context based), I needed a different build and install script so that I wouldn’t be installing all sorts of things I didn’t need. After doing about a week of work on the new install profile, I decided I liked it so much that some other projects that were relatively recently started should be migrated to it so that I could leverage Aegir to keep my common modules up to date.
This presented two problems. The name of the install profile and was inappropriate (as I had named it to describe the specific project instead of the underlying module stack), and one of the project I was migrating had been originally installed on a different install profile that was based around Context, but was no longer using those modules.
Unfortunately, Aegir doesn’t allow you to do migrations between different install profiles – both platforms must offer the same install profile for the migration option to show up. This was a problem, since although I knew the projects were compatible in terms of installed modules, I couldn’t perform the migration.
After some research, I discovered that it was possible to set a parameter in the install profile’s info file that listed the “old name” of a profile:
old_short_name = foo
This would tell Aegir (and possible Drupal core and drush? I didn’t check) that it should treat the install profile as migrateable from the older install profile named on the line.
This worked well, I edited the info file, migrated the first project, edited it again and migrated the second project. Now both of my projects were on an appropriately named, appropriately set up install profile that accurately reflected the stack they used. I cleared the Drupal caches and went on working on the projects. The next time I went to the module configuration page, however, I received with the following error:
Notice: Undefined index: distribution_name in drupal_install_profile_distribution_name() (line 202 of ...\includes\install.inc)
It didn’t seem to actually cause any issues, but it was annoying and would probably scare the clients when they used the administration interface so it had to go.
Before going into the solution you should note that there are cases where this issues can a legitimate symptom of a larger problem, or can be solved by not deleting your install profile. For full details you should read the bug report thread. As always, you should also make a backup of your site before attempting this.
In this instance, I knew that there was no real problem because:
- I had written the install profiles myself and knew what was in them
- the install profiles were not designed to run after the project install – they contained only one-time setup code
- I knew the profiles were compatible since I had manually disabled all modules in the old platform that were not present in the new install platform, and ensured the site still worked.
Because of those criteria, I knew that it was simply a matter of Drupal expecting the wrong install profile name, and that if I could change the name, the problem would go away.
To do this, I needed to make two changes in the database:
In the system table, there is a listing for the install profile that was originally used when setting up the site. The filename filed will contain something like
profiles/myprofile/myprofile.profile. You should change this so that the path correctly reflects the profile you want Drupal to think you have installed, and make sure that the status field is set to 1:
UPDATE `system` SET `filename` = 'profiles/newprofile/newprofile.profile',
`status` = '1' WHERE `system`.`filename` = 'profiles/myprofile/myprofile.profile';
In the variable table, there is a row with the name install_profile. This row’s value must be set to the match the install profile you wish to have active as well. Unfortunately, a wrinkle presents itself at this time – the data in the variable table is serialized php data stored as a BLOB. If you’re using phpMyAdmin, you can make it easier to view this type of data (at least for Drupal projects where the decoded value might mean something) by configuring phpMyAdmin to show blobs – you can confirm if you need to change the value of the row by doing this. If you do need to change the row, you’ll need to have MySQL correctly encode the data. The format is a hex-econded serialized php string, (e.g.
s:4:"asdf"; where ‘s’ indicates a string, the number indicates the number of characters in the string).
So to update the value in the table you should run:
UPDATE `variable` SET `value` = HEX('s:10:"newprofile";') WHERE `variable`.`name` = 'install_profile';
Make sure you update the length of the string if it changes. You can test your serialized string online before committing it to the database.
And that’s it! Drupal is now set to your new install profile. Clear you Drupal caches and you should see the error go away!