caveats

Run cron if you use the watchdog

It seems like a lot of people forget about this. Maybe because they don't know how to set up a cron. But if you use the watchdog, and you want to periodically discard your old log entries (admin/settings/error-reporting), you should also set up your cron.

If you don't know how to do this, read the Drupal cron documentation.

If you're using Drupal 6, you might consider using Acquia's Drupal distribution which enables cron by default from their servers.

And if you don't have access to set the cron on your server, Poormanscron is a great alternative.

Setting TinyMCE visibility for translatable content types that have names with spaces in Drupal

This is a little caveat for you in case you work with TinyMCE and the i18n module.

If you like to restrict the TinyMCE form to only appear on the node add and edit forms (node/add, node/edit/[id]), and you have spaces in your content type name, there's a slightly different drupal path 'behaviour' for the original node and the translated node.

The normal drupal path for adding nodes to drupal is node/add/[contenttype]. If the content type name contains spaces, the drupal path for adding a new node contains the content type name with spaces replaced by dashes. So you'll have something like node/add/blog-post if your content type is 'blog_post'.

That is only true for adding a new node that is not a translation of another node. If you say 'create translation' to add the translation for a node then the content type name in the drupal path hasn't spaces replaced by dashes but by underscores. So you'll have node/add/blog_post in our example.

Here is the code for the example 'blog post' content type. For completness' sake I have added the node edit case too.

<?php
if(arg(0) == 'node' && arg(1) == 'add' && (arg(2) == 'blog-post' || arg(2) == 'blog_post')) {
  return TRUE;
}
else if(arg(0) == 'node' && is_numeric(arg(1)) && arg(2) == 'edit') {
  $node = node_load(arg(1));
  if($node->type == 'blog_post') {
    return TRUE;
  } else {
    return FALSE;
  }
}
else {
  return FALSE;
}
?>

E-mail top level domain suffixes not incorporated in core e-mail validation function valid_email_address in Drupal

Using the Drupal core function valid_email_address($mail) doesn't cover all possible e-mail address syntax errors.

This function doesn't take the Top Level Domain in count. The explanation from the Drupal core developers is that they want to make e-mail addresses on a domain without a TLD, like root@localhost, valid.

So beware of this! This is spread all over the Drupal system. Even while registering on a Drupal website, you don't have to specify the TLD. So I think a lot of people will make the typo and register with an address like johndoe@hotmailcom and they will never receive their confirmation e-mail.

Case using for filenames of client side files when developing on LAMP

At this moment I'm integrating the HTML/CSS/JavaScript produced by a design bureau into a Drupal theme. And sometimes I was at the verge of pulling my hair out and calling names to the guy who created the images.

Please! If you know you're developing for Linux servers, check your use of letter cases! Or better... Just use dashes to seperate the words.

An example:

Suppose you have a filename you would like to call like 'BgCanvasLeftSpacesAndWhatever.jpg'. As soon as you mistype one letter (just the case), it won't work on a Linux/Apache server. But you wouldn't notice the difference if you just tested on your local OS X or Windows computer.

Spot the difference between 'BgCanvasleftSpacesAndWhatever.jpg'!!! Practically undoable.

If you would have used dashes, you would have spotted the difference immediately, because no Operating System or web server would allow you to drop the dashes.

So in the example you would have bg-canvas-lef-spaces-and-whatever.jpg.

And it looks better too ;)

Syndicate content