Changing your install profile’s distribution_name in Drupal 7

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.

The Problem

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.

The Solution

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!

Drupal project workflow and version control with git – now 90% less complicated!

Edit: Since this post was created, I’ve since changed my Drupal development workflow (again) and would no longer recommend this approach. Instead, we’re now using a versioned drush-make script and aegir. A new workflow post is coming, eventually.

The last workflow with Drupal and git I posted about was complicated. This is much simpler.

  1. Create a project directory and start a git repository: mkdir my_project && cd "$_" && git init
  2. Into this directory, check out the Drupal base as a submodule: git submodule add http://git.drupal.org/project/drupal.git drupal
  3. Once the submodule has finished loading, go into the submodule and check out the version of Drupal that you want to use. In my case, the most recent 7.x.: cd drupal && git checkout 7.9
  4. Install Drupal as normal. Point your webroot  (or however you’re accessing the site) at the Drupal directory within your project directory.
  5. Move the sites directory out of the drupal directory and into the parent directory. Create a symlink back into the drupal directory: mv sites .. && ln -s ../sites This will let you use git to manage the sites directory, while still letting Drupal think everything is normal. Additionally, it will make it easier to update the Drupal version using git.
  6. Modules and themes are installed by adding them as submodules to the sites directory now. I usually put all downloaded modules/themes in a directory called contrib and all custom modules in a directory called collab, but there is no need for you do to this if you don’t want to.
  7. (Adding a module) Let’s add, for example, the Git Deploy module to our site. git submodule add http://git.drupal.org/project/git_deploy.git sites/all/modules/contrib/git_deploy && pushd "$_" This will clone the submodule and put you in its directory, where you can choose which version to run by performing git tag then git checkout version_foo. Use popd when you’re done to return to the project root.
  8. Using the Drupal interface, install/activate the module normally.
  9. Repeat as needed.

I mentioned the git_deploy module above, since if you’re using this workflow that module is necessary for Drupal to be able to determine when modules need to be updated. Without it, you’d have to check every submodule manually with git.

To update a module, you simply cd into the directory, git fetch to update the module, then git checkout new_version. Don’t forget to update the database using update.php as normal for Drupal.

Updating Drupal core is not much more difficult. Simply remove the symlink, fetch and checkout the new version, re-add the sites symlink, and update the Drupal install as you normally would. I keep the following script in the project root directory to save me the two seconds it normally takes to do this:

#!/bin/bash

rm -rf ./drupal/sites
ln -s ../sites ./drupal/sites

That’s it! It’s pretty simple, and the majority of the usage once everything is set up is just adding submodules over and over as needed. It has the benefit of not storing any drupal code in your local repository (only submodule configuration information and custom code) and has the benefit of being easily extensible to storing your own custom modules in a different repository and adding them the same way. Other developers can easily re-create the installation by cloning your project repository recursively.

As always, suggestions for improvements are welcome.

Drupal project workflow and version control with git

Edit: Since this post was created, I’ve since changed my Drupal development workflow (again) and would no longer recommend this approach. Instead, we’re now using a versioned drush-make script and aegir. A new workflow post is coming, eventually.

Edit: Since making this post, I’ve dropped this workflow and moved to one where Drupal Core is a submodule – this avoids storing it in the local repository but requires some directory symlinks to work correctly. See the post: Drupal project workflow and version control with git – now 90% less complicated!

The side-project that has my most direct attention at the moment is a Drupal 7 site that will provide a forum for discussion, social interaction, and event planning for a gaming guild. Since I’m going to be learning and working with Drupal 7 for my job, I figured it would be useful to leverage the experience I’d be gaining for the benefit of one of my projects. Although in my opinion Drupal’s forum offerings have been lackluster in the past (I can’t speak to their current state yet since it’s been a few years since I last paid any serious attention to the state of Drupal’s Forum module), I feel like the more flexible platform Drupal provides will be a significant enough benefit that I should base the project on Drupal instead of trying to add features to software that is a forum at its core.

One of the first issues I encountered was setting up a version control system for the project. There were several challenges and conditions I was hoping to meet with the selection of the version control setup. Specifically, I was hoping to be able to pull updates from Drupal’s own repository (as they maintain a stable branch), I was hoping to avoid storing Drupal Core code in my own repository (since that would just be inflating the size of my project repository), I was hoping for the ability to include sub-repositories since the project might involve writing custom Drupal modules that really should be in their own separate areas as they’re small projects in their own right, and finally I wanted the system to be a DVCS because then my development machine would be a free repository backup.

I’ve used Mercurial in the past and have been pretty happy with, but the tool of choice for the Drupal development team seems to be git. After reading about several variations on workflows, I finally settled on one that seems good:

  1. Clone the Drupal Core into a new git repository.
    git clone --branch 7.x http://git.drupal.org/project/drupal.git MyProjectName

    This leaves us with the Drupal Core as the origin remote.

  2. Pick the tag you want to run, and check it out. If you want to run development, check out the appropriate version branch (such as 7.x) instead. Note that this will cause Drupal’s auto update system to complain that it doesn’t recognize your version. In my case, I want to run the most recent stable 7.x release, not the development head:
    git tag -l
    git checkout 7.8
  3. Rename the origin remote to upstreamor something similar. We’ll use this remote to pull in updates from the Drupal Core repository when an update is released so that we don’t have to worry about downloading and unpacking tarballs over our existing site.
    git remote rename origin upstream
  4. (Optional) Disable pushing to upstream. In general, without the correct permissions you’ll be unable to push to the Drupal branch you cloned. However, in the case that you actually were to have the permissions to make changes to Drupal, or if you just want your repository configuration to be as clean as possible, you should rename the branch you checked out so it does notshare a name with its tracking branch on upstream (by default, a branch will think it can push to any identically named branch on the associated remote). In this example:
    git branch -m 7.x drupal-7.x

    Now, if you run git remote show upstream you’ll notice that the local branch no longer has an entry for ‘git push’.

  5. Create a new branch master and switch to it
    git checkout -b master

    or

    git branch master
    git checkout master
  6. (Optional) Set up a new origin remote if you have a remote repository you usually push to. In my situation, I’m using a gitolite repository, but the instructions for something like github should be similar. First we want to push our local repository. This should only be done into an empty remote repository. Optionally, also push tags to the remote repository – although be aware this will copy all of the Drupal project tags as well, so you may wish to forgo this part.
    git push --all theRemoteRepoString
    git push --tags theRemoteRepoString

    Then we want to set up origin and tracking:

    git remote add --track master origin theRemoteRepoString

Caveats

  • This method, while useful, will result in (relatively) large repositories, since you’re also mirroring the Drupal development repository. If you want to avoid this, there are other options, such as maintaining your own “drupal” branch, and extracting the packaged Drupal updates into it. This might be useful in a situation where the size is of a concern, or you’re maintaining multiple installations of the project and can justify the effort needed to maintain the branch yourself, since it loses the ability to simply update by doing git pull on the upstream branch.
  • It would be ideal if there were a way to make this work without re-storing the Drupal files in the local repository since they’re managed by a different repository. While that would technically be more correct, I have no idea how you would accomplish that.
  • Even if you push with the –mirror option in step 6, other developers working on the project will not get the upstream remotes that you’ve configured. This might not be an issue, as you may only want to have one developer responsible for updating things from upstream, but if you do, you’ll either need to copy (not clone, copy) the local repository set up, or have each developer configure the upstream and the upstream tracking branch. There could potentially be a solution that involves git hooks, but I don’t know what it is. That said, the branch containing drupal itself will track from that branch on your own server, so when a developer pulls from upstream and commits, other developers will still get those changes from your server.
  • This workflow is good, but not ideal in my opinion. If you know a better workflow, tell me!

Misleading “Mobile Device Management” Error on Android

Here’s a short record of how to fix a problem I recently encountered, since I couldn’t find any other resources about it.

I have a personal Google Apps account, which syncs to my phone. Yesterday, I started receiving the error message:
Google sign-in your domain requires mobile device management. Please install the Google Apps Device Policy application to enforce security policies

This was confusing since research quickly showed that there was no way I could have enabled that feature – it isn’t available on personal Google Apps accounts.

What actually was the issue was that in the control panel for the Apps account, under the Settings -> Mobile section, the “Enable Google Sync” box had somehow come unchecked. Re-enabling it fixed the problem!

Hopefully that information will be useful for anyone who might have this problem in the future.

Web Development on OSX

My personal development machine is a Macbook Pro. I’m not generally a believer in the supremacy of Apple products, but after my last laptop almost literally fell apart, I was looking for something with a backlit keyboard, a good screen, and very good construction. The fact that it ended up being easier to make it work with the setup at the university for my research advisor was a bonus, and I’ve learned to love the trackpad gestures.

But ooh, boy, does it stink for web development. Outdated versions of apache, php, and python. Three competing package managers – one of which want me to compile everything (sorry, I’d run Gentoo if I wanted that), one of which is incredibly invasive should anything go wrong, and one of which is dkpg reimplemented poorly. Not to mention that the moment I started configuring apache to my needs I started losing the ability to suspend my machine (this one I suspect has something to do with the connection between the installed version of apache and the Web Sharing feature in OS X).

So when I decided to upgrade to Lion (Hey, I was reinstalling anyway, right?) there was no way I was going to touch the included server stuff. Of course, my day job has recently involved setting up servers. It’s actually involved too much setting up servers, but that’s nobody’s fault. Because of this newfound familiarity, I decided my best course of action would be to install Ubuntu Server JeOS in VMWare and run my development stack there. If it messes up, it’s not a significant problem, as I can just reinstall it or roll it back to an earlier snapshot.

I initially tried installing the ubuntu open-vm-tools but I found that with my version of VMWare Fusion at least, the open-vm-tools package didn’t allow the folder sharing to work. I didn’t spend too much time troubleshooting as simply installing the tools by hand worked.

One downside is that VMWare Fusion 4 appears to have dropped the headless VM option that was present in earlier versions of the software, which is unfortunate since it would be more convenient ssh in than to be stuck using the fixed width console that the VM presents.

Still, despite some of the issue, it seems like this might be a more viable setup for doing any sort of significant web development on OSX.

flipbit init

After many false starts, I’ve finally settled on a domain so that I can start assembling my ideas and general brain-noise into a form that could potentially be useful for other people, but will more likely be useful for me just so it’ll stop rattling around inside my head. Hopefully I’ll be able to use this domain to talk about the tools, ideas, projects, and maybe even about my research.