As reported at #1306198-26: Fatal error: Class name must be a valid object or a string on line 137 of adapter.inc, sometimes the url processor plugins are not registered when needed depending on whether CTools or Facet API is heavier. It is unclear as to why this is happening, so this thread is a call to action for people to help debug.

CommentFileSizeAuthor
#5 facetapi-missing-plugin-5.patch1.98 KBboznik
#4 facetapi-missing-plugin-4.patch1.62 KBsherakama
#3 facetapi-missing-plugin-1816110-3.patch1.28 KBsherakama

Comments

tjmoyer’s picture

tjmoyer commented

This happend to me, too, right after I had reindexed all content in Apache Solr. But once I cleared cache, it resolved itself.

acbramley’s picture

acbramley commented

This happened to me after upgrading facetapi from an old version to the latest stable. I deployed the new code up to our testing platform and have been getting this error sporadically.

Edit: Just to note, I have cleared cache multiple times through drush, bouncing varnish, and truncating db tables, along with resaving the facet settings etc
Edit 2: Seems like it may have been an issue with my feature export, I was missing the facetapi:facetapi:1 ctools component. You need this as well as the facetapi:facetapi_defaults:1 component

sherakama’s picture

sherakama commented
Issue summary: View changes
StatusFileSize
new facetapi-missing-plugin-1816110-3.patch1.28 KB

I'm getting a similar issue on a different part of the module. Included is a patch to prevent a WSOD. Some more debugging is needed.

sherakama’s picture

sherakama commented
StatusFileSize
new facetapi-missing-plugin-4.patch1.62 KB

New patch...

boznik’s picture

boznik commented
StatusFileSize
new facetapi-missing-plugin-5.patch1.98 KB

Theres a fatal error on FacetapiTestCase::getInfo(). this patch adds the guts of hook_hook_info to prevent the fatal.

sherakama’s picture

sherakama commented
Status: Active » Reviewed & tested by the community

Nice work @boznik,

This looks to be the root cause. Running several days on a production site now and this has not cropped up. Seems to stem from this issue: https://www.drupal.org/node/496170 where PHP errors early caused a poisoned cache.

Lets get this in!

nwom’s picture

nwom commented

The patch from #5 does not include the changes from #4, but is instead a separate patch. Is this intentional?

boznik’s picture

boznik commented

RE #7: Yes, that is intentional.

eugene.ilyin’s picture

eugene.ilyin commented

Mhh, patches #4 and #5 are different, I'm bit confused and I don't know how to reproduce the problem. I'm stuck and I cannot just commit something and hope that it's solution.

eugene.ilyin’s picture

eugene.ilyin commented
Status: Reviewed & tested by the community » Postponed (maintainer needs more info)
dchatry’s picture

dchatry
Location France
commented

Currently running an instance with Search API Solr, Facet API and a lot of cache. Recently, I moved the cache handler from Drupal own's to Memcache.
Since then, my website kept randomly crashing (a few times a week, or even a day sometimes) with no apparent reason and would not work until I cleared all caches. The logs redirected me to this issue and so I applied patches #4 and #5. It's been a week now an the problem has yet to resurface, so I'd say it has worked in my case!

If you have trouble reproducing the issue, maybe try configuring a Search API view with lots of contents, lots of facets, and a third party cache module (like Memcache).

wdseelig’s picture

wdseelig commented

Am curious why neither the patch in #4 or #5 is included in the 7.x-1.x-dev version published in late 2017?