The developers of Wunderkraut have worked hard on digging up fun and exciting surprises about Drupal since the last edition was published. Now that Drupal 8 is just around the corner, I expect that this will be the last edition of gotchas about Drupal 7 - brace yourself for new ones in Drupal 8!

Thanks to my great colleagues who have helped me gather this list: Georg, Cristian, Jani, Aleksi, Juho, Mikael, Olli, Federico, Janne, Pauli, Florian, Andreas, Tuomas, Jim, Peeter, Miķelis, Greg

Token translatability

Georg writes: 

This annoyed me for two days and took another colleague of mine almost a day until I accidently came across it, to help him out:

You configure breadcrumb, metatags or you-name-it in this great dynamic way like: "Read all about [node:field-headline]", which is replaced to, say "Read all about Munich".

Everything is just fine.

Until you are starting with translation stuff.

The token simply resist being translated, no matter what.

You put it though t() and surely find it in the translation interface, you translate it to German like "Lies alles über [node:field-headline]" and end up with a German/English mixture: Lies alles über Munich. (while you would expect to see the german word for Munich here: München).

Lots of blood, sweat and tears later you find out that tokens with underscores work just fine: 

Put "Read all about [node:field_headline]", translate it to "Lies alles über [node:field_headline]" and you are done.

Disabling e-mails sent out to new users by Drupal

You know, sometimes you don’t want Drupal to send people all those emails when they are signing up to your site. The slightly annoying problem is that the Drupal interface to choose which emails get sent out is a bit hidden. Deep down somewhere: 

[11:14] Cristian: I just need to disable that single email ... and I*m not finding a contrib module for that
[11:17] Sampo: I think there should be a variable for each of those notifications, but not all of them are exposed to the UI. maybe
[12:39] Cristian: @sampo, you were right . I've added the following to settings.php and all is right in the world
[12:39] Cristian: $conf['user_mail_register_no_approval_required_notify'] = FALSE;
Here is a list of possible values (check the $notify = variable_get('user_mail_' . $op . '_notify', $default_notify); line https://api.drupal.org/api/drupal/modules!user!user.module/function/_user_mail_notify/7

[12:50] Jani: @Bernt This _should_ provide a UI for those: https://www.drupal.org/project/mailcontrol
Panels and Display Suite and region names with 3-col are not friends 

Aleksi wrote this to me: 

Hi! Juho asked me to give this link to you for your next blog post?

It's an issue where Panels layout doesn't work with Display Suite and the issue occurs because I used names like 3-col in the region. 

Time zone handling with Tokens

Mikael writes: Note that when displaying date/time values through tokens, it will use default timezone handling ...even you have configured in field that differently (like no timezone handling etc.)

Another inconsistency - with the date module

[10:23] Olli: Ehhhh... Nice gotcha from the drupal.org page:

<?php$start_date = $wrap_node->field_my_data->value()['value'];$start_date = $wrap_node->field_my_data->value->value();?>

Above two methods of accessing the date value ARE NOT EQUIVALENT. The first one returns date string, and the second a timestamp! I think it should be noted on the page.

Olli also provides an example as to why that value->value() is there: 

Since for date fields:

->value()['value'];
->value()['value2'];

Is pretty much value->value() and value2->value();

Just slightly different output, for whatever reason. 

Block caching - a favourite that has gotten me too

Federico wrote about a strange case: 

I have a block that allows to add products to the cart right under the cart page (/cart). This is a form method post that sends to /cart.
 I can't get why it sometimes works, and then i get first a 302 response and then another GET request of /cart. Other times I get a 200 OK response instead and that's it, no product is added.


Why is this happening - I don’t see no logic to it.. 

And then a bit later: 

Wow @janne fixed it! it was a block being cached, damned little riot!

Following up after this: 

Jani: So resolution was DRUPAL_NO_CACHE Instead of the default DRUPAL_CACHE_PER_ROLE?Pauli: One could say that you should always disable caching for any block that contains a form. 

Caching form token is a bad idea

Note: This is not a problem for anonymous users

This one I picked up from our favourite friend Drupal Answers: 

http://drupal.stackexchange.com/questions/74775/how-to-cache-forms-with-a-reverse-proxy-and-deal-with-stale-form-tokens

"When Form API generates a form, it also generates a token that is passed out with the form in a hidden field, and expected to be returned back. If it is, the form is processed.

If a rendered form were ever to be cached, say, by Varnish, this mechanism breaks. The first user submitting the form will consume the token, and following attempts to use the form will be rejected." writes user Letharion

Libraries API surprise

And here is one gotcha that I stumbled over in a blog post from Garrett Dawson at Aten Design: 

One gotcha that seriously gotcha'd me is the necessity of providing a value for either version argument or version callback. The documentation for hook_libraries_info() says that both are optional, but if at least one isn't provided, the library isn't available to load. If you're not concerned about the version of the library, you can use a short-circuit function for the version callback. 

See the original blog post for more

Rewrite Results with Path results in doubled language prefix

Drupal user Ursula posted an issue where she reported a problem with views and rewriting of paths on a multilingual site at https://www.drupal.org/node/1491742

To "Fields", I added "Content:Path" and another field (Content:Performance Title). I then, under "Rewrite results" of the second field, I check "Output this field as a link", and set [path] as the Link path. I tried this with "Use absolute path" and without.The resulting link includes a doubled language prefix like:http://example.com/en/en/linkednode

dawehner had a great solution at hand: https://www.drupal.org/node/1491742#comment-5802404

Well the problem is that the node:path field is not the best one to use here. A good way is to add a hidden nid field, and then use that as a token when outputting the link like this: node/[nid].

 Display Suite preprocessed fields are a can of worms

It is easy to start liking Display Suite’s preprocessed fields as they are quick to get working. But then you might want to put one inside a Field Group - and boom it won’t work as this issue states: https://www.drupal.org/node/1452198

I got some good advice from Juho: 

I also got smacked in the face a few times in one project by the "inside field group" issue, and after that, I learned that it's usually better to favour hook_ds_fields_info over ds preprocessed fields.

Creating a Views Bulk Operation based on example moduleIt is really easy to implement custom actions for VBO, just create a normal Drupal action. But if you want to edit entities, read this Drupal Answers article BEFORE you start working, note especially what it says about 'behaviour': 

http://drupal.stackexchange.com/questions/30910/how-to-create-custom-vbo-action

I found this information AFTER I had gotten it to work properly - I put the 'behaviour' in there because it made sense according to the example module, but my action didn't seem to work because VBO would overwrite my changes. Thank you VBO for 7 new grey hairs. I went through this so that you don't have to! 

Interesting way to fill up your database

Yet another tip from Florian: 

Be careful with what you put into the t() function. If you put a variable in there, there are good chances you'll fill your translation table very quickly...

Watch out for this when using views and menu_get_object for taxonomy pages

[16:34] Andreas: @Daniel #drupal-gotcha: menu_get_object('taxonomy_term' ..) does not return the expected result, when the taxonomy pages are overridden with views
[16:35] Olli: Yep, need to menu_get_object('views_args', ...) or something similar
[16:37] Andreas: @Olli yeah, and even worse, when the view is placed on a panel page, those things really bite you in the @ßß when the code relies on the configuration remaining unchanged :(
[16:40] Andreas: And it is much easier for debugging, when we do not use the common drupalism to assign the function to a var inside an if test
 if ($term = menu_get_object(...)) gets stepped over in a blink of an eye by the debugger
 Views query alter documentation has important information

kiamlaluno from Drupal Answers pointed out this important information:

If you look at the documentation for views_plugin_query_default::add_where_expression(), you will notice the following note. (The emphasis is mine.)

The caller is responsible for ensuring that all fields are fully qualified (TABLE.FIELD) and that the table already exists in the query. Internally the dbtng method "where" is used.

Batch runs on load balanced environments can give headaches

Tuomas reported this: 

[13:42] Tuomas: If you ever experience issues with batched exports on load balanced environments, this is useful
[13:42] Tuomas:
#These should be pointed to only one front.
if(req.url ~ "^/batch") {
set req.backend = web1;
}
else {
set req.backend = default_director;
}

Took a while to debug why not all items that should be on export aren't there. Seems some chunks got passed to different server and were not included in the export.

Note from Janne: An even better approach would be to use client director instead of round robin. That way you don't have to worry about forgetting some path, you still have loadbalanced stuff for all users, and it's even failsafe in that if the web1 goes awol it is still able to direct traffic to web2 instead.

 Date and views together 

Something tells me this one has struck many of us:

[11:51] Cristian:

Hi . Has anybody @here encountered this before ?

I have a field of type "date" which I use to collect date when a certain node was updated ( user inputs the data ) .

I want to create a view where I filter all those nodes which have not been updated in the past 3 months. The views filter does not recognize the field as a "date" field but rather as a test field.

Any ideas on what could be wrong ?
[11:51] Jim: is views date enabled @Cristian?
[11:52] Federico: u're missing views date
or date_views maybe?
yep the right module is date_views :)

[11:53] Cristian: I'll go sit in the corner now ... thanks guys
[11:53] Peeter: pshh.. someone take a pic of it.
[11:55] Miķelis: ahh, the good old drupal. solve any problem by adding a module. :)
[11:56] Federico: :p well sometimes brainfarts happen @Cristian :)
[11:56] Cristian: @Bernt , there's another gotcha for you
Weird error messages and crashing

I am pretty sure a lot of frontenders have been hitten by this one: A lot of core dumps with error messages that don’t really make any sense. 

After digging and digging you ask a colleague and he asks you if you’re using npm in your project? Ooh yes - and then you do realise that php-fpm core dumps because drupal didn't understand the info-files from npm-installed things, in it’s node_modules folders. 

Issue here: https://www.drupal.org/node/2329453

Thanks for reporting, Greg

Bonus: The problem that fixed itself

This is a nice WTF moment, when you spend a while fiddling with a module that doesn’t work right, you check the documentation, Google it a bit, maybe you even open up the debugger and step through the code to see what’s going on, you find the bug and then, only when you’ve even fixed the bug and are ready to create an issue and submit a patch you check the issue queue only to see that somebody beat you to it. 

A year ago. 

The moral to the story is of course to check the issue queue first, and check patches that don’t necessarily seem to be related. 

And if you know a module maintainer that have such lingering patches it doesn’t hurt to remind them over lunch.