rfay's blog

Fixing a Broken Drupal 7 Registry


In Drupal 7 we have a very nice "registry" that registers what PHP classes should be loaded from what files.

Unfortunately you can get the system into a state where it can't bootstrap to a high enough level to rebuild the registry (normally done by clearing the cache). What do you do then?

I had this situation today due to an annoying Rules/Entity issue, and dereine pointed out that it had recently been an issue in the Views queue.

Since the solution given in the Views queue didn't work for me, I created a package that you can use to get out of this trouble, Registry Rebuild.

When would you need Registry Rebuild?

You might get something like:


If this happens when you're trying to run update.php, and happens when you're trying to clear your cache, well, you have some trouble. That's what Registry Rebuild is for.


Oops. I can't believe I said that.

Drupal has a long tradition of insisting that everybody's contribution is equal, that every piece of content is equal. We have to stop that.

It's nearly impossible to find the critical content on d.o and has been for a very long time. How do we fix this? Enlist the community.

Here are some broad brushstrokes:

Simpler Rebasing (avoiding unintentional merge commits)


Please just do this if you do nothing else:

git config --global branch.autosetuprebase always

About rebasing and pulling



  • Push when you need to.

That's it.

Reasons to rebase to keep your history clean


Handling the new .gitignore file in D7 and D8




This happens to me periodically, so I thought I'd write it down.

Situation: An existing site has had its theme hacked in place, or just has a stock theme deployed and I need a subtheme. But that means that I'm going to have to change the name of the theme, which can mean having to go back and do all the theme and block settings again. I really don't like manual work, so this time I tried to write down what has to be done to create a new theme with the old theme's settings and block settings.

I did this on a Drupal 6 site, but I believe the basics are the same for any Drupal version. Edit (26 May 2011): Drupal 7 block table changed its name and one field, so a recipe for it is at the bottom of the article.

Drupal Testbots are now running on the OSUOSL Supercell


You probably know that all Drupal core patches and commits get tested using the simpletest testing system, but you may not know how. Essentially, every time a patch is posted and placed in the "Needs Review" status on Drupal.org, and every time a commit is made, the information is sent off to qa.drupal.org, which then farms it out to testing working machines we call testbots.

Well, the testbots are quite compute-intensive, and although we tried for years we never really got enough decent, manageable machines from community contributions. Partly this is because the machines are really compute-intensive, and partly it's because they can be pretty tweaky and not everybody wants to learn how to manage them and deal with their occasional fits. Many community members had donated time on their machines, but in recent months we'd been using Amazon EC2 instances for the bulk of our testbots, and the bill to the Drupal Association was more than we'd like to pay, more than $500 many months.

Playing around with Git

Even if you've just arrived into the Gitworld, you've already noticed that things are really fast and flexible. Some people claim that the most important thing about the distributed nature of Git is that you can work on an airplane, but I claim that's totally bogus. The coolest thing about the distributed nature of Git is that you can fool around all you want, and try a million things, and even mess up your repo as much as you want... and still recover. Here's how, with a screencast at the bottom.

With CVS or Subversion or any number of other VCS's, when you commit or branch, you have the potential of causing yourself and others pain forever. And there's no way around it. You just have to do your best and hope it comes out OK. But with Git, you can try anything and rehearse it in advance, in a total no-consequence environment. Here are some suggestions of where to start.

Drupal Patching, Committing, and Squashing with Git


Ways to create patches


[edit A.txt]
git add .
git commit -m "Added A.txt"
[edit B.txt]
git add .
git commit -m "Added B.txt"


Pushing and Deleting Git Topic Branches (Screencast)

Creating topic branches (also called "feature branches") is easy in Git and
is one of the best things about Git. Sometimes we also want to get those pushed
from our local repo for various reasons:

  1. To make sure it's safe on another server (for backup).
  2. To let others review it.
  3. To let others build upon it.

Here we'll just be dealing with #1 and #2, and not talking about how to collaborate
on a shared branch. We'll be assuming that only the original author will push to it,
and that nobody else will be doing work based on that branch.

Review of Packt's Drupal 7 First Look

(Disclaimer: The book for review was provided gratis by the publisher.)

Drupal 7 First Look, by Mark Noble (Packt) should probably be named "What Drupal 6 Developers Need to Know about Drupal 7". It would kind of make sense then. If you need a book-length (252-page) introduction to what's changed in D7, this is a lot better than reading the horrendous D7 Module Upgrade Guide. However, I can't recommend it for any purpose other than that. It's not one of the leading books. It's not authoritative or particularly accurate, not well edited, and doesn't have clear scope.

Here's what I liked: The chapter on the Drupal 7 PDO Database Interface (DBTNG) is really quite good. I don't have enough depth in PDO myself to check it for accuracy, but it seemed to have a very solid tutorial approach, with a lot of detail. Quite nicely done.


Subscribe to RSS - rfay's blog
Drupal theme by Kiwi Themes.