At DesignHammer we frequently use Install Profiles for migration projects. An install profile makes it easy for developers to work on migration code, site builders to add and configure modules while exporting the settings to Features, and themers to work on the Drupal 7 site theme – all at the same time, without getting in each other's way.
For example, in working on migration of content, it is sometimes quite useful to tear down the site, rebuild it, and re-run the migration scripts:
drush @mysitealias.local site-install my_profile -y
You are about to DROP all tables in your 'mysite' database. Do you want to continue? (y/n): y
Starting Drupal installation. This takes a few seconds ...
Installation complete. User name: admin User password: topsecret
drush mi --all
I don't want that to interfere with other people's work; that's why having a site that can be quickly torn down and rebuilt from an install profile and Features is quite useful.
Eventually, that usefulness runs its course. The migration scripts are completed, the site builders have added most modules and configured content types, the theme is mostly done. At this point, we need to do some more in depth testing, and edit content or create new content before deployment. So, we stop using the install profile and the site build/rebuild process.
Depending on the client, it may be fine to leave the modules and themes residing in
/profiles/my_profile/. In other cases, it might be desirable to adopt a more traditional Drupal site structure and place the modules and themes in
However, you can't just move the modules and themes to a different directory, because Drupal won't know where they've gone to. You could disable, uninstall, and re-install each and every module and theme but that would be quite tedious. Instead you can do this in a couple minutes with some SQL queries. It's a good idea to run this in your local development environment before trying it out on the development site that you are collaborating with others on.
The first step is to move the modules and themes. Make sure you double check the paths to match your desired configuration (for example, you may not care about separating modules into custom and contrib directories):
(Note: other developers may have topic branches open that branched off
develop before you relocated everything to
sites/all/modules. If you are tracking the entire codebase in git, these developers will need to checkout their topic branch and run
git rebase develop, assuming that you committed module and theme relocation work to
Next step is to tell Drupal where to find the modules and themes by executing these SQL queries, again taking care to check that the directories match the
mv operations you just performaed:
Make sure that you update your site-specific drushrc.php, if it exists, to reflect the new location for downloading modules. with drush.
For good measure, run
drush cc all.
Now you can visit your site, and it should be working fine. "Admin > Reports > Status" will still show the name of your install profile (which is correct - that is the initial profile used to build the site), but otherwise, you've moved away from the Install Profile and can place modules and themes in
sites/all/ without any issues.