I got a WSOD and was trying to figure out why and how to solve it.

After researching I discovered that I got a WSOD because some module (module unknown, but is related to date+calendar modules) was not properly defining the entity type.

Before I can even address the problematic module, I needed to first deal with the WSOD.

The WSOD happens because the entity code is expecting a class object and got something else.
My patch solves this by providing DrupalDefaultEntityController when no valid entity class object is found.

This is a feature request to deal with the WSOD so that invalid/improper uses of entity api can be handled more gracefully, even if this gracefullness does nothing more than throw an error such as:

Recoverable fatal error: Argument 2 passed to SelectQuery::fields() must be an array, null given, called in /var/www/html/includes/entity.inc on line 284 and defined in SelectQuery->fields() (line 1300 of /var/www/html/includes/database/select.inc).

This directly relates to #1042822: Developers need an $entity->entity_type property.
Until the above issue is resolved, I suggest applying this patch (or something similar).

CommentFileSizeAuthor
drupal-7.x-graceful_entity_failure-1.patch578 bytesthekevinday

Comments

Jooblay.net’s picture

Jooblay.net commented
Priority: Major » Normal

What is the status of this issue?

thekevinday’s picture

thekevinday commented

The referenced issue looks like it has a long way to go before developers can settle on a decision on how to solve the problem.
The WSOD still happens without the above patch.

Perhaps the patch can be used to use class_exists() instead of simply empty().
That might handle more cases.

What I don't know about is if the DrupalDefaultEntityController should be returned as a fallback or if some error page, that is more graceful than a WSOD, should be presented.

While I was wondering about that, I also noticed that the documentation for entity_get_info() is missing the @return part.
Whether or not DrupalDefaultEntityController is returned as a fallback should depend on what the expected return value for entity_get_info() should be.

The following is from the documentation at http://api.drupal.org/api/drupal/modules%21system%21system.api.php/funct... :

  controller class: The name of the class that is used to load the objects. The class has to implement the DrupalEntityControllerInterface interface. Leave blank to use the DrupalDefaultEntityController implementation.

This seems to support the idea of returning DrupalDefaultEntityController as the default on invalid class.
Maybe a watchdog error should be printed here at the very least.

Jooblay.net’s picture

Jooblay.net commented

I would say due to the lack of activity on this issue it would seem to be a configuration problem. How can we reproduce this issue. ?

chrisrockwell’s picture

chrisrockwell commented
Issue summary: View changes
Status: Active » Closed (duplicate)

Cleaning up - several issues for this, consolidating to #1158114: SelectQuery::fields() must be an array, null given entity.inc on line 284 SelectQuery->fields() (line 1262 select.inc.