I've created a custom block in Drupal 7, to display, in the upper right corner on every page, a menu that is context sensitive. Based on certain user attributes some functionalities are enabled or disabled. This block displays a list of available functionality to the user.

small example:

<li><a href="?q=node/add/article">write new article</a></li>
    if (og_is_member('node', 12, 'user')){
        print('<li><a href="?q=board">Board of directors</a></li>');         
        print('<li><a href="?q=admin/reports/pages">statistics</a></li>');
  global $user;

  // Check to see if $user has the administrator role.
  if (in_array('content_manager', array_values($user->roles))) {
            print('<li><a href="?q=comment_review">Manage comments</a></li>');
<a href="?q=user/logout">Log out</a></li>

I've noticed that when I make an SQL dump on the live site and put it on my laptop's local database for backup, this context sensitive menu is not there, while on the production site it displays just fine. first I thought I just had to readjust the visibility settings of this new block on the backup site. But when I visited admin/structure/blocks the block wasn't even there. So I figures something must have gone wrong with the sql dump. So I tried again, still no block in the list.
This new block's name is 'nav_menu_block', so I did a text search on the sql dump from the production site. Nothing.... So I googled a bit to find out where the data for custom blocks is stored. Found a few web pages stating this is stored in the table "block_custom". But when I go there with phpMyAdmin, this table is empty.

So now I have this problem: if I ever have to put the backup version up again it will not contain this new block, and who knows what else will be missing....

Can anyone PLEASE tell me where to find the data for this custom block with PHP code in the database?

many thanks

  • I know it will not immediately help you, but I strongly suggest turning off PHP filter entirely and switching to custom modules for tasks like this one. As you can already see, it'll save a lot of problems.
    – Mołot
    Feb 27, 2014 at 10:36
  • 1
    thanks Molot. I've found several pages stating this. I'll look into it for sure, but for a short-term solution I really need this fixed. :) Feb 27, 2014 at 10:54

3 Answers 3


Universal solution to find something you know is in the database is:

  1. Dump the entire database to SQL file.

    • No compression, or uncompress after downloading.

    • Use one row - one line format - disable "insert many rows in one INSERT statement" and similar options.

    • Also, disable anything that looks like "save BLOB columns in hex format" - you want serialised variables in human-readable form.

  2. Use grep or similar text search tool to search for the string parts you think characteristic enough to the row you need to find.

  • thank you Molot. I've dumped the DB like you suggested. Still nothing when I search for the content of the PHP in the custom block. But ... What is surprising that also some of the 'regular' articles and pages also cannot be found by searching for their content like that. Feb 27, 2014 at 12:39
  • @DirkVerdonck remember that SQL files have some characters escaped, and grep needs escaping, too. Searching for just "php" seems like good start if it gives not too much results. Otherwise - consider Clive's answer and part about storage backends. Is it possible it is not in database at all?
    – Mołot
    Feb 27, 2014 at 12:44
  • I've limited my search to strings with no specials characters in them, so nothing that needs escaping. Some articles I Can find, some I can't. (the ones I could find were in the table "field_data_body"). Feb 27, 2014 at 12:59
  • I've also searched the entire directory of my local backup of the webroot folder for significant phrases in the PHP code. Nothing..... Strange, huh? Feb 27, 2014 at 13:00

The body for custom blocks, regardless of the filter format used, is 100% definitely stored in the block_custom table, in the body field; I just tried it.

This be the proof (with a bit of sensitive info blacked out):

enter image description here

I would check the obvious things like

  • Make sure you're dumping the right database from the right server
  • Run Hacked to make sure all of your core/contrib modules are doing what they were written to do, and haven't been interfered with.
  • Clear the caches (not just db caches, any external caches like Memcache/Redis you might be using too)
  • Identify any enabled modules that might affect/alter storage backends. Methodically disable those, adding new blocks with PHP code each time, to determine if they are causing the issue.
  • thank you clive. I've double checked, but still the block_custom table is empty. And there is only one server and one DB on the 'live' side, so that's not the issue either. Feb 27, 2014 at 12:36
  • I've emptied the drupal cache, memcache and Redis I'm not familiar with so I don't think that's the problem Feb 27, 2014 at 12:37
  • 1
    Hmm, it's got to be one of the modules you have installed interfering then (or an amazingly bizarre server setup, which is unlikely). For sanity, install a blank version of Drupal, enable the php module, and add a block. If it's still not in the block_custom table, then quite simply your computers do things differently to mine when encountering Drupal :)
    – Clive
    Feb 27, 2014 at 12:39
  • Perhaps disable memcache in settings.php temporarily, just to be sure
    – Clive
    Feb 27, 2014 at 12:40
  • there is no reference to memcache in the settings.php file. Are we talking about the same file? I'm referring to mysite/sites/default/settings.php (this is probably a newbie question, my apologies :) ) Feb 27, 2014 at 13:13

strange: after three days of looking for the record it suddenly appears in the block_custom table, both in PHPMyAdmin table representation and in the SQL dump. I truly have no clue what happened. Anyway, I've made a good backup and migrated to a new database, now everything works fine.

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.