in facetapi/plugins/facetapi/adapter.inc on line 112 there is a fatal error when creating a new class.

Came across this upgrading from Beta 6 -> 7

Let me know if there's any other information I can provide to help resolve this. Thanks!

Grant

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cpliakas’s picture

Which search module are you using?

cpliakas’s picture

Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

So this looks like the URL Processor plugin, which was added in beta7. This means that the hook implementations aren't cached, which I am assuming is the issue. Did you clear cache or run update.php after updating the module?

omills’s picture

Same problem for me, during beta 6 to 7 update.
Here is my pm list:
Search Database search (search_api_db) Module 7.x-1.x-dev
Search Search API (search_api) Module 7.x-1.x-dev
Search Search facets (search_api_facetapi) Module 7.x-1.x-dev
Search Search pages (search_api_page) Module 7.x-1.x-dev
Search Search views (search_api_views) Module 7.x-1.x-dev
Search Toolkit Facet API (facetapi) Module 7.x-1.0-beta7

omills’s picture

Solution: Cache clear gets it working again! Thanks cpliakas
drush cache-clear

cpliakas’s picture

Status: Postponed (maintainer needs more info) » Fixed

Thanks for posting back, omills. Marking this as fixed because a cache clear does the trick.

cpliakas’s picture

Just a note here...

Whenever updating any module you must run update.php as part of the update process. Facet API beta 7 does have a schema update, so it needs to be run. It will also clear cache, preventing the issue in the OP above.

Thanks,
Chris

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

greg.harvey’s picture

Title: Fatal error: Class name must be a valid object or a string on line 112 of Adapter.inc » Fatal error: Class name must be a valid object or a string on line 137 of adapter.inc
Version: 7.x-1.0-beta7 » 7.x-1.0-rc4
Status: Closed (fixed) » Active

Getting this again, using Apache Solr Integration, was fine with beta10 of that and beta7 of Facet API - just upgraded to rc4 (yes, have run updatedb and cleared cache many times, restarted PHP in case APC is causing problems, etc. etc.) and I'm getting this again. Going to downgrade to make sure it's definitely an issue with Facet API.

cpliakas’s picture

Thanks for posting back. What version of Apache Solr Search Integration are you using?

greg.harvey’s picture

This was latest, 7.x-1.0-beta16. But then I thought at first it was Apache Solr at fault, so I rolled that back before I rolled back Facet API, so also tried it with 7.x-1.0-beta10 and Facet API 7.x-1.0-rc4 still gave me that error with both Apache Solr releases. Let me know if there are any specific checks/environment information you want me to do/give you. =)

Edit: Forgot to say, rolling back Facet API did fix the problem - rolling back Apache Solr Integration alone did not.

cpliakas’s picture

Status: Active » Postponed (maintainer needs more info)

The standard URL processor is defined by Facet API and a vital component, so it really should exist. I'm sure a lot more people would be yelling at me if it didn't :-). One of the difference between Facet API betaX and rcX releases is that a hook_hook_info() implementation was added and Facet API hook implementations were separated out into a facetapi.facetapi.inc file. Are you sure this file is present in the environment you are testing on? If you are deploying via VCS, is it possible that this file wasn't explicitly added? That's really the only thing I can think of off the top of my head.

Thanks,
Chris

greg.harvey’s picture

Hi Chris - thanks for taking the time to reply. We deploy with Jenkins and the file was definitely there. Very odd. I'll have to try this again and report back. I'll give it a go tomorrow, if I remember/get time. =)

yurtboy’s picture

greg.harvey any update on this?

Just a follow up on this. I get the same error which after a magical combination or cache clear. theme change back and forth and reading some random news for a few minutes it works again.

The trigger for me is when I try to add additional theme functions into the project around this one area. The site is 99% done so it is well themed and working. But only here do simple things like adding dpm to hook_preprocess_page to get some output I need or even moving search-results.tpl.php into the theme folder cause this error to start up.

PHP Fatal error: Class name must be a valid object or a string in /var/www/staging/sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc on line 137

Here is my list of modules
Core Search (search) Module Enabled 7.10
Search Toolkit Apache Solr search (apachesolr_search) Module Enabled 7.x-1.0-beta16+18-dev
Search Toolkit Current Search Blocks (current_search) Module Enabled 7.x-1.0-rc4
Chaos tool suite Chaos tools (ctools) Module Enabled 7.x-1.0-rc1

greg.harvey’s picture

Status: Postponed (maintainer needs more info) » Active

Interesting additional info - thanks. I haven't had chance yet. Spent the last few days in never ending phone calls and dealing with infrastructure issues... =/

Nick_vh’s picture

I had similar encounters when backporting the module to Drupal 6. This exact error seemed to popup regurlarly. And it could be caused by a malfunction in the autloading of classes actually. It seems that this function is called too early somehow and thus the url processor does not exist.

What you could try in the meantime is to hard-wire the path to the file where the class is situated :

facetapi.facetapi.inc

/**
 * Implements hook_facetapi_url_processors().
 */
function facetapi_facetapi_url_processors() {
  return array(
    'standard' => array(
      'handler' => array(
        'label' => t('Standard URL processors'),
        'class' => 'FacetapiUrlProcessorStandard',
        'file' => drupal_get_path('module', 'facetapi') . "/plugins/facetapi/url_processor_standard.inc",
      ),
    ),
  );
}

Notice: the file path was added
If this does not resolve it, try to do a include_once of the url_processor.inc in that same function, before the return to figure out if the class loading is your problem.

yurtboy’s picture

So far so good! It is not complaining about the search-result.tpl.php folder in the themes folder. I added one test change it it is still working!
Just excited after hours of trying to figure out if it was a server issue or solr issue etc.
When looking at the error it seemed far enough up the line that I could not
All I did was your first suggestion.
I will get more into it this weekend again (maybe today if I catch up on other build stuff) and let you know.
Let me know if you need more testing etc since I have a VM running this site I can easily change up modules etc and let you know what works.

Thanks!

Nick_vh’s picture

We might need to add all the file paths for the plugins. Just in case... Ctools will figure out if it is already loaded or not. The only thing I am a bit worried about is that for example url_processor.inc is not included because it is not a plugin, it is a base class.

So probably we need to add a simple mechanism to load those classes when needed? This could also help 6.x-3.x

cpliakas’s picture

Oh wow that sucks. Great debugging, guys. I will try to replicate based on the information above.

yurtboy’s picture

This has been working great. No more issue while I theme out the page.
Thanks again!

cpliakas’s picture

Based on comments in #16 and #19, should we roll a patch and mark this as RTBC?

Nick_vh’s picture

cpliakas, this change has more impact if we include the path for all other plugins also. As a way for a fallback when autoload fails?

cpliakas’s picture

Do you think we need to do this for all plugins, or just the URL processor? I am totally fine with this workaround, but personally I'd rather not duplicate the class loading unless necessary. I could be convinced otherwise.

cpliakas’s picture

Status: Active » Needs review
FileSize
674 bytes

So what about something like this? It is more of a hack, but at least it prevents having to have a dual loading mechanism in the core plugins.

cpliakas’s picture

Status: Needs review » Fixed

I committed my hack to the 7.x versions of Facet API. If it doesn't work we can re-open and try other methods.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

bear_beavis’s picture

Version: 7.x-1.0-rc4 » 7.x-1.2
Status: Closed (fixed) » Active

I got the same issue with Facetapi 7.x.1.2

"Fatal error: Class name must be a valid object or a string in sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc on line 219 "

I found a workaround, module ctools has weight 0 in table system :

update system set weight=-1 where name='facetapi';
drush cc all
then it works everytime

update system set weight=1 where name='facetapi';
drush cc all
got the error everytimes when pointing my browser to url '/admin/config/search/apachesolr/settings/solr/facets'

When facetapi weight is 0 like ctools module, sometimes it works, sometimes not...

cpliakas’s picture

Status: Active » Needs review
FileSize
1.62 KB

Thanks for the details. Before changing the weight by default, I want to figure out why this even matters. If it is unavoidable then we can modify the weight on install and see what the consequences are, if any. The attached patch will at least prevent the fatal errors, and I opened a separate issue at #1816110: Determine why the URL processor plugins are unavailable when CTools is weighted heavier than Facet API where we can analyze why the weights have any bearing on this.

cpliakas’s picture

Status: Needs review » Fixed

Committed "fix". Let's move to the other issue for future debugging.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.