After disabling comment module, I could not access some modules, so I researched how to get that fixed and end up following this. I cleared all the cache_table, menu_router and registry_file.

This is the exact command I ran:

TRUNCATE `cache`;
TRUNCATE `cache_block`;
TRUNCATE `cache_bootstrap`;
TRUNCATE `cache_entity_og_membership`;
TRUNCATE `cache_entity_og_membership_type`;
TRUNCATE `cache_field`;
TRUNCATE `cache_filter`;
TRUNCATE `cache_form`;
TRUNCATE `cache_image`;
TRUNCATE `cache_libraries`;
TRUNCATE `cache_menu`;
TRUNCATE `cache_metatag`;
TRUNCATE `cache_page`;
TRUNCATE `cache_path`;
TRUNCATE `cache_token`;
TRUNCATE `cache_update`;
TRUNCATE `cache_variable`;
TRUNCATE `cache_views`;
TRUNCATE `cache_views_data`;
TRUNCATE `menu_router`;
TRUNCATE `registry_file`;

Now I have an empty site, I can't browse or go to anywhere. Even the front page Gives page not found error saying "/" not found.

I tried to rebuild the menu and registry with these commands but it didn't work.

define('DRUPAL_ROOT', getcwd());
require_once './includes/bootstrap.inc';


I tried with drush using drush cc all but it says

No Drupal site found, only 'drush' cache was cleared. but drush status shows it find the site

 Drupal version         :  7.23
 PHP executable         :  /usr/bin/php
 PHP configuration      :  /etc/php5/cli/php.ini
 PHP OS                 :  Linux
 Drush version          :  7.0-dev
 Drush temp directory   :  /tmp
 Drush configuration    :
 Drush alias files      :
 Drupal root            :  /path/to/site/root

What can I do? How to get the site back after this?

  • Restore from the backup you took before you decided to modify the database.
    – dxc
    Commented Jun 6, 2014 at 5:29
  • @enzipher, I want to fix this.
    – mrN
    Commented Jun 6, 2014 at 6:21
  • Can you run /update.php ?
    – dxc
    Commented Jun 6, 2014 at 6:43
  • @enzipher, Yeah tried that also. Nothing happened.
    – mrN
    Commented Jun 6, 2014 at 7:05
  • 1
    @Mołot, I think I know how the SE community works. SE demands to show what you have tried and what didn't work. That is what I have done. I ran into a problem and thus am asking a question about it.
    – mrN
    Commented Jun 6, 2014 at 9:49

2 Answers 2


Best thing is to restore it from a backup to make it work.

If you want to fix it, replicate the site from a back up (db and files). Then truncate tables one by one to see which one is causing the problem (It should be menu_router).

Truncate first all cache table and check Truncate menu_router and check Truncate registry_file and check.

About the code you did, try to remove registry_rebuild from your code. Create a file fix.php and paste this code

define('DRUPAL_ROOT', getcwd());
require_once './includes/bootstrap.inc';


save it into your drupal root and visit mysite.com/fix.php .

  • I already tried this, the admin menu is missing and lots of other modules giving blank screen.
    – mrN
    Commented Jun 6, 2014 at 9:47
  • Have you tried to replicate the site from a working backup and see which is the faulty table? Commented Jun 6, 2014 at 9:48
  • Yes it is menu_router Restoring that from the db gives me a working site but without admin menu and many modules like views not behaving properly.
    – mrN
    Commented Jun 6, 2014 at 9:50
  • Have you tried to use registry_rebuild after you rebuild menu_router? Commented Jun 6, 2014 at 9:55
  • Nope. I tried to rebuild menu though.
    – mrN
    Commented Jun 6, 2014 at 10:20

I assume you've got no backup from before you messed up the site, so that the obvious solution - using your favourite SQL management tool (e.g. phpMyAdmin or the CLI SQL program) to restore from backup - is not an option?

  • Create a backup now (using whatever database management tool you have).

  • Create a clean install of the Drupal core.

  • Look at your new nice and shiny database, print out the schema (a list of the tables it now contains).

  • Roll back from the backup all the tables that exists in this schema, except the following (all of these may not even exist in your backup):

    • {accesslog} – access log generated by statistics module (disabled by default);
    • {batch} – connects a user to his/her batch (a crashed site has no active users);
    • {cache*} – the cache just optimises page loads, always safe to truncate;
    • {flood} – flood log generated by built-in flood control;
    • {registry_file} - code registry, rebuilt when cache is cleared;
    • {search*} – loses search indices and statistics, indices is regenerated by cron;
    • {sessions} – loses user session (a crashed site has no active users);
    • {syslog} – system events log generated by syslog module (disabled by default);
    • {watchdog} – loses log messages.
  • Note that list above is always safe to exclude from rollbacks. They only contain ephemeral data, and may contain bad data if a site has crashed. There is a comment after each, explaining what it is used for.

  • Also roll back all tables starting with field.

  • Install all the contributed and custom modules you absolutely need, but skip those you suspect make trouble.

  • Roll back from the backup all the tables that belongs to these modules, module by module. You can see what table a belongs to because the table name always starts with the module's machine name. Check that your site is healthy after each round of rollbacks.

Usually, this gives you back a working site, with no contents lost.

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.