Skip directly to content

Drupal Planet

Topical posts related to Drupal and syndicated for the Planet Drupal feed.

Making Targeted Drupal Cache Clears using Drush

April 07, 2014

The standard Drush command for clearing Drupal's cache looks like this:

	drush cache-clear all

(You can also use the shortened alias cc like this: drush cc all)

These commands give you the same result as when you click that cache clear button in the UI  it clears all of Drupal's internal caches.

But clearing all of Drupal's caches at once can be overkill. You usually don't need to clear everything, and doing so can put heavy load on your servers (especially if your site is large or gets a lot of traffic). Beneath the surface, Drupal's caching is actually pretty granular, and tools like Drush give us the ability to target and clear caches on the subsystem level.

Using Drush, you can see your caching options with:

	# Using the shortened alias from this point on.
	drush cc

Which returns something like this:

[0] : cancel
[1] : all
[2] : drush
[3] : theme-registry
[4] : menu
[5] : css-js
[6] : block
[7] : module-list
[8] : theme-list
[9] : registry

Let's look at what each of these does (as a quick note, I'm specifically looking at Drush 6, which is the major version at this time):

drush cc all
Remember how I said that this does the same thing as the cache clear button in the UI? Well, that's technically false. Yes, drush cc all will clear all your Drupal caches (as long as it can bootstrap Drupal), but it will also clear its own internal Drush cache. That's why when Drush cannot bootstrap Drupal, you will still see a success command saying 'drush' cache was cleared.

drush cc drush
This only clears Drush's internal cache (the same one I just mentioned). You don't need a Drupal site available to clear this cache.

drush cc theme-registry
This command simply calls drupal_theme_rebuild() to rebuild the theming system. This is needed whenever new ".tpl.php" files or theme hooks are added to the system. This specific cache clear only applies for Drupal 7 and up.

drush cc menu
This runs a menu rebuild, which refreshes the database tables used by various menu functions. For example, any new router items (like those defined in hook_menu) are added to the menu_links table, and stale ones are removed. This also clears the page and block caches, to prevent the display of stale menu links.

drush cc css-js
If you have CSS or JS aggregation enabled, this will rebuild the aggregated files. It also increments the query string on CSS & JS links, forcing clients that have cached an old copy to download a fresh one.

drush cc block
Block caching exists so Drupal doesn't have to look up the locations and visibility of blocks with each page load. This command refreshes that cache.

drush cc module-list
This re-scans the module directories in your codebase and refreshes Drupal's internal list of which modules are available.

drush cc theme-list
This re-scans the theme directories in your codebase and refreshes Drupal's internal list of which themes are available.

drush cc registry
Drupal maintains an internal registry of all functions or classes in the system, allowing it to lazy-load code files as needed (reducing the amount of code that must be parsed on each request). The list of these files is known as the "code registry" and it is stored in the system table in your Drupal database. This cache clear will look at this list of files and update the contents of any files that have been changed. Note: it will not rebuild the registry from scratch. For more information, see registry_update.

drush cc ?????
You may see other options in this list, because contributed modules (like views and advanced aggregation) can add their own kinds of cache clears. In each case, you'll see a file in the contrib module named something like that contains the code which defines what the cache clear does.


If you want to see what each of these options does on a code level, you can download Drush and inspect the file found at Drush/commands/core/

Template Picker Now Supports Entities

January 25, 2014

Several months back, I released a module to, called Template Picker. The idea was that it was too difficult to set up a workflow where content creators could pick how they want their content to be displayed. It either required heavy site building using tools like Panelizer (outside version control), or one-off custom development.

The way Template Picker works, you drop node templates into your theme for each way you'd like to display your content, and, as long as the file name matches the naming convention, it will be available as an option on the corresponding node-edit page. If that's too much Drupal lingo for you, you can see a video demo here.

But what I really wanted was to think outside the node and see if we could allow template picking for all sorts of entities. This way, a user could choose a style for their user profile, or a content admin could assign taxonomy term listings to predefined displays. It took some digging into the entity API, but I finally got it coded up and released over the Christmas holiday. I also depricated the old project on to fix a renaming issue (kind of a pain, but that's the price of learning).

If you think something like this could be useful for your next project, you can check it out on

There's more than one way to save a node

January 01, 2014

Every day, millions of nodes are saved. It happens every time content is created, migrated, or updated. It's probably the most common content management task in Drupal.

But there are lots of ways you can change the node-save experience for your users, and there are many contributed modules that offer alternative approaches to saving nodes. Here are a few that I like.

Add another

The Add Another module allows gives users the option to save a node while quickly creating a new one. You can choose to add the option to the admin form itself, or as part of the save confirmation message. It's great for those content types, like "Image" or "Video" for example, where your users find themselves creating a series of nodes in succession.

Hide Submit

Occasionally you'll see an issue where an end user clicks submit on a the node-edit form and, being ignorant of the fact that the request is being processed, clicks submit several more times to see  if it's broken. Sometimes this can lead to multiple form submissions, resulting in bad things like duplicate content. The Hide Submit module does one simple thing: Prevent forms from being submitted multiple times. It does this by disabling the submit button once it's been clicked, with settings to fade out the button, append text, or hide it all together. This prevents errors, but it also signals to the user that the submission is in progress, helping to alleviate a bit of the frustration.

Publish Button

"Does the word "Save" mean that I'm saving a draft or does it mean that I'm publishing the content live?" While it may be obvious for those familiar with Drupal, the intent of the button isn't always clear for new users. The Publish Button module aims to make it more explicit by splitting up the "Save" button into two buttons: "Save" and "Publish". If a node is published, the publish button is replaced with an "Unpublish" button.

Node Buttons Edit

What if you have your own idea on what button text should be used? You could use "string overrides" module for a universal approach to text customization, but the Node Buttons Edit module gives you a straightforward admin page for customizing the button text specifically. No need to incur the additional overhead if you don't have to.

More Buttons

The More Buttons module gives you the option of turning on more buttons (shocking, I know), to further customize your content saving experience. For example, you may want a "Save and Continue" button to save the status of the current input while continuing to make changes. Or maybe you'd like a cancel button, to close the form altogether. If so, this module makes these (and other options) available to you.

So next time you see users tripping over the node saving workflow, remember that you, as a sitebuilder, have a handful of options at your disposal to make things a bit more clear.

If Gmail were built with Drupal

November 09, 2013

A comparison of the Gmail interface with similar fields in Drupal's interface

So what are you trying to say?

Admins and content creators who use Drupal are going to compare their experience using Drupal to the other modern web applications they use, like Facebook, Evernote, and Gmail. Many of those products have entire teams of usability experts who optimize their products for their users. While Drupal has come a long way, just comparing the interfaces is instructive for showing us where we can improve.

Is Drupal's interface really that bad?

It works, but the data is in and content creators are struggling. The form is long, which is intimidating, and requires scrolling to complete. It's long because space isn't always used efficiently, with wide gaps in some places, and seldom-used features taking up a lot of room. The form itself lacks some of the more clever and user-friendly form elements that other applications use for autocomplete, tagging, multiselect, drag and drop, and others.

What do we do?

We raise awareness. We explain that if Drupal is succeeding, it is despite its authoring experience, not because of it. We acknowledge the issues that exist, and we chip away at them in the core issue queues as much as we can. Then we celebrate every victory we have (three cheers for the improved installation interface!).

And in the mean time?

There are plenty of small things you can do to improve things on your existing sites. Integrate better form elements. Simplify the node-edit page. Try out some alternative admin themesOrganize your fields to help reduce confusion. There are a lot of contributed modules that can help empower your content creators, and if you can't find the one you're looking for, then build it (and share it with the rest of us). Piece by piece, we can make Drupal actually feel like the modern web-publishing powerhouse that it is under the hood.

Note: This image came from a talk I gave at Capital Camp, where I go into more detail about the specific issues in the Gmail clone, and some things site builders can do to improve things. If you find this topic interesting (or you just want some more context around this example), go check it out.

Learning Drupal with the Janki Method

October 12, 2013

One of the best ways to set yourself up to succeed with Drupal is to adopt a habit of continuous learning. I'm sure there are plenty of ways to do this, but over the past 8 months, I've been using a system called the Janki method, and it has really served me well. This post is intended to explain what the Janki method is, and how you can use it to learn and retain Drupal information.

What's the Janki Method?

The "Janki method", is a technique for retaining the programming knowledge by using spaced repetition software. Space repetition can be used to learn anything from fractions to Farsi, and it's also effective for learning Drupal.

Wait… spaced repe-what?

Basically, there's a category of learning software called "spaced repetition software." Think of it like flashcards, but smarter. These flashcards are designed with algorithms to adjust the repetition of facts so as to maximize your ability to retain the information. The algorithms are based on studies about long-term retention of information.

Anything you plan on remembering for more than a couple minutes requires repetition. Your current Drupal knowledge consists of the tasks you've performed repeatedly, like creating a new content type or writing a hook_menu implementation. But learning Drupal like this is inefficient because some tasks tend to come up a lot more frequently than others. With my work, I get a lot of practice adding values into the vars array and printing them in templates, but I already know how to do that. What I really need is repetition working with imagecache, multilingual, or other areas where my knowledge is fuzzy.

Enter Anki

Anki is an open-source spaced-repetition tool that you can use to make learning Drupal less random and more efficient. There are other tools out there (paid and unpaid), but I've been using Anki because it syncs across devices and it's free. There's a web version, and desktop version, as well as apps for Android and iOS.

How it works

At it's core, Anki lets me create flash cards. Each card has a front and a back. You simply put your question on one side and the answer on the other. There are a few variations on the format, like fill in the blank, etc. You can organize these cards into decks and tag them. Boring, right?

WRONG! Let's look at one of my cards.

Convert the following PHP logic into the ternary syntax:

Ok, cool. We've got a little programming challenge and a text field where we can put our answer. Once I submit my answer, I get the following screen:

$calories = ($coke == 'diet' ? 'low' : 'high');

The yellow highlighting indicates that the answer I submitted was correct. However, instead of just sending this card to the bottom of the pile, Anki asks me to rate the difficulty of the question. If it was easy, then I don't need to see the card for a while. If it was hard, then I should see it sooner. The time indicators above each of the buttons at the bottom tell me how long it will be until I see the card again.

As you can see, the lengths of time on this card are pretty long (4.6 months, if the question was easy). That's because I've answered this question many times before. When a card is first created, reminders happen often because the knowledge is fresh and more likely to be forgotten without frequent reminders. Reminders decrease in frequency over time, and adjust as Anki learns which cards are easy or difficult for you (according to its learning algorithm).

Using this to learn Drupal

Lets be honest, you can't completely learn Drupal just by answering flashcards. You need to be working on a Drupal instance, trying to build stuff with it, in order to get any kind of comprehensive understanding. But the Janki method shines at taking those discrete pieces of knowledge that you come across in the process, and ensuring that you remember them. That means fewer Google searches, less trips to, and less context switching. If you've ever secretly wondered whether you were really a good Drupal developer, or just a good "Googler", then the Janki method is one way to help you become the former.

That being said, you don't just "do Janki" and call it good. If you go into it with the wrong technique, you could end up defeated. Here are a few techniques that I found to be helpful along the way.

1. Build your own cards.

Anki allows you to import & export cards, and since it has an open source community, it's easy to find card sets online that other people have built. It may be tempting to download somebody else cards to kick off your study, but you'd be doing yourself a disservice. Why? Because when you make your own cards, you separate the initial learning of the concept from the remembering, which is important. You want to be in a situation where you aren't needing to learn something new with every card you look at because it totally changes the experience. You'll find yourself saying, "I have no clue what this answer is… yep, I wouldn't have guessed that." Compare that to, "Oh, man, I should know the answer to this one… shoot! I can't believe I missed that!". If you use somebody else's cards, you find ones that are too easy, too hard, or not exactly relevant to your unique blend of skills and workflow. Finally, without giving context to your knowledge it'll be more difficult to remember new information.

2. Make it a habit.

I work with Drupal nearly every day, so it was pretty easy for me to get in the habit of both writing and solving cards. For writing, I downloaded Anki for Mac onto my work computer so I could  leave the application running on a separate Mac desktop during the day. Whenever I came across a new function or found a technique I wanted to remember, I'd hop over to Anki, add a new card, and hop back into my work.

As for solving, I downloaded Anki for Android, so I could solve cards on my smartphone whenever I had free moments during the day. While that seemed good, it didn't really work because I was always more tempted to read RSS feeds, check Twitter, or do something else during my spare time. Instead, I recommend working it into a daily routine. I settled on a system where I needed to scan a barcode in the other room to turn off my alarm clock. Once the alarm turned off, my phone would automatically launch Anki, and I'd sit down and solve the three or four cards I needed to do for the day. Great for waking up the mind early in the day.

3. Write good questions.

Your learning is only as good as your questions. Bad questions will give away the answer in the wording of the question, or allow you to memorize the answer without understanding the concept. Good questions force you to understand the concept in order to solve them. It took some trial and error, but I started to learn what kinds of questions really worked well for me.

Use fill in the blank

The "Ternary" question above is a good example of this. Forcing yourself to write a line of code as an answer is good because you're applying the exact knowledge you'll need. I don't need to memorize the "idea" of a ternary operation. I need to memorize the exact syntax because if I'm programming and I miss one semi-colon, my application breaks. 

If I don't force myself to write a line of code as an answer, I find myself clicking "Show Answer" before I've really committed to my answer. That leads to me "kind-of" getting it right, and "kind-of" learning it, which means I usually end up needing to google the exact syntax later.

Avoid True/False questions

While I'm sure there are instances when these are appropriate, they tend to be less effective to me. It's easy to word them poorly and make them easy to guess. For example, here's one of my less-than-awesome True/False cards.

True or False: User 1 has all Drupal permissions and none of them can be revoked on the permissions page.

Seems like a good card right? The problem is that the very existence of this card makes it easy to guess the right answer. Why would I make this card if User 1's permissions were revokable like anybody else's? I wouldn't, so the answer must be "True". While it's possible to write good True/False questions, it's not easy, so I tend to stay away from them.

Don't play "guess the parameters"

I thought it would be really cool to memorize the parameters of Drupal functions, and it is! However, the right way is to teach yourself how to apply the function (parameters included), instead of just guessing what the parameters are. Here's an poor example:

Which Drupal function do you use to determine whether th user has a given privilege? (Include parameters)

This question forces me to memorize stuff that I won't be need when I'm writing code later, like the words "string" and "account". I think we could word this better:

Using Drupal APIs, test to see if the current user has access to 'administer views' , and store the result of the test as a boolean in the variable $is_views_admin.

There. Now we're testing the same knowledge, but in the exact application that we'll need in the future. That looks better.

Anything else?

I could mention more of Anki's features, like its online plugin library or all the data and charts it produces (great for quantified self junkies), but I'll leave you to explore more into it if you are interested. Here are a couple more articles about the Janki method, that were helpful for me along the way.

Whether you've been working with Drupal for 6 days or 6 years, there's a lot left to learn. Using the Janki method has worked well for me, and I'd happily recommend it to anybody who is deliberately trying to learn Drupal, whether you're working on mastering Drupal 7 or just getting started with Drupal 8.


I've had several requests to see some of my cards and while I recommend you build your own, I do think that seeing somebody else's may be useful as an example. Thus, I've included them at the link below. They're not perfect, especially the early ones I made, but they may give you some ideas.

Bryan's Programming Deck