Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough

How not to delete Drupal variables in your module's uninstall function

Parent Feed: 

It’s considered “best practice”, if a module creates any variables, to delete those variables in the module’s uninstall function. Before Drupal 7, this was done in a call to db_query(). But with the “new” DBTNG (Drupal 7 Database API), using db_query() is no longer recommended. See the documentation for db_query():

Do not use this function for INSERT, UPDATE, or DELETE queries. Those should be handled via db_insert(), db_update() and db_delete() respectively.

However, browsing through (a relatively small set of) Drupal modules I have for my local Drupal 7 installations, I still see a number of modules which are using db_query to delete variables, typically something like this:

<?php
  db_query
("DELETE FROM {variable} WHERE name LIKE 'some_module_%'");
?>

Let’s rewrite this fictional module’s call to db_query() to instead use db_delete():

<?php
  db_delete
('variable')
    ->
condition('name', "some_module_%", "LIKE")
    ->
execute();
?>

But there is another problem with this code. Which is? That’s right… it uses a wildcard that might apply to another module’s variables. What if someone else writes a “some_module_extended”, “some_module_plus”, or “some_module_rethunk”*? Then our db_delete() function call will delete variables from those modules, too. This is not at all a stretch of the imagination with modules that provide an API or which are widely used and might get forked. So what is better practice? Well, of course if your code is aware of the names of all your variables, you could easily loop through an array to remove them. Or, if your module dynamically creates variables based on user input, you could store the names of these user-created variables in another variable, then do the looping. Or, of course, you could also create your own table to store your module’s “variables” and that table would automatically be dropped whenever your module is uninstalled.

Another point worth bearing in mind—I don’t see all modules taking care of this—is that when you delete variables it is good to also clear the variable cache. Only some of the modules which delete variables using db_delete() seem to remember this:

<?php
  cache_clear_all
('variables', 'cache_bootstrap');
?>

But the best practice is to use variable_del()

Of course you would be best off looping through all your variable names using variable_del(), which also automatically clears the variable cache. If you know the names of all your variables (or can store them as dynamic variables are created), this would most certainly be “best practice”. It will also remove the deleted variable from the global $conf array.

Updated:

To clarify and correct code, as suggested in comments, below.

* The former English (as a foreign language) trainer in me requires me to add the following caveat: 'thunk' is not a word in proper English (nor is 'rethunk'), but Oxford English Dictionary defines it: “informal or humorous past and past participle of think” : : who would've thunk it? (Just so's yah knows I ain't totally illegiterate. ;-) )

Original Post: 

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web