caveats

PHP filter and search index woes

PHP filter is a great filter. It gives you a lot of flexibility. But it has a lot of disadvantages too. One of them is that it makes your code harder to debug.

One of those hard debug sessions occurred lately when the following happened. Cron always stopped running when it was going to index this one node. It also redirected to some page. Weird.

What was happening? The node was a page. The body was having the PHP filter on and the following code was in that body:

<?php drupal_goto("node/add/story"); ?>

What does this have to do with search indexing you ask? Well, when the search indexer is going to index a node, it first runs all filters on your body, and it's the result of that that is getting indexed. So if you're writing PHP code, that code is run when the indexer comes along. Even "non-text generating" code, like the redirect in this case.

Written on April 23, 2009 at 11:56, tagged as caveats, Drupal, PHP, PHP filter, search

Deleting Drupal variable directly in the database

This is just a quick caveat (or reminder). If you delete a variable from the variables table, always clear the cached entry of the variables too. Drupal caches the whole variables table in the cache table in an entry called 'variables'.

Here are two cases (of the many) you'll need this.

When you're writing your own module and you're setting some variables, always clean them up. Fastest way is by issuing a direct query to the database.

/**
 * Implementation of hook_uninstall().
 */
function my_module_uninstall() {
  db_query("DELETE FROM {variable} WHERE name LIKE 'my_module_%'");
  cache_clear_all('variables', 'cache');
}

A second typical case I can come up with is when releasing the cron semaphore after it got 'stuck'.

DELETE FROM variable WHERE name = 'cron_semaphore';
DELETE FROM cache WHERE cid = 'variables';
Written on November 05, 2008 at 07:49, tagged as caveats, Drupal, module development

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.

Written on October 15, 2008 at 22:29, tagged as caveats, cron, error reporting, logs, watchdog

Importing a UTF-8 database and keep special characters

This is a follow up to the post "Creating a UTF-8 database to work with special characters".

When you want to move your database from one server/database to another one, you generally create a sql dump file from the source database using the mysqldump command and then do an import into the destination using the mysql source statement or via shell redirection (<).

This is just a heads up. When you make the connection on the destination server/database, specify the --default-character-set=utf8 option.

You end up with something like:

mysql -u user -ppassword --default-character-set=utf8 database < "dump.sql"
Written on April 29, 2008 at 06:30, tagged as caveats, Drupal, i18n, MySQL

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;
}
?>
Written on February 07, 2008 at 19:15, tagged as caveats, Drupal, i18n, modules, TinyMCE

About

drupalcoder.com is a blog on all things Drupal in specific and LAMP on OS X in general. It is maintained by Davy Van Den Bremt, a Belgian (Drupal) web developer and designer living in Ghent. The goal of this blog is to log all interesting things that have crossed the writer's path while developing Drupal sites. You can read all about Davy's professional activities on his LinkedIn profile. If you want to get in touch, use the contact form.