I was working on a site this morning, and I enabled a whole bunch of modules at the same time. One of the modules threw a PDO exception during the process.

What state is the site in at this point? Assuming the site still loads after the error, is it safe to use, or should I restore from a backup?

For the sake of this question, I am not concerned about the actual error or the module that threw the error (I would report this in the issue queue). I am concerned about the general state of the site, and what may have happened to the installations of the other modules.

To make this more concrete, let's say I tried to enable ModuleA, ModuleB, ModuleC, and ModuleD. After I clicked SUBMIT on the module page, ModuleC threw an uncaught PDO Exception and I didn't get the normal module enabled message. Now, lets say that I can live without ModuleC on the site. What can be said about the state of hpw the installation went for ModuleA, ModuleB, and ModuleD, and also dor Drupal in general?

  • 1
    It totally depends - what was the specific error message? What module were you installing?
    – Clive
    Nov 7, 2013 at 16:34
  • @Clive I am thinking more in the general sense, but related to a real world problem. In my case, it was easy enough to restore a backup. I'll edit with some more detail later.
    – mpdonadio
    Nov 7, 2013 at 16:40
  • I think it'll be hard to answer that generally - the module might matter less, but a PDOException can be thrown for so many different things - an invalid query string, a temporary (or permanent) network failure, a full hard disk, messed up MySQL or server conf, a goat gnawing on the corner of the machine (not totally sure about the last one). I guess even knowing the 'genre' of the exception would be useful
    – Clive
    Nov 7, 2013 at 16:47
  • I will uninstall the modules one by one, if i don't know about the error and that will fix the error mostly and it is safe. suppose if the site is completely dead, then i will restore the backup. it depends on the state. and it looks off topic or too broad here, i don't know why @Clive not mentioned this.
    – Bala
    Nov 7, 2013 at 17:58
  • I tried to clarify this a bit. The question isn't about the module that caused the error, it's about everything else.
    – mpdonadio
    Nov 7, 2013 at 18:52

1 Answer 1


Generally, it isn't. It may be, but it depends what's in module's hook_install.

First, most modules provide schema. The code of drupal_install_schema in 7 is currently:

function drupal_install_schema($module) {
  $schema = drupal_get_schema_unprocessed($module);
  _drupal_schema_initialize($schema, $module, FALSE);

  foreach ($schema as $name => $table) {
    db_create_table($name, $table);

As you can see, no call to db_translation, and each table is created one at a time. Now, if module only provides own schema, you are left with some garbage in database, but it's a well isolated garbage. But if it implements hook_schema_alter it's pretty possible you are left with some tables already altered, bu no code to handle these alterations. Now, in theory installing schema should never fail with PDO error, but due to RDBMS configuration for example, it may happen.

Second problem is that module's author can write pretty much anything in it's install code, and you are not guaranteed it will get rolled back at failed install. If he decides his module needs to change variables provided by core or other modules (for example to allow apparent conditional content, like with translated variables), or if it redefines some fields to provide additional functionality, you may end up with some of your data converted to module's format, and no longer accessible without it, or without running code meant to uninstall it.

Note: Situations above from experience. Even if I miss some theoretical part that should make them impossible to happen, they both did happened to me in real life. With -dev versions, but module version depends solely on it's author, so there is no guarantee that it will not happen in stable versions some day, too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.