Half a year ago I wrote a blog post about various stumble blocks I had run into in my first year as a Drupal developer. I called them gotchas because they were not necessarily bugs - they might just be Drupal’s way of doing things which may confuse people new to or experienced with Drupal. Sometimes they are annoyances - they could be called paper cuts too. The post got some attention - which was great because people started sending me tips about things they ran into. Now there is time for a new round!

Half a year ago I wrote a blog post about various stumble blocks I had run into in my first year as a Drupal developer. I called them gotchas because they were not necessarily bugs - they might just be Drupal’s way of doing things which may confuse people new to or experienced with Drupal. Sometimes they are annoyances - they could be called papercuts too. 

The post got some attention - which was great because people started sending me tips about things they ran into. Now there is time for a new round! 

First I’d like to start with an update to my previous post - good news! 

Outdated gotcha: Features module and taxonomy

In the comments Damien McKenna pointed out

Features v2 now uses the machine name and labels for permissions, roles and vocabularies, making exporting those much easier than it used to be.

Which is true. It was just that we were using the “Taxonomy Access Fix” module in that project, and it was not using the machine names. But that module has been updated to also use vocabulary names. Things do get better in Drupal! 

New gotchas I have foundGOTCHA 1: Trying to be consistent about naming? Not too fast! 

I can’t believe that I didn’t stumble into this one before, I have a feeling it hits a lot of people new to Drupal: When starting a new project, you might want to be consistent about naming, and give a custom project module and theme the same name. 

Well, buddy, that is asking for trouble! And different trouble every time to confuse you even more - a search of any error message that pops up might not give you the cause as the first result in Google. 

This duplicate naming problem can of course happen between your own custom modules and contrib projects you add from drupal.org. 

Andreas also adds that you will also run into trouble if give your site profile the same name as your theme (and possibly also module names). 

This is documented in Drupal's documentation, which you of course have read thoroughly: https://www.drupal.org/node/143020

Tips for best practice in naming: http://drupal.stackexchange.com/questions/851/best-practice-for-avoiding...

Gotcha 2: Where was that module again? 

In a direct response to the original blogpost, reddit user tranam mentioned: 

The biggest gotcha in Drupal, as far as I'm concerned, is having a modules folder, and a sites/all/modules folder. 

http://www.reddit.com/r/drupal/comments/1vuneh/bernts_drupal_gotchas/

Gotcha 3: Updating a module doesn’t 

Lauri mentioned this:

You're trying to update a module and it doesn't update. drush up, drush updb, disable, enable, delete, download, etc.. and it's still the same! Then a colleague points out the obvious: You have the module installed in more than one place, like /sites/all/modules and /sites/all/modules/contrib or even a submodule of another module.

To find out if this is your problem, you can run SELECT * FROM system  to see the actual path that drupal has associated with a specific module. 

Gotcha 4: The pesky feature that won’t revert (multilingual sites)

So you just pushed a git commit to a server, and you’re trying to revert the feature, but it just won’t happen. You have tried the magic cache-clearing/php-fpm reloading/cache-clearing incantation several times already, but no no no no go. 

Then you look at the feature diff, and you notice that .. you were looking at the feature page in a different language from it was made in. Aargh! 

Gotcha 5: Browser based language detection is killed by page caching

Florian told me abot this one: If you have page caching enabled the browser based language detection will not work due to a bug in core.

This dropbucket snippet might work for you though: http://dropbucket.org/node/728

Gotcha 6: Dragging and dropping around in panels don't work

Juho V tipped me about this one - and Sampo provided the workaround: 

[11.57.59] Sampo: Sulla on exposed formi tossa. Disabloi se view, draggaa toi paikalleen ja toimii.

Decrypted from Finnish it reads: You have an exposed form in there. Disable that view, drag it to it’s position and it will work. The exposed form is what breaks the drag and drop, so you better just disable that display. 

Gotcha 7: Administer Content permission is powerful but not that powerful

Mario notified me about this one: 

Administer Content permission sounds all powerful: But if you're not user 1 you can still not access unpublished content if it is not edited by yourself. 

You also need "Bypass content access control" permission - or you could use the “view_unpublished” module. 

Gotcha 8: Multiple meanings of “vid” in the database

This has baffled me, at least, when poking around in the database trying to figure out how to solve a case. And I am not the only one: http://drupal.stackexchange.com/questions/13266/what-does-vid-mean

marcvangend at Drupal Answers writes in http://drupal.stackexchange.com/a/13269 :

Unfortunately, vid can mean multiple things. That's not ideal, but I have not seen it causing problems (other than mild confusion now and then).In the context of nodes, it means 'version id'. For every node in the node table, Drupal can save multiple versions in the node_revisions table. The version id is the unique identifier in the node_revisions table. (This is the vid you see in your query.)In the context of taxonomy, vid means 'vocabulary id'. A vocabulary is a collection of related terms. Every vocabulary has a unique id.In the context of the Views module, vid means 'view id'.

Gotcha 9: EntityFieldQuery executed from cron checks access right

Teemu reported this one: If you are running EntityFieldQueries from cron, you might not get the expected results because EFQ does indeed add it’s own access checks. 

Solution: 

$query = new EntityFieldQuery();
$query->entityCondition('entity_type', 'node')
->fieldCondition('field_something_id', 'value', $something_id)
->addMetaData('account', user_load(1));

The last line makes it sure its loaded as Dries. 

An alternative is apparently to use this one (which was added in Drupal 7.15):    

->addTag('DANGEROUS_ACCESS_CHECK_OPT_OUT')
Gotcha 10: Blocking users does not block immediately

Reigo reported this experience: 

I once discovered a blocked user who had logged in before he was blocked, and he was still active! So after blocking, empty the session table.

Note: Emptying the session table will also log out ALL the site’s users - so you might think twice about that. One option is to remove the session for that specific user id. 

Gotcha 11: Want to disable the query pager? We’ll trip you up

If you have a query object and wish to return all items, you might try and set the limit to null or false to disable the pager. No go: 

https://api.drupal.org/api/drupal/includes%21pager.inc/function/PagerDef...

public function PagerDefault::limit

States: 

Specify the maximum number of elements per page for this query.
The default if not specified is 10 items per page.
$limit: An integer specifying the number of elements per page. If passed a false value (FALSE, 0, NULL), the pager is disabled.

Did you think that a disabled pager would return all results? Sorry, daften states this https://api.drupal.org/comment/13964#comment-13964

I would expect disabling the pager would mean everything is shown, instead nothing is returned.

Gotcha :) 

Gotcha 12: Views with date filter not returning what you want

I was struggling with a view with filters for a date field, that did not return what I wanted. I suppose the following conversation speaks for itself: 

[15:08:17] Ilmari: ha!
[15:08:19] Ilmari: I got it
[15:08:26] Ilmari: Guess what, its the granularity
[15:08:32] Ilmari: It is set to "day"
[15:08:38] Ilmari: instead of seconds
[15:08:56] Ilmari: In the "settings" part of the filter (separate settings)
[15:09:16] Ilmari: Filter granularity => Day
[15:09:21] Ilmari: should be => Second
[15:10:36] Ilmari: Did you find "Filter granularity" under "Settings" for the filter?
[15:11:08] Bernt: I didn't find that
[15:11:09] Ilmari: Pretty annoying that the default is a day
[15:11:18] Ilmari: Content: Date - end date:value2 (yesterday) | Settings
[15:11:25] Ilmari: --> "Settings"
[15:11:32] Bernt: Oh hah there!! GRRRRRRR hitting my head in the wall
[15:11:36] Ilmari: :D
[15:11:36] Bernt: or on the desk, it is closer
[15:12:02] Ilmari: I've encountered that exact problem several times, i always forgot to check those settings..
[15:12:22] Ilmari: ..and the default "day" granularity doesn’t really make sense, usually
[15:12:56] Bernt: Thanks man
[15:13:45] Ilmari: heh
[15:13:50] Ilmari: Glad I could help this time
[15:13:50] Bernt: Well, another GOTCHA for my list

So when you are working with a date field in views, remember to check what the granularity setting of the field is. Date defaults to day, which doesn’t work too well if you are more interested in now! 

Gotcha 13: Site name in a feature that depends on .. 

Florian reported this find: 

Don't export the site name in a feature that's a dependency of an installation profile, or you won't be able to install. 

It just happens that the installer checks the site name to test if Drupal has already been installed or not, so if you add that variable to a feature, then it thinks that the installation has already been done.

In the meantime, you can just set the title during an install task (that runs later in the process).