Skip directly to content

Drupal Planet

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

An Opinionated Guide to Getting Help with Drupal

March 18, 2015

You are facing a Drupal problem and you need help. We've all been there.

Drupal is a mature open source project with a vast community, so there are a lot places you can look for help*, and they all have their pros and cons. I’ve spent nearly 4 years trying them all and I found that some options work better for me than others. If you want to save yourself the experimenting and just use the opinionated approach I use today, then stick around; this is the guide to getting help with Drupal that I wish I had several years ago.

Without further ado, here is the list of support channels I currently use, prioritized in the order that I use them:

1. Google It

Many things can be solved quickly through an online search. Drupal.org has a search bar, and I tried to use it a lot when I was getting started, but I’ve since learned that you just can’t compete with Google when it comes to search. Pro-tip: you can search Drupal.org exclusively from Google by using the “site” keyword: “site:drupal.org."

Strength: Access to a ton of content. Exact searching of error messages.
Weakness: You often have to know the right vocabulary

2. Ask People you Work With

Online searches can fall short when your problem is fairly specific, or you don’t know the right vocabulary to use to describe your problem. Sometimes you just need to point at a screen and say “have you ever seen this before?” Face to face communication is fast, and effective (as long as you’ve got somebody experienced around you can talk to).

Strength: Face to face communication is often faster and easier
Weakness: Success will depend entirely on who you work with

3. Ask On Stack Exchange

Stack Exchange is a well-designed Q&A site that provides community-curated answers to programming questions. You’ll find that there are Drupal questions on both the main site (stack overflow.com) as well as the Drupal-specific site (drupal.stackexchange.com), but you’ll want to ask Drupal questions on the Drupal site. I have found the community there to be very active with most of my questions receiving responses in a matter of hours.

Strength: It’s a forum highly optimized for a good Q&A experience.
Weakness: The wrong kind of questions won’t survive here (like subjective questions or site-specific issues)
Link: http://drupal.stackexchange.com

4. Drupal.org Issue Queues

If you can isolate your issue down to a specific project (like a module, theme, or Drupal core) then you can go to the Drupal.org issue queue for help. If your issue has already been reported in the queue, you may find recommendations from the maintainer or even patches that fix the problem. Otherwise you can report the issue yourself. On one occasion I needed to fix an unfamiliar search-related issue that was outside my skill set, and I reported it in the issue queue of a contrib project. The maintainer got back to me in 2-3 days and posted a patch that fixed it. I benefited by getting a fix from an expert (which could have taken me days/weeks to figure out myself), and the project benefited from my QA work (the fix was included in the next module release). That’s the power of open source.

Strength: Can get expert feedback (and maybe even fixes) from module maintainers.
Weakness: Not useful unless you have isolated the issue.
Link: http://www.drupal.org/project/<project-name>/issues

5. Official Documentation

By official documentation, I’m talking about the Docs on Drupal.org, explanations on Module pages, or information found in README.txt files. These docs are often a great place to look if you are looking for help getting a module or theme installed and set up for the first time. Other than that, I haven’t had much luck browsing through them for my specific issues. The way I see it, if something in the official docs addresses your problem, you’ll come across it when googling your issue.

Strength: Entry-level instructions and set-up steps.
Weakness: Contains a lot of old information. Difficult to browse.
Link: http://drupal.org/documentation

6. Twitter

It’s hard to have a good conversation in 140 characters, but if you have enough followers who know Drupal (or you can get a retweet from somebody who does) then it can still be valuable. One way I’ve used it effectively is to ask my question on StackOverflow and then send the link out to Twitter to give it some attention if I’m not getting answers.

Strength: You may have more success asking your personal connections.
Weakness: 140 character limitation. Question can get lost in the mix.
Link: https://twitter.com

7. IRC

The Drupal community has IRC chatrooms on freenode at #drupal and #drupal-support designed for support. Some people really like using IRC for support; In some ways it’s like the “asking people you work with" suggestion above. That being said, I’ve always struggled to get answers via IRC. I feel awkward jumping in when there are already conversations in the channel, and several times I’ll ask a question but it promptly gets lost in the back scroll with no response. Plus, questions asked in IRC are usually not archived or searchable so the conversation you have won't benefit future people with your problem. So your mileage may vary, but I’ve yet to have a successful support experience on IRC.

Strength: Community of experts
Weakness: Chatrooms are not designed for Q&A.
Link: http://drupal.org/irc

Other Options

There are other options that I won’t discuss in detail. They all have strengths and weaknesses (which I’ll list below), but they aren’t really part of my main help workflow for one reason or another.

  • Drupal.org Forums - My questions have gone unanswered here. I’ve seen successful threads, but they seem pretty rare to me.
  • Groups.Drupal.org - Quality varies widely from group to group. I’ve seen groups with good discussion and others with lots of spam.
  • Local User groups - Good for subjective questions but not deep troubleshooting.
  • Books - Good for generic instruction, site building, and walkthroughs but not for heavy custom development.
  • Training - Can be online, on-site, or workshops. Good for generic instruction, site building, and walkthroughs but not for heavy custom development.
  • Conferences - Good for generic instruction and subjective questions. Not great for deep troubleshooting.
  • Example modules - Good for learning Drupal coding patterns but not for troubleshooting
  • Professional Services - Good for getting high-level architecture and security recommendations. Offering varies depending on the provider.
  • Api docs - Good for looking up specific Drupal  API functions.
  • [Insert your social network here]

Finally, whatever you ask, and whoever you ask it to, remember that you have a responsibility to ask good questions.

* Here’s the official drupal.org page on getting help (we covered all the options here and more).

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 mymodule.drush.inc 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/cache.drush.inc.

Template Picker Now Supports Entities

January 25, 2014

Several months back, I released a module to drupal.org, 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 Drupal.org 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 Drupal.org.

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.

Pages