rfay's blog

Fixing a Broken Drupal 7 Registry

Submitted by rfay on

Topics: 

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:

PHP Fatal error:  Class 'EntityAPIControllerExportable' not found in ...sites/all/modules/rules/includes/rules.core.inc on line 11

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.

Drupal.org is a cesspool of undifferentiated **** (oops... content, that is)

Submitted by rfay on

Topics: 

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)

Submitted by rfay on

Topics: 

Executive summary: Set up to automatically use a git pull --rebase

Please just do this if you do nothing else:

git config --global pull.rebase true

About rebasing and pulling

Edit 2021-06-17: Updated the suggested command from the old git config --global branch.autosetuprebase always to the current (from a long time) git config --global pull.rebase true

I've written a couple of articles on rebasing and why to do it, but it does seem that the approaches can be too complex for some workflows. So I'd like to propose a simpler rebase approach and reiterate why rebasing is important in a number of situations.

Here's a simple way to avoid evil merge commits but not do the fancier topic branch approaches:

  • Go ahead and work on the branch you commit on (say 7.x-1.x)
  • Make sure that when you pull you do it with git pull --rebase
  • Push when you need to.

That's it.

Handling the new .gitignore file in D7 and D8

Submitted by rfay on

Topics: 

Drupal 7 and Drupal 8 recently added a default (and sensible) .gitignore file to the standard repository, and while this solves some problems, it has also caused some confusion. (issue)

Here's a link to the actual new .gitignore. Essentially, it excludes the sites/default/files and sites/default/settings.php files from git source control.

Changing a theme name (or adding a subtheme) without losing block and theme settings

Submitted by rfay on

Topics: 

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

Submitted by rfay on

Topics: 

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

Submitted by rfay on

Topics: 

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

Submitted by rfay on

Topics: 

Back in the bad old days (like 2 weeks ago) there was exactly one way to create patches and exactly one way to apply them. Now we have so many formats and so many ways to work it can be mind boggling. As a community, we're going to have to come to a consensus on which of these many options we prefer. I'm going to take a quick look at the options and how to work among them when necessary.

Ways to create patches

My preference when making changes is always to commit my changes whether or not the commits will be exposed later. That lets me keep track of what I'm doing, and make commit comments about my work. So in each if these cases we'll start with a feature branch based on origin/7.x-1.x with:

# Create a feature branch by branching from 7.x-1.x
git checkout -b my_feature_99999 origin/7.x-1.x
[edit A.txt]
git add .
git commit -m "Added A.txt"
[edit B.txt]
git add .
git commit -m "Added B.txt"

First, I may want to know what commits and changes I'm going to be including in this patch.

Pushing and Deleting Git Topic Branches (Screencast)

Submitted by rfay on

Topics: 

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

Submitted by rfay on

Topics: 

(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.

Pages

Subscribe to RSS - rfay's blog