RandyFay.com

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

Tom Geller's new book Drupal 7: Visual Quickstart Guide is a concise, dense sitebuilder/administrator's guide to Drupal 7. It provides a pretty decent task-oriented overview of D7 sitebuilding and administration. It's a manageable size for almost anybody, about 210 pages of primary content.

Overall summary: The book does well what it sets out to do, which is provide a user-interface task-oriented introduction to Drupal 7 for sitebuilders and administrators (in a reasonable size package). That approach has innate drawbacks, but so does every other approach, right?

Update: Please read this update on my experience before using the technique in this article.
Update: See the drush implementation of this approach in the comment below.

DamZ taught me a great new piece of git trivia today. You can use a local repository as a kind of cache for a git clone.

Let's create a reference repository for Drupal (and it will be bare, because we don't need any files checked out)

git clone --mirror git://git.drupal.org/project/drupal.git ~/gitcaches/drupal.reference


That makes a complete clone of Drupal's full history in ~/gitcaches/drupal.reference

Now when I need to clone the Drupal project's entire history (as I might do often in testing) I can


git clone --reference ~/gitcaches/drupal.reference git://git.drupal.org/project/drupal.git


And the clone time is on the order of 2 seconds instead of several minutes. And yes, it picks up new changes that may have happened in the real remote repository.

Sometimes, whether in testing or other situations, you need to reset a password (often the admin password) for a Drupal site.

Edit: The shortest answer is that two wonderful options are built into drush!

Get an admin login link

drush uli

Set the password for any user

drush upwd admin --password="newpassword"

(More info on drush uli below.)

Now for the long version

In Drupal 6, you could just reset the admin password with:

cd
drush sql-cli # or mysql -u -p
UPDATE users SET name='admin', pass=md5('drupal') WHERE uid=1;

and then log in with username 'admin' and password 'drupal'.

But no more. Drupal 7 has a unique hash for each site, which means you can't just use the md5() trick any more. However, there is a script in the scripts directory that will do this.


cd
php scripts/password-hash.sh 'drupal'


Update October, 2014: Lots of things have gotten easier over the years.
These days, the easy way to fix this set of things is with the Pull Request workflow, which is essentially the Integration Manager workflow discussed here (probably).

• Use github or bitbucket or somebody that makes the PR workflow easy
• Delegate a person as integration manager, who will pull or comment on the PR
• Require contributors to rebase their own PR branch before pulling if there are conflicts.

Update: Just for clarification, I'm not opposed to merges. I'm only opposed to unintentional merges (especially with a git pull). This followup article describes a simple way to rebase most of the time without even thinking about it). Also, for local development I love the git merge --squash method described by joachim below.

Last week I had the wonderful opportunity to spend a few days learning Microsoft’s Azure cloud technology (and catching up on lots of Windows Server technology too - it’s been a while). Now, admittedly, this was unfamiliar territory for me as I’ve been away for a few years. You may laugh, but I had a serious case of culture shock as I experienced the difference in empowerment and support between the two environments.

In the Microsoft world,

• if you have a problem there are ways to get support, but most of them require knowing a bunch of forum-type websites or paying money to somebody.
• If you need free support, how do you find out where you would get it?
• If you discover a bug, what do you do?
• If you know how to solve a bug, how do you get the solution committed?
• If you know how to improve a product, how could you have any confidence that you could influence it?

In the Drupal world,

Edit 2015-08-30: The bottom line years later: Use the (Github's) Pull Request methodology, with a responsible person doing the pulls. You'll never have any of these problems.

I learned the hard way recently that there are some unexpectedly horrible things that can happen to a project in the Git source control management system due to its distributed nature... that I never would have thought of.

Edit: Please follow Gábor Hojtsy's excellent series on translation in D7, if you're not already following it. It's more up-to-date and more authoritative. You'll probably be interested in Drupal 7 Multilingual: What's new in I18N.

Drupal has long been a leader in the ability to present a website in multiple languages. In Drupal 7 we continue that tradition: Field translation or "content translation" made it into Drupal 7, but it's not obvious from a plain Drupal 7 install how you would use it.

This article is fundamentally about content translation, not about interface translation, which is a completely different thing in Drupal (and always has been). Interface translation is about prompts, labels, menu entries and the like, all of which are handled by the core locale module and various contrib modules like i18n. I will explain how to import basic interface translation files, however.

Drupal 7 Module Development (Matt Butcher et all, Packt Press, December, 2010) is a great step forward for Drupal 7. It packages up key D7 information about theming, the render system, entities, fields, the Form API, node access, and the File API all in one place. Summary: If you're doing D7 module development, either for the first time or switching moving from Drupal 6, you need this book.

Some parts of the book were more familiar to me, and as a result less impressive, so I'll focus on the parts that were most useful to me:

I'm thrilled to announce that I'm going to work for Commerce Guys starting tomorrow. Yes, a real job! I'm looking forward to working with some great people on some fun projects, and of course Commerce Guys is well known for promoting contributions to Drupal and the Drupal community.

My first act will be to participate in the Drupal Commerce code sprint in Paris next week, and wow, am I looking forward to that.

Woohoo!

A unique and surprising feature of the Drupal user object up through Drupal 6 was that you could throw any crap into it you wanted and then run user_save() and it would be there. So in Drupal 6:


user_save($account, array('some_random_stuff' => 'surprisingly random');


Well, that always seemed way too easy and it was. After a security problem was discovered with this in way early D7 alpha days, it was decided to make this far more explicit and deliberate. Now you have to have implement hook_user_presave() to actually move your data into the right place and prove that you really wanted to do it.

Best practice says that we're going to save settings into the user object keyed by the module name. So if my module is named 'mymodule' in Drupal 7:


...
$stuff = array('some_random_stuff' => 'surprisingly_random');
user_save($account, array('mymodule' => $stuff);

It's a treasured geek secret that ssh can tunnel TCP connections like ssh all over the internet. What does that mean? It means that you can access machines and ports from your local machine that you never thought you could, including git repositories that are behind firewalls or inside VPNs.

There are two steps to this. First, we have to set up an ssh tunnel. We have 3 machines we're interacting with here:

• The local machine where we want to be able to do a git clone or git pull or whatever. I'll call it localhost.
• The internet or VPN host that has access to your git repository. Let's call it proxy.example.com.
• The host that has the git repository on it. We'll call it git.example.com, and we'll assume that access to git is via ssh on port 22, which is very common for git repos with commit access.

Step 1: Set up a tunnel (in one window). ssh -L3333:git.example.com:22 you@proxy.example.com

The beta is out so here's another site migrated to D7. It's a very simple site, but it did upgrade. I had a few problems, but mostly it went OK. I like the Corolla theme that this works with. I like Bartik too, but Corolla is it for now.

If you're like me you've heard "render arrays" or "renderable arrays" over and over again in the Drupal 7 development cycle, but you might not have really understood what it was all about. Here are the results of my own exploration in developing the new Render Example for the Examples project.

Remember the Form API? Or the content section of a $node or a $user in Drupal 6? Basically now everything is kept in a form like that until the very last minute in D7.

What's this about "rendering"?

Rendering in the Drupal world means turning structured "render" arrays into HTML.

• Sweaver: Incredibly, this lets you adjust your site's appearance easily and intuitively on the fly. Just diddle with the font! Change the background color of a region, or add a background graphic. Incredible.
• Context: Quit procrastinating. Context is easy to use and easy to understand and will vastly increase your ability to configure the appearance and behavior of a page or section. Seriously. You don't have to wait. It just works. It's intuitive. Try it.
• @Font-your-face: You can really have a billion free web fonts that actually work in all modern browsers on all platforms. No more weird graphics creation. So easy to use. Again, this doesn't take any time or effort.

greggles showed me how to make a view show different content to different users by role the other day, so I thought I'd write it down.

The goal: Displaying different nodes to administrators than I show to just authenticated users and that different than what anon users see. (In this case, I'll show pages to administrators, stories to authenticated users who are not administrators, and articles to anonymous users.)

The strategy: Create three different displays in the view, each of which is limited to a particular role, and each of which has its own filter. The administrator display has a filter that chooses pages, auth user one that chooses stories, etc.

The devil's details: The displays must be ordered by most restrictive to anonymous. The displays are apparently attempted in the order they're shown on the views edit screen. So we need the most restrictive (administrator) first. On that one only administrators will succeed. The next display has the authenticated users, etc.

It's a Drupal and PHP best practice to develop with E_NOTICE turned on. Please do.

I installed a new contrib project from Drupal.org yesterday and found a whole bunch of warnings emitted to the screen. It turned out that the developer of the project had not (apparently) been working with E_NOTICE properly enabled in their development environment and so had never seen these. Two of them were actually obvious logic failures. You want to know when PHP is complaining about your code! (Make sure you have error/warning reporting to screen turned on during development too!)

So here's the deal: PHP has a flag called E_NOTICE. In release version of Drupal it's ignored (in includes/common.inc, drupal_error_handler()). In dev versions of Drupal and in Pressflow it's enabled. Anybody who ever edits PHP code during development should have this turned on. So you can

Edit: This initiative wasn't really successful, but since this was written the testbots migrated onto the OSUOSL Supercell infrastructure. The center for information about the testbots is the Testbot project and issue queue.

Do you have some spare computing power, or want to provide some to the Drupal testing infrastructure?

You probably know that every commit and every patch submitted to Drupal 7 Core gets a full test (more than 20,000 assertions) taking 25 minutes on non-trivial computer hardware. So we can generally use more computing power. For the code sprint at Drupalcon Copenhagen, we had 13 machines testing patches so that everybody could get the fastest possible turnaround.

Anyway, it's not hard to do it. You can either install a machine with Debian 5 and go through a simple setup, or just use the free Virtualbox program with a pre-set configuration. That way you don't have to blow away an existing machine's configuration, and you can still return it to its old life after it's served as a PIFR client for awhile. (PIFR is Project Issue File Review).

Continuing from Form API Changes for Drupal 7, Part 1: $form_state changes.

One of the many pleasant improvements to the Drupal Form API is that AJAX Forms are now really easy. Really easy. We used to call them AHAH forms, and the concept was the same, but they were so complicated that few people attempted them. In D7 we even changed the name to distance ourselves from "AHAH" :-)

In Drupal 6 you had to make a menu entry in hook_menu() that pointed to an AJAX callback handler that was complete black magic. (See a sanitized example.) People did this part differently, and it was hard to figure out the right way. (If you're doing D6 AHAH, the gory details and resources are here.)

In Drupal 7 there is none of that. But we still have to start with the basics so that you'll understand what's going on:

Drupal 7 has had a major (read huge, life-altering) change to its file API. Hopefully it's all good, but you definitely need to understand it if you're porting or developing any D7 modules.

There are two key changes, which I'll deal with one at at time:

[Edit: Added wildcard DNS section at the end, also link to dnsmasq setup instructions; also quick info on nginx defaults]

After my Debugging Drupal talk at Copenhagen today a lot of people wanted to know how to use a wildcard virtualhost, so I promised a quick writeup.

The purpose here is to be able to deploy new virtualhost-style Drupal sites on your localhost without doing any apache configuration (or /etc/hosts, if you deploy a nameserver).

Most of the time Drupal works better (and more like your production site) if you run it as a production site. If I have a site like debugging_example.com, I run it locally as debugging_example.l. That's way better than localhost/debugging_example, because all the URLs work right, and it's clean URLs.

The basic idea of what you have to do:

• Enable mod_vhost_alias in Apache
• Configure a catchall virtualhost
• Tweak your .htaccess by uncommenting one line
• Make an entry in your /etc/hosts

Here's the quick version of how to do it:

Cygwin is a great set of Unix/Linux utilities for Windows. Here are quickstart instructions for using it in a Drupal context (for git, patch, ssh, or whatever)

New URL for Zend debugging plugin (now called Studio Web Debugger)

If you're a user of Eclipse with the Zend Debugging Extension and you've tried to use PHP 5.3, you may have noticed that the traditional download location doesn't have it.

The new location for downloading the Zend debugging extension is http://www.zend.com/products/studio/downloads. Get the "Studio Web Debugger" for your platform and architecture (requires registration). (Note that the old location for this was http://downloads.zend.com/pdt/server-debugger/, which is still referred to on many places on the web. This old location has libraries only up through PHP 5.2, but if that's all you need, will work fine.)

Basic debugging with Eclipse Galileo is covered in http://drupal.org/node/157609.

You may know that lots of delicious things have happened to Drupal's Form API in Drupal 7. (Only a geek can say "delicious" and "Form API" in the same sentence. Try it!) The finest minds in the business have been working on it, I can assure you. Give effulgentsia, fago, frando, and chx a big hug when you see them, because Form API is much improved. (Sorry to those of you I forgot to name, but THANKS!)

I'm going to do a series covering Form API changes, starting with this one. I won't attempt to cover the deep details, just the things that ordinary developers might use:

1. $form_state changes and form builder function signature changes
2. AJAX Forms changes
3. New properties (#attached and many friends)

Let me know if you have other topics to suggest.

OK, to business. This article is mostly parroted from the api.drupal.org topic: Form Generation. Thanks to Alex Bronstein (effulgentsia) for his reviews and contributions to that doc.

Drupal is great at handling multilingual situations, but how do you make user-contributed content in multiple languages accessible to those who can't read them?

The Translatable Regions module tackles this by using the automated Google AJAX Language API via the jquery-translate plugin.

What do you have to do?

• Install the module.
• Decide what selectors you want to have translation buttons.
• Configure the selectors at admin/settings/translatableregions.

Whenever those selectors appear on the page, a button is added offering to translate to many languages, the default being the browser language.

Here's an example of the use on user profiles on http://warmshowers.org.

The Examples for Developers Project aims to provide high-quality, well-documented API examples for a broad range of Drupal core functionality. You can download the code from the project page, view it on api.drupal.org, or experience it (for several of them) at drupalexamples.info.

Recently, we've added two new example suites:

Edit 2012-11-12: If you're interested in the newer problem of running PHP 5.3 on Ubuntu 12.10 Quantal, try this recipe.

Edit 2012-09-21: Isn't it about time you moved to PHP 5.3? Even though these instructions seem to work even for Ubuntu 12.04, it's really time for people to move on to PHP 5.3. If you're a Drupal user on Drupal 6, Drupal core and nearly all contrib are now just fine with 5.3.

Edit 2011-11-23: Since Ubuntu 9.10 (Karmic) is now out of support, the repositories to use for it have changed to old-releases.ubuntu.com. I've changed the karmic.list files attached. Please be aware that although 10.04LTS is still supported for years still, 9.10 is out of the support window, meaning that security issues in these packages will not be fixed.

Update: Look here to solve same problem with Ubuntu 10.10.

Lots of us are starting to run Drupal on Ubuntu 10.04 Lucid Lynx, and of course, Lucid comes with PHP 5.3, for which Drupal 6 is not yet ready.

Tomorrow (Thursday, 22 April) we'll be working 9-5 US Pacific time on the Examples Project. A list of tasks is posted on groups.drupal.org and there's plenty of fun for everybody. We'd love to have you join us wherever you are in the world, or physically at the Drupalcon sprint location.

Alex Bronstein, (effulgentsia) one of the maintainers of the Form API, will be doing an off-Broadway session on D7 Advanced Form API tomorrow (Wednesday) at 4:15pm in room 252. This is an exciting chance to catch up on all the great simplifications (and changes) in D7 FAPI.

Topics will be:

• What's changed in D7 FAPI
• The FAPI pipeline
• Pipeline hooks and #properties
• The essential $form_state keys (and the ones that are gone now)
• AJAX Integration
• And much, much more, of course

Check out the slides in advance

If you care about the Form API, BE THERE!

Rob Loach, Kat Bailey and I will be presenting Drupal 7 AJAX and Javascript Monday, 3-4pm, in room 307.

Here are the basics:

• The new AJAX Framework
• AJAX forms, with a complete how-to and sample, easy to understand code.
• The fantastic new #states feature for dynamic forms.
• D7 Javascript changes from D6.
• Using Javascript Libraries.

We've made great strides in Drupal 7. Come and hear about it.

If you used AHAH in D6, you're probably afraid of AJAX forms. But if you never used #ahah, you'll walk out of the room feeling competent to try out #ajax. You can't believe how easy it is now.

We can substantially improve our core software development process with some simple steps in Drupal 8.

<

ol>