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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

shinz83’s picture

Yikes! It just took me down!

I need this module!

cpelham’s picture

I get this, too!

clanghoff’s picture

Me too. Any solutions?

TimelessDomain’s picture

Priority: Normal » Major
cpelham’s picture

Priority: Major » Critical

I 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?

TJM’s picture

I 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.

Anonymous’s picture

I 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.

TimelessDomain’s picture

applied patch recommended by #7 (line 577-585 of file.field.inc), but it did not fix the error

TJM’s picture

#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.

paulgemini’s picture

Here's a temporary solution that allowed me to deactivate mini panels without going into the database:

http://drupal.org/node/1139732#comment-4526448

paulgemini’s picture

That proved to be a temporary solution as the problem is back...

marcvangend’s picture

I 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.

marcvangend’s picture

Status: Active » Needs review
FileSize
498 bytes

...and here is a patch.

Status: Needs review » Needs work

The last submitted patch, 1169986-13-class-feedsplugin-not-found.patch, failed testing.

Screenack’s picture

Seeing this error here, too, after upgrading to Drupal 7.2

snjogu’s picture

Title: Drupal 7.2 ... ( ! ) Fatal error: Class 'FeedsPlugin' not found » Drupal 7.2 ------- Fatal error: Class 'FeedsPlugin' not found xxxxxx

This 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!!

marcvangend’s picture

Title: Drupal 7.2 ------- Fatal error: Class 'FeedsPlugin' not found xxxxxx » Drupal 7.2 - Fatal error: Class 'FeedsPlugin' not found

See #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.

wishville’s picture

Feeds temporarily disabled but subscribing for updates and fix.

snjogu’s picture

Hi, 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?

widhalmt’s picture

Waiting and subscribing, too.

marcvangend’s picture

See comment #12 for a quick fix (worked for me at least). No need to apply a patch, just add 1 line to feeds.info.

snjogu’s picture

Thanx.
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.

oggsmith’s picture

#12 works for me too, prior to patching I had to clear cache to get the site working again.

snjogu’s picture

Title: Drupal 7.2 - Fatal error: Class 'FeedsPlugin' not found » For the module Nodejs

I 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??

TimelessDomain’s picture

Title: For the module Nodejs » Drupal 7.2 - Fatal error: Class 'FeedsPlugin' not found
merlinofchaos’s picture

Note that CTools plugins auto register classes, so the solution in #13 is not actually correct. Though it may appear to solve the problem.

marcvangend’s picture

@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".

merlinofchaos’s picture

We've found the problem. It's in core itself. A temporary workaround is posted here:

http://drupal.org/node/1170312#comment-4547662

rickmanelius’s picture

I had to apply both #28 and #12, now it seems I'm alright.

chrisjlee’s picture

Status: Closed (duplicate) » Needs work

#28 Worked for me. Confirms it. The issue is a bug in core. My registry needed to be rebuilt. Fails to register classes.

TimelessDomain’s picture

i agree with #30

chrisjlee’s picture

Should consider this closed.

webchick’s picture

Status: Needs work » Closed (duplicate)
webchick’s picture

mindbat’s picture

Version: 7.x-2.0-alpha3 » 7.x-2.0-alpha7
Status: Needs work » Active

This 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?

mindbat’s picture

One more note: after using the fix from #12, I got "Missing Plugin" errors until I cleared the cache.

omega8cc’s picture

It 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.

merlinofchaos’s picture

As 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.

omega8cc’s picture

@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:

files[] = plugins/FeedsCSVParser.inc
files[] = plugins/FeedsFetcher.inc
files[] = plugins/FeedsFileFetcher.inc
files[] = plugins/FeedsHTTPFetcher.inc
files[] = plugins/FeedsNodeProcessor.inc
files[] = plugins/FeedsOPMLParser.inc
files[] = plugins/FeedsParser.inc
files[] = plugins/FeedsPlugin.inc
files[] = plugins/FeedsProcessor.inc
files[] = plugins/FeedsSimplePieParser.inc
files[] = plugins/FeedsSitemapParser.inc
files[] = plugins/FeedsSyndicationParser.inc
files[] = plugins/FeedsTermProcessor.inc
files[] = plugins/FeedsUserProcessor.inc

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.

merlinofchaos’s picture

Except 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.

omega8cc’s picture

I 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.

twistor’s picture

Assigned: Unassigned » twistor

This 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.

merlinofchaos’s picture

ahh, 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.

colan’s picture

Version: 7.x-2.0-alpha7 » 7.x-2.0-alpha8
Status: Active » Fixed

This 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?

Taxoman’s picture

Title: Drupal 7.2 - Fatal error: Class 'FeedsPlugin' not found » Fatal error: Class 'FeedsPlugin' not found

One 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.

DamienMcKenna’s picture

Status: Fixed » Closed (fixed)

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

Status: Closed (fixed) » Needs review
samuel.mortenson’s picture

Issue summary: View changes

I'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.

Status: Needs review » Needs work

The last submitted patch, 13: 1169986-13-class-feedsplugin-not-found.patch, failed testing.

MegaChriz’s picture

Status: Needs work » Closed (fixed)

The change in the patch from #13 is already committed. If you still get this error, try a registry rebuild.

semi-k’s picture

Status: Closed (fixed) » Active

Same 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

Ace Cooper’s picture

@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

MegaChriz’s picture

Issue summary: View changes
Status: Active » Closed (fixed)

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. 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.