After installing Drupal 7.2, after running flush, cron, and update.php, the site crashed with this error: ( ! ) Fatal error: Class 'FeedsPlugin' not found. I can revive the site by disabling the feeds module (http://www.example.com/admin/modules/list) with the list modules link.
Has anyone else had this issue when upgrading to Drupal 7.2?
Cause
An outdated registry. Drupal keeps track of which class is where on the file system in a thing that is called a registry. However, this registry isn't 100% reliable: whenever you move or update a module, the registry may become outdated. Classes may have been moved, added or deleted. The result is that Drupal no longer can find a specific class if a module requested it, even if that module contains the class in question.
Solution
Perform a registry rebuild.
Comment | File | Size | Author |
---|---|---|---|
#13 | 1169986-13-class-feedsplugin-not-found.patch | 498 bytes | marcvangend |
Comments
Comment #1
shinz83 CreditAttribution: shinz83 commentedYikes! It just took me down!
I need this module!
Comment #2
cpelham CreditAttribution: cpelham commentedI get this, too!
Comment #3
clanghoff CreditAttribution: clanghoff commentedMe too. Any solutions?
Comment #4
TimelessDomain CreditAttribution: TimelessDomain commentedComment #5
cpelham CreditAttribution: cpelham commentedI found that when I turn off Feeds I still get a similar error message for CTools and Mini Panels:
Fatal error: Class 'ctools_export_ui' not found in /home/cpelham/public_html/dev.crsny.org/public/sites/all/modules/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3
This leads me to wonder, could this be a bigger problem with the 7.2 update?
Comment #6
TJM CreditAttribution: TJM commentedI have encountered the Fatal error: Class 'ctools_export_ui' not found too. The error went away, when I deleted the database with phpmyadmin and imported a database from a development site without CTools and Panels. I then re-activated the modules on the new database, and now the database is not producing the Fatal error even though both CTools and Panels are activated. I will have to wait and see if the site crashes again. I am not a developer, so I don't know how to find the bugs.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedI experienced the same issue. After clearing the cache a few times, I was still getting an AJAX error while trying to import one of my feeds (worked on the other feeds, though).
I ultimately found this post (http://drupal.org/node/1146288) that fixed the issue for me. I am now importing everything successfully again.
Comment #8
TimelessDomain CreditAttribution: TimelessDomain commentedapplied patch recommended by #7 (line 577-585 of file.field.inc), but it did not fix the error
Comment #9
TJM CreditAttribution: TJM commented#6 suggestion failed for me after using the web site several more time. Apparently, there are a couple of problems. One is with the Feeds module and the other is with the Panels module.
http://drupal.org/node/1170312
http://drupal.org/node/1139732
flush the cache
Currently, I find the following working for me for Drupal 7.2. ... We'll see if the fix continues.
1. apply the code change at this link... http://drupal.org/node/1146288 replacing the original code of lines 577-585 of drupal7/modules/file/file.field.inc with the new code given in the link.
2. de-select the Mini panels in the Panels module. Then run uninstall.
flush cache, run cron, and run Status Report to see if everything is OK.
Comment #10
paulgemini CreditAttribution: paulgemini commentedHere's a temporary solution that allowed me to deactivate mini panels without going into the database:
http://drupal.org/node/1139732#comment-4526448
Comment #11
paulgemini CreditAttribution: paulgemini commentedThat proved to be a temporary solution as the problem is back...
Comment #12
marcvangendI think this happens because modules need to declare which files containing the classes they use, so the classes can be auto-loaded. The FeedsPlugin class is declared in plugins/FeedsPlugin.inc, but that file is not listed in feeds.info. drupal 7.2 seems stricter with this requirement (described in http://drupal.org/node/542202) than 7.0 was.
I was able to solve this problem by adding
files[] = plugins/FeedsPlugin.inc
to feeds.info. Perhaps other files need to be added as well in case similar problems with other classes occur.
Comment #13
marcvangend...and here is a patch.
Comment #15
Screenack CreditAttribution: Screenack commentedSeeing this error here, too, after upgrading to Drupal 7.2
Comment #16
snjogu CreditAttribution: snjogu commentedThis error won't go.
Fatal error: Class 'FeedsPlugin' not found in"xxxxxxxxxx"
Version 7.2 (stable release)
Comes up after installing (feeds module)[either dev or stable release ].
Then brings da site down.
Need help guys!!
Comment #17
marcvangendSee #1170312-17: After updating to Drupal 7.2 Fatal error: Class 'ctools_export_ui' not found; if this is a problem with ctools' autoloading mechanism, the trick in #12 may be a simple workaround but not the correct fix.
Comment #18
wishville CreditAttribution: wishville commentedFeeds temporarily disabled but subscribing for updates and fix.
Comment #19
snjogu CreditAttribution: snjogu commentedHi, at first it was ctools but i was able to sort that out...by re-installing. For feeds it different story. How do u apply a patch?
Comment #20
widhalmt CreditAttribution: widhalmt commentedWaiting and subscribing, too.
Comment #21
marcvangendSee comment #12 for a quick fix (worked for me at least). No need to apply a patch, just add 1 line to feeds.info.
Comment #22
snjogu CreditAttribution: snjogu commentedThanx.
This worked for now n hopefully settles the nerves.
. Re-installed feeds module(this time the dev release version)
.followed #12 [i.e adding "files[] = plugins/FeedsPlugin.inc"
to feeds.info. in the feeds module]
.enabled the module
.run update(which prompted me to update ctools--from alpha to 7.x-1.0-beta1 [just released]).
Now i can flush all caches, run cron and off course run updates without the site crashing down as it used to.
Comment #23
oggsmith CreditAttribution: oggsmith commented#12 works for me too, prior to patching I had to clear cache to get the site working again.
Comment #24
snjogu CreditAttribution: snjogu commentedI get this after running cron.
file_get_contents(sites/all/modules/nodejs/socket_io/socket.io/support/socket.io-client/socket.io.js) [function.file-get-contents]: failed to open stream: No such file or directory in _locale_parse_js_file() (line 1393 of YYYYYYYYYY\includes\locale.inc).
Any idea??
Comment #25
TimelessDomain CreditAttribution: TimelessDomain commentedComment #26
merlinofchaos CreditAttribution: merlinofchaos commentedNote that CTools plugins auto register classes, so the solution in #13 is not actually correct. Though it may appear to solve the problem.
Comment #27
marcvangend@merlinofchaos #26: I know, that's why I wrote in #17: "if this is a problem with ctools' autoloading mechanism, the trick in #12 may be a simple workaround but not the correct fix".
Comment #28
merlinofchaos CreditAttribution: merlinofchaos commentedWe've found the problem. It's in core itself. A temporary workaround is posted here:
http://drupal.org/node/1170312#comment-4547662
Comment #29
rickmanelius CreditAttribution: rickmanelius commentedI had to apply both #28 and #12, now it seems I'm alright.
Comment #30
chrisjlee CreditAttribution: chrisjlee commented#28 Worked for me. Confirms it. The issue is a bug in core. My registry needed to be rebuilt. Fails to register classes.
Comment #31
TimelessDomain CreditAttribution: TimelessDomain commentedi agree with #30
Comment #32
chrisjlee CreditAttribution: chrisjlee commentedShould consider this closed.
Comment #33
webchickComment #34
webchickOn #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap, that is.
Comment #35
mindbat CreditAttribution: mindbat commentedThis error occurred for me after upgrading to the latest version - alpha7.
The fix from #12, followed by running update.php, solved the problem for me.
Any chance we could get that line added to the feeds.info file in the next release?
Comment #36
mindbat CreditAttribution: mindbat commentedOne more note: after using the fix from #12, I got "Missing Plugin" errors until I cleared the cache.
Comment #37
omega8cc CreditAttribution: omega8cc commentedIt looks like a duplicate of #1201638: Plugins should be listed in info file. Note that the patch posted there was already committed but it is no longer in the code, so I have re-opened the other issue.
Comment #38
merlinofchaos CreditAttribution: merlinofchaos commentedAs I said in #26: CTools plugins auto-register plugin class files and should not be listed in the .info file. This means that the fix from #12 is not correct.
Comment #39
omega8cc CreditAttribution: omega8cc commented@merlinofchaos Maybe, but since running Registry Rebuild, which is expected to *fix* weird issues like this one, in fact *triggers* this fatal error in Feeds, while adding there lines:
and then running `drush rr` again fixes the problem permanently and there are no other side effects.
I understand it doesn't look pretty, but it does work, and anyone who removed these lines from feeds.info after they have beed added, made the life harder for many people.
Comment #40
merlinofchaos CreditAttribution: merlinofchaos commentedExcept that the fix is incorrect.
I understand that, as a user, you don't care about whether the fix is correct or not, just that it works for you, but that is actually pretty important to module maintainers. It means that there is another problem that's actually causing this, and slapping a bandaid over it is not the right way to go about it.
Every other module out there does not have to register their class plugin files. So why should this module? Clearly something is wrong, somewhere, that is breaking the auto-registration process. That needs to be investigated. Maybe it's hiding another problem.
Comment #41
omega8cc CreditAttribution: omega8cc commentedI fully agree that the patch from #1201638: Plugins should be listed in info file is not a fix. It is just a workaround. However, once there is workaround (committed!) and no fix yet (because the real underlying issues are not identified), what is the reasoning behind removing the workaround and making life harder for people who are not aware that there is such weird issue waiting to crash their sites? That is the reasoning behind re-opening the other issue and asking to re-add the workaround, until the proper fix will be available.
Comment #42
twistor CreditAttribution: twistor commentedThis issue just came on my radar.
There have been a bunch of problems with registering plugins. Currently, any contrib module implementing a Feeds plugin will need a cache refresh after being enabled so that the plugin can be found. The workaround is to add it to the info file. In D6, the workaround was to clear the ctools plugin cache on hook_enable(), but that doesn't work in D7. There are similar issues with tests failing because of missing plugins.
@merlinofchaos, Is it correct to have FeedsPlugin registered as a plugin? It's an abstract base class that other plugins need to implement things.
Anyway, digging in.
Comment #43
merlinofchaos CreditAttribution: merlinofchaos commentedahh, I usually implement those abstract base classes as invisible plugins, but that's not necessary. If it's an abstract base class and not at rue plugin, then putting it in the .info file makes more sense.
Comment #44
colanThis is now working in the latest alpha thanks to commits from #1201638: Plugins should be listed in info file. Or we could mark this as a duplicate of that one as it's still open?
Comment #45
Taxoman CreditAttribution: Taxoman commentedOne of the underlying and fixed issues here was fixed in Drupal 7.14.
(See #1347894: Clear cache causes integrity constraint violation )
Therefore the title of this issue is misleading when it refers to Drupal 7.2.
Also notice that the currently working "set of fixes" are temporary, awaiting other changes to fulfill the fix, so this might crop up again.
Comment #46
DamienMcKennaMarked #1979634: Fatal Error when updated feeds from Alpha 7 to Alpha 8 as a duplicate.
Comment #49
samuel.mortensonI'm re-testing the patch, and will re-roll if it fails. I don't see why we should wait for a core issue to be resolved when a simple fix is already available.
Comment #51
MegaChriz CreditAttribution: MegaChriz commentedThe change in the patch from #13 is already committed. If you still get this error, try a registry rebuild.
Comment #52
semi-k CreditAttribution: semi-k commentedSame problem after reset cache with D7.43 + feeds 7.x-2.0-beta2 (feb 2016).
I can't restart my website after the crash (impossible to deactivate Feeds module even with Drush)...
Thanks for helping
Comment #53
Ace Cooper CreditAttribution: Ace Cooper as a volunteer commented@semi-k Follow #51 here or let me point you to my reply in the neighbouring thread:
https://www.drupal.org/node/2721287#comment-11174385
Comment #54
MegaChriz CreditAttribution: MegaChriz as a volunteer commentedDrupal keeps track of which class is where on the file system in a thing that is called a registry. However, this registry isn't 100% reliable: whenever you move or update a module, the registry may become outdated. Classes may have been moved, added or deleted. The result is that Drupal no longer can find a specific class if a module requested it, even if that module contains the class in question. In some cases this issue can be fixed by going to the module admin page and then clear all caches. When the module page is accessed, all module paths are updated. Some modules may request classes quite early in the bootstrap process, like Rules or Feeds. This will then result into a no longer accessible website and then there is now way to access the module page. In such cases Drupal's registry needs to be updated in an other way. This can be done by executing the registry rebuild script. In some cases I experienced that I needed to rebuild the registry twice as there were errors during the first run.
Closing this issue as the patch for this issue has already been committed.