Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
#27 | 1306198-27.patch | 1.62 KB | cpliakas |
#23 | processor-class-autoload-1306198-23.patch | 674 bytes | cpliakas |
Comments
Comment #1
cpliakas CreditAttribution: cpliakas commentedWhich search module are you using?
Comment #2
cpliakas CreditAttribution: cpliakas commentedSo 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?
Comment #3
omills CreditAttribution: omills commentedSame 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
Comment #4
omills CreditAttribution: omills commentedSolution: Cache clear gets it working again! Thanks cpliakas
drush cache-clear
Comment #5
cpliakas CreditAttribution: cpliakas commentedThanks for posting back, omills. Marking this as fixed because a cache clear does the trick.
Comment #6
cpliakas CreditAttribution: cpliakas commentedJust 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
Comment #8
greg.harveyGetting 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.
Comment #9
cpliakas CreditAttribution: cpliakas commentedThanks for posting back. What version of Apache Solr Search Integration are you using?
Comment #10
greg.harveyThis 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.
Comment #11
cpliakas CreditAttribution: cpliakas commentedThe 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
Comment #12
greg.harveyHi 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. =)
Comment #13
yurtboy CreditAttribution: yurtboy commentedgreg.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
Comment #14
greg.harveyInteresting additional info - thanks. I haven't had chance yet. Spent the last few days in never ending phone calls and dealing with infrastructure issues... =/
Comment #15
Nick_vhI 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
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.
Comment #16
yurtboy CreditAttribution: yurtboy commentedSo 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!
Comment #17
Nick_vhWe 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
Comment #18
cpliakas CreditAttribution: cpliakas commentedOh wow that sucks. Great debugging, guys. I will try to replicate based on the information above.
Comment #19
yurtboy CreditAttribution: yurtboy commentedThis has been working great. No more issue while I theme out the page.
Thanks again!
Comment #20
cpliakas CreditAttribution: cpliakas commentedBased on comments in #16 and #19, should we roll a patch and mark this as RTBC?
Comment #21
Nick_vhcpliakas, this change has more impact if we include the path for all other plugins also. As a way for a fallback when autoload fails?
Comment #22
cpliakas CreditAttribution: cpliakas commentedDo 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.
Comment #23
cpliakas CreditAttribution: cpliakas commentedSo 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.
Comment #24
cpliakas CreditAttribution: cpliakas commentedI committed my hack to the 7.x versions of Facet API. If it doesn't work we can re-open and try other methods.
Comment #26
bear_beavis CreditAttribution: bear_beavis commentedI 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...
Comment #27
cpliakas CreditAttribution: cpliakas commentedThanks 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.
Comment #28
cpliakas CreditAttribution: cpliakas commentedCommitted "fix". Let's move to the other issue for future debugging.