Class name must be a valid object in common.inc after removing a duplicate module

Created on 10 May 2014, over 10 years ago
Updated 3 June 2024, 7 months ago

Problem/Motivation

Received "Fatal error: Class name must be a valid object or a string in /mampstack/apps/drupnpx/htdocs/includes/common.inc"

This occurred when I had found a duplicate module and removed it (it was in a profile and in sites/all/modules). This affected the system table, and that affected everything.
Stacktrace:

PHP Fatal error:  Class name must be a valid object or a string in /htdocs/includes/common.inc on line 7837
PHP Stack trace:
1. {main}() /htdocs/index.php:0
2. drupal_bootstrap($phase = 7, $new_phase = *uninitialized*) /htdocs/index.php:20
3. _drupal_bootstrap_full() /htdocs/includes/bootstrap.inc:2260
4. drupal_path_initialize() /htdocs/includes/common.inc:5144
5. drupal_get_normal_path($path = 'user/1', $path_language = *uninitialized*) /htdocs/includes/path.inc:21
6. subpathauto_url_inbound_alter($path = 'user/1', $original_path = 'user/1', $language = NULL) /htdocs/includes/path.inc:272
7. menu_get_item($path = 'user/1', $router_item = *uninitialized*) /htdocs/sites/all/modules/subpathauto/subpathauto.module:25
8. _menu_translate($router_item = array ('path' => 'user/%', 'load_functions' => 'a:1:{i:1;s:9:"user_load";}', 'to_arg_functions' => '', 'access_callback' => 'user_view_access', 'access_arguments' => 'a:1:{i:0;i:1;}', 'page_callback' => 'page_manager_user_view_page', 'page_arguments' => 'a:1:{i:0;i:1;}', 'delivery_callback' => '', 'fit' => '2', 'number_parts' => '2', 'context' => '0', 'tab_parent' => '', 'tab_root' => 'user/%', 'title' => 'My account', 'title_callback' => 'user_page_title', 'title_arguments' => 'a:1:{i:0;i:1;}', 'theme_callback' => '', 'theme_arguments' => 'a:0:{}', 'type' => '6', 'description' => '', 'position' => '', 'weight' => '0', 'include_file' => 'profiles/panopoly/modules/contrib/ctools/page_manager/plugins/tasks/user_view.inc'), $map = array (0 => 'user', 1 => '1'), $to_arg = *uninitialized*) /htdocs/includes/menu.inc:472
9. _menu_load_objects($item = array ('path' => 'user/%', 'load_functions' => 'a:1:{i:1;s:9:"user_load";}', 'to_arg_functions' => '', 'access_callback' => 'user_view_access', 'access_arguments' => 'a:1:{i:0;i:1;}', 'page_callback' => 'page_manager_user_view_page', 'page_arguments' => 'a:1:{i:0;i:1;}', 'delivery_callback' => '', 'fit' => '2', 'number_parts' => '2', 'context' => '0', 'tab_parent' => '', 'tab_root' => 'user/%', 'title' => 'My account', 'title_callback' => 'user_page_title', 'title_arguments' => 'a:1:{i:0;i:1;}', 'theme_callback' => '', 'theme_arguments' => 'a:0:{}', 'type' => '6', 'description' => '', 'position' => '', 'weight' => '0', 'include_file' => 'profiles/panopoly/modules/contrib/ctools/page_manager/plugins/tasks/user_view.inc'), $map = array (0 => 'user', 1 => '1')) /htdocs/includes/menu.inc:761
PHP  10. user_load($uid = '1', $reset = *uninitialized*) /htdocs/includes/menu.inc:593
PHP  11. user_load_multiple($uids = array (0 => '1'), $conditions = array (), $reset = FALSE) /htdocs/modules/user/user.module:366
PHP  12. entity_load($entity_type = 'user', $ids = array (0 => '1'), $conditions = array (), $reset = FALSE) /htdocs/modules/user/user.module:291
PHP  13. entity_get_controller($entity_type = 'user') /htdocs/includes/common.inc:7804

((line numbers may be off due to debugging code))

Proposed resolution

I believe this is related to a pervasive bug as reported against many modules (more than 50 issues that I can see). While several of those issues have been closed, they may have been closed only because the bug could not be tracked down. The issue still is apparent.

This issue is, admittedly, a tough one to find. I have tracked down the actual cause, but the intricacies of the cache are a bit beyond me.

Clearing the cache could help here. Sadly, you can't always get there, largely because drush cc will also blow up when this error is occurring. So will anything having to do with accessing a user (in my case). . Requiring a user to clear the cache every time this occurs is improper by its nature - you can't have a user do a workaround as a normal course of business.

This is the tip of the iceberg on this problem. (the PHP Fatal error: Class name must be a valid object or a string in /includes/common.inc on line 7522).

[[[[in 7.28, at line 7855, 6 = ]]]]

    $class = $type_info['controller class'];
    $controllers[$entity_type] = new $class($entity_type);

The symptom appears because the search for the element ['controller class'] is presumed to be successful. It is not, and no secondary message (such as in a try / catch or an actual test here) is generated.

The issue stems from, for whatever reason, not being able to obtain a $class value from the $type_info array by executing module_invoke_all('entity_info'). Certainly a call time pass by reference could do it, but that would normally be caught. The actual problem is in /includes/common.inc at 7644.

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

Notice that if the $cache condition is true then the module_invoke_all('entity_info') is never executed.

It just happens that the condition is always met after some other processing is done to create the cache. That means that there is no way to get the entity_info set up --- in my case there was no way to obtain the 'user' entity info, causing the original error above. I made the 'else' one level higher (took out the 'else {}') for testing, and everything worked as it should to clear the error.

I believe that the real bug is that the checking of cache is less than adequate, and that a check on the existence of the entity_info about the specific entity being searched for is needed. In fact, it may be justifiable to also search for the element ['controller class'] for that entity in the entity_info stored in cache.

I'd be happy to suggest changes, but I am not clear on process for making changes to core.

πŸ’¬ Support request
Status

Closed: works as designed

Version

7.0 ⚰️

Component
EntityΒ  β†’

Last updated about 17 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States dvandusen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΈπŸ‡°Slovakia poker10

    We just committed better error handling in a case the class is missing here #1982810: Core entity_get_controller gets a NULL controller class β†’ .

    I think we can close this support request as it was most probably caused by removing the enabled module which is not a good idea. Generally, this error is mostly caused by missing files or errors in contrib modules / custom code. You can look at the documentation of hook_entity_info to see that the there is already a fallback in case the controller class is not set - it defaults to DrupalDefaultEntityController. Checking if the given class really exists is not something Drupal core should do (it tends to not babysit broken code).

    If you think this is still an issue for D7 core, feel free to reopen, but we would need a steps to reproduce this (without any non-standard actions). Thanks everyone!

Production build 0.71.5 2024