PHP Fatal error: Class name must be a valid object or a string in drupal-7.14/includes/common.inc on line 7680

I am getting this same error, but not sure how to get around it. I currently cannot run Drush because that error comes up each time.

It keeps tripping on my custom entity, claiming it can't see its controller class. However, dumping entity_get_info() elsewhere shows that it in fact has one. Why then, does this fail?

/**
 * Get the entity controller class for an entity type.
 */
function entity_get_controller($entity_type) {
  $controllers = &drupal_static(__FUNCTION__, array());
  if (!isset($controllers[$entity_type])) {
    $type_info = entity_get_info($entity_type);
    $class = $type_info['controller class'];
    $controllers[$entity_type] = new $class($entity_type);
  }
  return $controllers[$entity_type];
}

Now it stops on NodeController.

Just for kicks, I added a ternary to prevent $class from being '' or null:

$class = isset($type_info['controller class']) ? $type_info['controller class'] : 'DrupalDefaultEntityController';

Which then results (drush cc all) in:

WD php: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server[error]
version for the right syntax to use near 'IN  ('1560'))' at line 2: SELECT base.*
FROM 
{} base
WHERE  (base. IN  (:db_condition_placeholder_0)) ; Array
(
    [:db_condition_placeholder_0] => 1560
)
 in DrupalDefaultEntityController->load() (line 196 of /data/disk/o1/static/drupal/includes/entity.inc).
Drush command terminated abnormally due to an unrecoverable error.                                                                                                          [error]
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'IN  ('1560'))' at line 2: SELECT base.*
FROM 
{} base
WHERE  (base. IN  (:db_condition_placeholder_0)) ; Array
(
    [:db_condition_placeholder_0] => 1560
)
 in DrupalDefaultEntityController->load() (line 196 of /data/disk/o1/static/drupal/includes/entity.inc).

I assume 1560 is a node ID, which would be my frontpage.. This is about as far as I have gotten with this error in 3 hours and really do not know where else to look. I am kind of crippled.

How in the world do you fix this?

I mean it was fine until I updated these modules on Sunday:

• AddressField
• Context
• Delta
• Entity
• Geocoder
• GeoField
• Pathauto
• SearchAPI
• SearchAPISolr
• Token
• Omega (theme)

How can you even pin down where the problem is?

It looks like a Context with a PHP condition that uses arg(1) to run a load with the module loader function and not entity_load.

I have changed the code, but cannot clear the cache still to get rid of this. I truncated the cache* tables and it still persists. Is there a Drush cache or something? I have removed the PHP AND disabled the context.

Wow, this was a hard one to clear. Once this is up and stuck in the cache, it was very difficult to remove it. I called drupal_static_reset inside a PHP script, causing a segfault (yep), came back and drush cc all one more time- that time it worked. Thank you for your help.

What is the proper protection to keep this from happening?

It was a Context PHP condition set by a dev, like a block you put PHP code in. It was checking to see if it was on a particular entity detail page, by loading the object with arg(1) (similar to checking for $node with node_load(arg(1)).

I didn't- it was custom code in that condition that I removed.

Was using entity_class_load(arg(1)) and I replaced it with entity_load('my_entity', arg(1))- which cleared it up, seemingly.

I thought this was a somewhat accepted way of checking if you can load an object on a particular page. I suppose not for custom entities?

I was getting a similar error when I copied my site over to a new server. After running update.php, it sorted itself out though there were no database updates to run. Weird!

I am seeing the same error on a different line when I try to use entity_save() or entity_delete()

Fatal error: Class name must be a valid object or a string in /drupal-7.14/includes/common.inc on line 7656

Here are some examples that will cause the error:

$entity = entity_load_single('node', 100);
entity_save('node', $entity);

entity_delete('user', 4);

My bad: this was caused by menu callback function conflicts with hook_delete and hook_update.

See: #1694428: U and D in CRUD need working callbacks in Entity JS

I was having the same issue as @Kristen Pol and running drush updb && drush cc all cleared it up.

I can also confirm this still happens under certain circumstances. The drush updb and cc all afterwards cleared it up.

The only thing that was done prior to fatal wsod, was a feature was enabled that had to use the same field on two content types. This is the only thing we hypothesize that was the underlying problem.

I experienced this issue today. Solved by stopping memcached, restarting apache, truncating cache tables.
Site comes back; start memcached, restart apache.

The most common cause I found was with things like Solr and Memcache. If you delete an entity and those caching systems are not updated (through proper API usage, entity_delete etc), attempting to load an entity id that no longer exists causes some nasty problems.

Here is what happend for me;

Custom block snippet before:

function _jumbotron_block_data() {
    $entity_type = arg(0);
    $entity_id   = (array) arg(1);
    $entity      = (array) entity_load($entity_type, $entity_id);
    
    return entity_view($entity_type, $entity, 'jumbotron');
}

The block that used above was displayed on all pages. The problem with that is that when you visited an 404 OR 403 like /admin/ when not being logged in, or any other strange page. I had custom 404 and 403 pages, something like /woops/404. With above code the $entity_type would be woops. Which of course is not right.

Correct code

function _jumbotron_block_data() {
    $entity_type = arg(0);
    $entity_info = entity_get_info($entity_type);
    
    if (! $entity_info) {
        return;
    }
    
    $entity_id   = (array) arg(1);
    $entity      = (array) entity_load($entity_type, $entity_id);
    
    return entity_view($entity_type, $entity, 'jumbotron');
}

One of our developers ran into this issue as well. Although he's running a different version (7.22), this may help -

Like @kepford mentioned, if drush updb and drush cc all doesn't work, try truncating your cache_* tables first.

I run into this problem intermittently, usually because I've done something stupud. I can't promise that's not the case in this instance, but something weird is definitely going on and I am able to reproduce it.

Environment:
Drupal 7.28
PHP 5.3.10-1ubuntu3.11
PostgreSQL 9.1.13

It started when I disabled the Devel module, but this seems to happen across many modules.
First, an error kicked off from the termstatus contrib module, user_access() is undefined (warning sign). I wasn't using that module so I moved it and then this error reared its ugly head.

PHP Fatal error: Class name must be a valid object or a string in /includes/common.inc on line 7853

Ran through the regular gambit (truncate the tables, clear the browser cache, even did the drush updb and drush cc all, mentioned above. Nothing worked.

Had to dive into the code to figure out what was going on:
I won't paste the entire backtrace because it's painful, but it was definitely failing to load the user entity info.
common.inc
entity_load >
entity_load_controller >
entity_get_info >

    // had to disable caching to debug
    if (false && $cache = cache_get("entity_info:$langcode")) { 
      $entity_info = $cache->data;
    }
    else {    
      var_dump(module_list()); // USER MODULE IS LISTED
      var_dump(module_implements('entity_info')); 
/*
      Array
(
    [0] => comment
    [1] => eck
    [2] => node
    [3] => system
    [4] => taxonomy
    // USER IS MISSING (!)
)
*/
      var_dump(function_exists('user_entity_info')); // 
/*
bool(false) // (!)
*/
     $entity_info = module_invoke_all('entity_info'); //@7652
      ...

Adding the following test code which seemed to correct the issue (this is core so not a solution).

      // leave caching disabled
      require_once(drupal_get_path('module', 'user') . '/user.module');      
      module_implements('entity_info', false, true);
      
      $entity_info = module_invoke_all('entity_info'); //@7652

Was able to login now.
I removed all test code from common.inc and flushed the cache, problem comes back!

The solution I settled on was adding these 2 lines to the top of my custom module which apparently is loaded early enough to catch this issue. Not ideal, but it works.
Maybe my experience will save others some time.
Fun stuff.

Word to the wise and not so wise.

I started to notice additional system instabilities with other core and contributed modules with similar entity-info errors. After much deliberation, I found the cause was some custom-module initilization logic written inline instead of inside a hook_init function. When flushing the cache, this logic was calling drupal core functions before all modules were loaded or finished loading, leading to a variety of unexpected behavior (particularly with modules loaded late like wysiwyg).

Hope this helps someone.

I managed to solve this problem with few steps below.

First step: go to common.inc in includes folder
find the function "function entity_get_info($entity_type = NULL)"

change the line if ($cache = cache_get("entity_info:$langcode")) to if (false && $cache = cache_get("entity_info:$langcode"))
Now this cache is disabled.

next step:

Add the following 3 lines in the else statement above the "module_invoke_all function", so that the whole chunk becomes like below

if (empty($entity_info)) {
if (false && $cache = cache_get("entity_info:$langcode")) {
$entity_info = $cache->data;
}
else {

var_dump(module_list()); // Add this new line
var_dump(module_implements('entity_info')); // Add this new line
var_dump(function_exists('user_entity_info'));// Add this new line

$entity_info = module_invoke_all('entity_info');

Now you will be able to load the page and log in to the admin panel.

Login and Clear the Cache.

You are good to go. It should work like it did for me.

Once you have done the above, revert all the changes.

Thanks,

For me this was due to PHP version differences (i.e. between 5.3.10 and 5.3.29) where (string) $object (on an object implementing no __toString() method) generated the "Recoverable fatal error" running 5.3.10 and no error running 5.3.29. Keeping such an object from being cast as string was the bug to fix in my custom code. Similar casts of objects to string with certain version of PHP (I don't know which) may be the cause of the different cases above.

For me, this fixed it, by doing it on mysql

TRUNCATE TABLE cache;

I added code on a module file at the wrong location (it executed as part of the file and then I called die.

After clearing chace from the DB it worked for me.

For me, this fixed it, by doing it on mysql

TRUNCATE TABLE cache;

I added code on a module file at the wrong location (it executed as part of the file and then I called die.

After clearing chace from the DB it worked for me.

#27 worked for me.

Thank you!

I had to run updatedb, clear Drupal cache, and then clear memcache to fix this. Thanks @prdctvtxt

I cleared table cache , memcache cache and solr too but still error not resolved .
It comes when I make solr search in search result page. This is what I get in logs

Error: Class name must be a valid object or a string in entity_get_controller() (line 7998

Someone please help me.

Just created a new Solr instance and it worked.

This one should work:

drush sql-query "DELETE FROM cache_bootstrap"
drush sql-query "DELETE FROM cache"
drush php-eval "entity_info_cache_clear();"

That worked for me. Thanks!

Thanks @rosrokine

#34 worked for me.

Just leaving this for others who run into this problem:

drush @sitename.env --fire-bazooka --strict=0

Seriously. This forces an aggressive rebuild of the registry (multiple passes, multiple cache clears) and pretty much clears out all the cockroaches. As documented, you should back up the DB first.

I tried all of the above but nothing worked. Looking at the backtrace the error for me originated from menu.inc.

I put return NULL; as the first line of menu_local_actions() and menu_local_tabs().

I then did a registry rebuild (drush rr) and cleared the cache (drush cc all), and then removed those lines again.

After that is was all fine... hope this might help someone else.

The attached patch fixes this issue. There is also a core-level fix proposed in #1982810: Core entity_get_controller gets a NULL controller class.

Awesome #34.

Hi,
#34 worked for me, thanks

If you are facing a similar problem I would suggest to backtrace the error by temporarily hacking the common.inc file with this:

function entity_get_controller($entity_type) {
  $controllers = &drupal_static(__FUNCTION__, array());
  if (!isset($controllers[$entity_type])) {
    $type_info = entity_get_info($entity_type);
    $class = $type_info['controller class'];
    if ($class == NULL){
      variable_set('error_level');
      echo(ddebug_backtrace());
      die();
    }
    $controllers[$entity_type] = new $class($entity_type);
  }
  return $controllers[$entity_type];
}

Module devel required of course. That is how I've found the code that was giving problem and corrected the error.
It was simply due to a entity_load on a null entity type that happened on a particular situation.

I can vouch for #34, too. Thanks for that! I thought I was going to be in for a long day... (Might still be, it's early.)

I installed the module "modules_weight" and positioned my custom module as last (100). Saved, cleared the cache, and gone was the error. My custom module uses cache_clear_all() so probably that was the problem.

HI,

#39 This patch worked for me. thanks

#39 patch worked!
Thanks.

Since it is working for you, you could mark it "reviewed and tested by community".

I apply the patch and tested an working good for me, but need apply the following patch for working https://www.drupal.org/files/issues/drupal-entity_get_controller_null_co... in drupal core

updated the issue for tested, but without this patch in core, probably dont working

This should probably have tests added to it, too, correct?

#34 and the patch from #48 cleared up the issue for me. This was preventing me from being able to migrate and upgrade websites on Aegir.

#34 the patch return the following error:
"error: corrupt patch at line 44"

#34 worked for me with php 7.2.1
btw #34 is not a patch, just some drush commands.

Following works for me

UPDATE system SET status='0' WHERE name='module_name';
DELETE FROM cache_bootstrap WHERE cid='system_list';

TRUNCATE TABLE cache;
TRUNCATE TABLE cache_admin_menu;
TRUNCATE TABLE cache_block;
TRUNCATE TABLE cache_bootstrap;
TRUNCATE TABLE cache_features;
TRUNCATE TABLE cache_field;
TRUNCATE TABLE cache_filter;
TRUNCATE TABLE cache_form;
TRUNCATE TABLE cache_image;
TRUNCATE TABLE cache_libraries;
TRUNCATE TABLE cache_menu;
TRUNCATE TABLE cache_page;
TRUNCATE TABLE cache_path;
TRUNCATE TABLE cache_rules;
TRUNCATE TABLE cache_token;
TRUNCATE TABLE cache_update;
TRUNCATE TABLE cache_views;
TRUNCATE TABLE cache_views_data;

Thanks

#28 works for me, thank you.

Have put the long array between the code tags as otherwise it's impossible to read.

Updated to MR as patch was not applying because of comment.

This suggested change looks like a reasonable improvement to me.

#34 has an extra comment update which I think is important. The merge request does not have that.

I'd say go with #34 for the win