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:
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 sites/all/modules and sites/all/themes.
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 develop.)
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.
Should become:
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.
Comments
I recently performed these
I recently performed these steps on a Drupal 6 site. Everything worked as outlined in the post with the exception of a few changes to the SQL queries. `registry` and `registry_file` are called `autoload_registry` and `autoload_registry_file` in Drupal 6. Likewise, `cache_path` and `cache_bootstrap` are not in Drupal 6.
Making only the above changes allowed me to migrate away from the profile we were using to a standard install in 'sites/all' using only the command line. Afterwards the site worked great, modules were listed and enabled correctly, etc.
I've updated the snippet above to reflect the changes for Drupal 6.
Your gists are not working
Your gists are not working mate.
Thanks for the heads up Alex.
Thanks for the heads up Alex. I've fixed them.
Thank you for the great blog
Thank you for the great blog post on moving from an install profile back to a vanilla install. Sometimes I go the other way too, creating an installation profile out of a site a built via `drush dl`. In either case, the registry will need to be rebuilt, as you showed. There is a Drush extension that will rebuild the registry for you; if you install it, you can skip the step of hand-updating your registry table via SQL, and just run `drush rr`.
See: http://drupal.org/project/registry_rebuild
Thanks for that reference
Thanks for that reference Greg! I'll use Registry Rebuild next time.
registry, registry_file,
registry, registry_file, cache_bootstrap and cache_path are not there in D6...
so ran the following code on D6.
UPDATE system SET filename = REPLACE(filename,'sites/all/modules/contrib','profiles/cb/modules/contrib');
-- Update custom modules location
UPDATE system SET filename = REPLACE(filename,'sites/all/modules/custom','profiles/cb/modules/custom');
-- Update themes location
UPDATE system SET filename = REPLACE(filename,'sites/all/themes','profiles/cb/themes');
-- Truncate cache
TRUNCATE cache;
but somehow the theme entry from system table vanishes. Any pointers?
Hi there,
Hi there,
You might try using drush to disable then re-enable your themes. That should work.
Kosta
Hi mate,
Hi mate,
Thanks for the reply, and sorry i forgot to thank you for the awesome tutorial ( it was so rude of me i kno).
Tried the drush thingy. Didn't work.
Here are few things i did.
1. MOVED ( not copy ) the theme files into profile folder, ran the SQL update command on system table successfully. Used drush to disable the themes. Met with error "There was no extensions that could be disabled". Even thought at this point of time the system table contains valid path to the theme in profile folder.
2. Copied the theme files into profile folder, run the SQL update command on system table successfully. Used drush to disable the themes successfully. Deleted the themes in sites/all/themes. Visited admin/build/themes and voila the themes that i moved disappeared from the listing. The entries in system table too vanished.
Unlike modules simply rewriting the path to theme folder in system table is not enough.
will keep you updated if i succeed. thanks Kosta Harlan for the awesome tutorial.
another thing i noticed is
another thing i noticed is that even though the modules works after moving them, they wont be listed in admin/build/modules/list
Neither could it be done through drush as its not able to find the modules.
So am trying to figure out a proper way to make drupal search for modules and themes in the profile directory. Will post it in here if i find one.
Add new comment