My site (Drupal 7.2) is invisible.
At the end of updating process (updated only one module, Views Ticker) fatal error appeared as no connection to the home page of my site.

For other pages, the message is:
Fatal error: Class 'FeedsPlugin' not found in /sites/all/modules/feeds/feeds.module on line 214

On the admin/modules page I have the message that there are no any batch process.

As my previous action was enabling flags for Feeds and Feed-items, I disabled these flags. Disabling looks OK, however, another message is displayed:

Fatal error: Class name must be a valid object or a string in /sites/all/modules/feeds/includes/ on line 60

More info I got when tried to update UI translations:
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=83&op=do StatusText: OK ResponseText: Fatal error: Class name must be a valid object or a string in /sites/all/modules/feeds/includes/ on line 60

In the meantime I disabled and uninstalled Views Ticker (on the admin screen only not deleted form file system). No effect.

#11 feeds_1177844.patch933 bytesgrendzy
Members fund testing for the Drupal project. Drupal Association Learn more


AndrzejG’s picture

Status: Active » Needs work

Changed status.

AndrzejG’s picture

The same is when try cron:
Fatal error: Class name must be a valid object or a string in /sites/all/modules/feeds/includes/ on line 60

The same when try to come to admin/index.

Views disappeared from my Shortcuts and from Administration menu.

Now in the amin/modules page I have the message that FeedsHTTPFetcher plugin is missing. However I cannot go to admin/structure/feeds/edit/feed because of the same fatal error.


AndrzejG’s picture

Finally I disabled Feeds News module, and now all works as should work.

After a while - no, not all. I tried to set flags to Feed and Feed-item again, and all errors returned.

I had to disable also Feeds Import module. Now site works.

AndrzejG’s picture

Status: Needs work » Closed (works as designed)

OK, I realized that is the problem of the concept of how Feeds importers finish their work. It is not the only drawback raising from this problem. So, I will place another ticket. Closing this one.

q2_faith’s picture


AndrzejG’s picture

Status: Closed (works as designed) » Needs work


Despite I have Feeds News disabled, the error occured again. Just after updating IMCE, and running update.php. the site disappeared (the same as above).
Then I tried to update translations (to Polish) and the Message is:

Wystąpił błąd w AJAX HTTP. Błąd HTTP: 200 Informacje diagnostyczne. Ścieżka: /batch?id=93&op=do StatusText: OK ResponseText: Fatal error: Class name must be a valid object or a string in /sites/all/modules/feeds/includes/ on line 60

The same, as reported in my first post.

My intuition is that cron-based feed import is in some conflict with updating processes.

So, I disabled Feeds Import, and my site appeared as should do.
Translation update also works fine.

So, now I enable Feeds Import. Everything works fine.

chrisjlee’s picture

I just had this issue. I think it's related to #1170312: After updating to Drupal 7.2 Fatal error: Class 'ctools_export_ui' not found. It's a drupal core issue.

Rebuild the registry by adding a command to the index.php as suggested by merlinofchaos:

In the meantime, avoid hitting the update.php unless totally needed.

AndrzejG’s picture

Thank You, Chrisjlee.

BTW, I also reported similar bug of update process, see There were a lot of discussions and I thought the bud is fixed in Drupal 7.2. It is not, unfortunately.

RonP’s picture

#7 worked flawlessly for me and I am newb so don't be afraid to do it.

And don't hit update.php till core gets next release.

jojonaloha’s picture

Version: 7.x-2.0-alpha3 » 7.x-2.0-alpha5

I'm not sure that the core issue was the only thing causing this error. I've encounted this Fatal error on Drupal 7.12 and Drupal 7.14

Both sites were using Feeds which were exported as Features. I've tried the suggestion in #7. Both times the error occurred after deploying to a staging server, which our deploy scripts do a 'drush registry-rebuild'. Trying a drush cc all, drush registry-rebuild just returns the Fatal error.

I added something like this just above the line causing the error, and it was printing NULL.

if (!class_exists($class)) {

After doing a debug_backtrace() I found the line that was being called creating this error was (from feeds_plugin()):

$class = ctools_plugin_load_class('feeds', 'plugins', 'FeedsMissingPlugin', 'handler');
return FeedsConfigurable::instance($class, $id);

The $plugin in one case was MailhandlerFetcher, but the class does exist it just wasn't in the registry (yet?).

I was able to change to add:

class FeedsConfigureMissingPlugin extends FeedsConfigurable {
  public function save() {
    dpm('Missing Feeds plugin or bad registry.');

and update the if (!class_exists($class)) I added earlier to:

if (!class_exists($class)) {
  return new FeedsConfigureMissingPlugin($id);

Then I was able to do a 'drush registry-rebuild' (may get a different fatal error) but after that the site loads fine.

I'm not sure if this is the best method to go about this, but I definitely think something should be done with feeds_plugin() with the FeedsMissingPlugin because ctools_plugin_load_class() may return NULL.

grendzy’s picture

Priority: Major » Critical
Status: Needs work » Needs review
933 bytes

I'll admit I don't fully understand this issue, since it seems that ctools is expected to autoload the plugins. However adding them to the info file resolves the issue for me (combined with a similar patch to mailhandler: #1645816: PHP fatal error after registry rebuild).

franz’s picture

Status: Needs review » Closed (won't fix)

I'm closing this since it seems to be a Ctools bug.

jastraat’s picture

Status: Closed (won't fix) » Active

I am getting this error with feeds 7.x.2.0 alpha5, the latest Drupal 7, and the lastest release of ctools. I tried grendzy's solution, but it's still producing these errors and preventing the module administration page from loading.

grendzy’s picture

franz, can you link the ctools bug here for reference?

twistor’s picture

twistor’s picture


Can you post specifically what errors you are getting?

jastraat’s picture

I was getting the class __plugin not found errors along with many others.

However - after further investigation, I think my problems were unrelated to these modules (although I feel like there should be some better error handling).

We work in a multi-server environment of multi-site installs and one of our sites was being called from two multi-site installs on two separate servers. One had the feeds module, and the other did not - but calls to it were randomly failing based on which instance responded. It was a mess - but completely unrelated to this thread.

twistor’s picture

Status: Active » Closed (won't fix)

Better error handling is definitely something we could use, but that's a separate issue.

Closing this again, since you resolved your issue.

henk’s picture

I had similar bug after update Feeds. The easiest way if somebody have this problem is: remove Feeds module refresh the site and put it again.

Update core (I had 7.14 and update to 7.19) before update Feeds also fix this.

attheshow’s picture

Running drush rr fixed the problem on my site.

kevinsbath’s picture

+1 for running drush rr - thanks @attheshow

tim_dj’s picture

drush rr runs but did still give error if run from root path (even though a default is set in sites.php) I had to actually go into my multisite path.

lanceaeby’s picture

Issue summary: View changes

I came up with a temporary solution that worked for me.

I have a few importers on a site that run periodically via a cronjob, that import dates from an iCal feed using the Date iCal module. I had installed a few other modules unrelated to the Feeds module, tried to clear the registry (drush rr), and drush throws a bunch of "Fatal: Missing Parser" errors and can't complete the registry rebuild. This in turn kills the entire site.

My solution was to copy the parser that exists in the Date iCal module (date_ical/includes/, and paste it into the plugins directory within the Feeds module (feeds/plugins/). I then added a line to the Feeds info file (feeds/ defining the parser I just copied in.

This is what the ; Plugins section of my file looks like after the change:

; Plugins
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/
files[] = plugins/

I'm now able to clear the cache and rebuild the registry without errors. I'm not entirely sure if the Date iCal parser was being loaded before Feeds for some reason, but this worked as a temporary fix for me.

Kristen Pol’s picture

Thanks to @attheshow in #20. drush rr worked for us too.