fatal error on ddev restart due to class_implements()

[jenlampton]

I restarted ddev today and got a fatal from entity_plus:

TypeError: in_array(): Argument #2 ($haystack) must be of type array, bool given in in_array() (line 280 of /var/www/html/docroot/modules/contrib/entity_plus/entity_plus.module).

Line 80 was as follows:

if (is_array($result) && isset($info['controller class']) && in_array('EntityPlusControllerInterface', class_implements($info['controller class']))) {

But class_implements() can return a result that's not an array. I cahnged it as follows:

    $result = class_implements($info['controller class']);
    if (is_array($result) && isset($info['controller class']) && in_array('EntityPlusControllerInterface', $result)) {

I expect we should use a better name than $result but I don't know what that value is supposed to be, I just fixed my code :)

[argiepiano]

But class_implements() can return a result that's not an array.

class_implements always returns an array if the class exists - otherwise it returns FALSE. See https://www.php.net/manual/en/function.class-implements.php

So, this error is likely the result of either faulty code (e.g. faulty implementation of hook_autoload_info, or incorrect class load info), or a problem with this function being called before _backdrop_bootstrap_database() is called (which is the most likely problem).

A defensive-coding measure like the one you mentioned may help you avoid this error and bootstrap the site; probably you can remove that after the cache has been rebuilt. But this should not be needed under normal circumstances, unless there is some issue like the one I described above.

[jenlampton]

class_implements always returns an array if the class exists - otherwise it returns FALSE. See

I'm pretty sure this is the problem. Sometimes it returns FALSE but the code in this module assumes it is never FALSE, always an array, and new versions of PHP don't like that.

I'm thinking that if PHP itself thinks FALSE is an acceptable return value, the module should too.

I agree that this is almost always caused because of incorrect class load info, but this is the second time I've upgraded a module from Drupal 7 that ended up using the EntityAPIController class because it doesn't provide any classes of its own. I think that existed in Drupal 7's Entity API module, so I would imagine it's not uncommon.

That's a problem of its own - but it immediately shows a brittleness with this module I'd prefer people didn't find :)