I just upgraded to 7.2 last night and now I am getting fatal (white screen of death) errors:

Fatal error: Class 'ctools_export_ui' not found in .../sites/all/modules/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3

Another similar error is related to Feeds, which went away when I deactivated it but left me with the ctools error:

Fatal error: Class 'FeedsPlugin' not found

Not sure if these are related. Did something to do with plugins change in the 7.2 upgrade? A number of people are reporting these errors:

http://drupal.org/node/1169986
http://drupal.org/node/1139732

Comments

nikkubhai’s picture

I got the same error after updating to drupal 7.2

Fatal error: Class 'ctools_export_ui' not found in /home/***/public_html/sites/all/modules/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3

Few things which I want to clarify:
1. I found that I face the problem only when I login as admin. On every page I get the above error and I can't access anything.

2. This error occurred when I ran cron.

3. for other users, Panels are not working.

cpelham’s picture

Until we solve the error, you can disable Panels Mini. The rest of Panels should still work without throwing an error message. That has been my experience anyway.

If you backed up your site before upgrading to Drupal 7.2, you could restore back to Drupal 7.0. It has also been suggested that after reverting back to Drupal 7.0 it would probably be safe to upgrade to Drupal 7.1, just not to Drupal 7.2.

nikkubhai’s picture

@cpelham: How can I disable Panels mini? I can't access any page as admin. Can't access the modules page too. Is there any other way to disable the module?

cpelham’s picture

Do you have direct access to your database tables through phpmyadmin or some other way (command line is also possible)?

Through phpmyadmin you can click on the system table, which contains a row for each module. Scan down the rows (it might be several pages depending on how many modules you have) unril you find the row for module panels mini. Click the pencil icon. Then the row will open up and you will see the data for it. You will want to change the value of the status field from 1 to 0. 1 means the module is activated and 0 means it is turned off.

I found that I also had to empty the cache tables. Select each of the cache tables and then empty them. Do not DROP them by mistake!

After that your site should hopefully come back to life.

cpelham’s picture

Do you have direct access to your database tables through phpmyadmin or some other way (command line is also possible)?

Through phpmyadmin you can click on the system table, which contains a row for each module. Scan down the rows (it might be several pages depending on how many modules you have) unril you find the row for module panels mini. Click the pencil icon. Then the row will open up and you will see the data for it. You will want to change the value of the status field from 1 to 0. 1 means the module is activated and 0 means it is turned off.

I found that I also had to empty the cache tables. Select each of the cache tables and then empty them. Do not DROP them by mistake!

After that your site should hopefully come back to life.

nikkubhai’s picture

Thanks Christopher! I disabled mini panels and I don't see the error now.

For others facing the same prob, in order to empty cache, log in as admin and go to yoursitename/update.php .

jason89s’s picture

Clearing all caches fixed the problem for me. I had to manually type into the address bar /admin/config/development/performance to clear the caches because of white screens of death when viewing any non-admin page behind the overlay. I didn't have to disable any modules.

Sylense’s picture

I was able to work around the issue by the same steps. Disabling mini panels in phpmyadmin, emptying the cache tables, and then once I was able to login I flushed all caches just to be sure and my site is back up running panels and all. I wonder what the conflict is with the 7.2 upgrade ???

Anticosti’s picture

subscribing

davidsanger’s picture

subscribing

paulgemini’s picture

subscribing

paulgemini’s picture

Temporary solution that allowed me to deactivate mini-panels without going into the database:

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

drupaljohngo’s picture

Yest this worked for me as well. My panel content disappeared. I also upgraded to the newest dev versions. some modules I installed only the recommended beta version. I upgraded the core with drush and backed up the appropriate files and made .htacess and robots.text copies.

After disabling mini-panels the content reappeared.

Rock on!!!

marcvangend’s picture

I had a similar problem with the Feeds module. The cause seems to be that files containing class declarations need to be listed in the module's .info file in order to enable class auto-loading; see #1169986-12: Fatal error: Class 'FeedsPlugin' not found. If this assumption is correct, adding files[] = plugins/export_ui/ctools_export_ui.class.php should fix the problem for ctools as well.

cutmedia’s picture

subscribing, this is not fixed and is a major problem when upgrading to 7.2

sksmithson’s picture

I just cleared the caches. Mini Panels is working fine now.

merlinofchaos’s picture

CTools' plugins utilizes a hook provided by core to auto-register classes belonging to plugins.

It would seem that something in Drupal 7.2 has messed this hook up, because this is widespread. Clearing a cache fixes it, which suggests that sometimes it works and sometimes it doesn't.

robxu9’s picture

subscribing

cpelham's suggestion worked! :D

vabue’s picture

Same problem, subscribing.

sun-fire’s picture

The same problem. Subscribing.

snjogu’s picture

Title: After updating to Drupal 7.2, Fatal error: Class 'ctools_export_ui' not found » After updating to Drupal 7.2 Fatal error: Class 'ctools_export_ui' not found


Fatal error: Class 'FeedsPlugin' not found in

Hi, clearing the cache makes it even worse.(Works now fails later) .I had to disable(actually delete feeds module) for ma site to come up again.I desperately need that feeds module back. Give me some more ideas,please.

And the version is actually Drupal core(7.2). Had the same issue with 7.0.

cbherr’s picture

I dont want to disable mini panels because that's how a draw content for my homepage. Any recommendations? Clearing cache didn't work.

daviesap’s picture

Disabling the module by hand (directly within the database) and clearing caches did not work for me.

Couldn't get into my site at all.

Great.

This did the trick though (as found above)

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

What's the permanent solution. What a lot of time wasted on this.

merlinofchaos’s picture

Status: Active » Postponed (maintainer needs more info)

Naturally, when I went to upgrade a dev site of mine, I was unable to make this happen.

It's really difficult to tell what is really going wrong here. It *looks* like the class registry cache is somehow getting generated incomplete, which is causing autoload to fail. I do not, however, understand why this might happen. Perhaps there is some order of cache clearing that's failing.

Since I couldn't reproduce it locally I'm at a bit of a loss.

It would be awesome if somebody has some way to reliably make this happen. Installing things in a certain order, perhaps, or a particular set of modules?

merlinofchaos’s picture

Here's a question: people experiencing this, do you disable modules when running update.php?

marcvangend’s picture

@merlinofchaos: when I had a similar problem with Feeds module (see #14), no, I didn't disable modules.

parksan’s picture

Same problem after update 7.0 to 7.2,
try with "temp solution"---http://drupal.org/node/1139732#comment-4526448,

but when i flush the caches , i got another problem as following alert:
"Fatal error: Cannot redeclare ctools_export_ui_list_form() (previously declared in /home/content/i/t/p/itpro5166/html/piaozhiyuan.com/sites/all/modules/ctools/plugins/export_ui/ctools_export_ui.class.php:1289) in /home/content/i/t/p/itpro5166/html/piaozhiyuan.com/sites/all/modules/ctools/plugins/export_ui/ctools_export_ui.class.php on line 1292",

as a fresh for Drupal, i don't have any ideas for them, who can help me?

thanks so much!

KirstenLangholz’s picture

#27 Can confirm the same error messages.

snjogu’s picture

what version of ctools are u running?

gatman’s picture

No problem in upgrade to 7.2 - modules disabled.

Error occurs on update from ctools-7.x-1.0-alpha4 to ctools-7.x-1.0-beta1. Module not disabled on update (wasn't aware that was SOP)

Mini-panels disabled as temp measure.

merlinofchaos’s picture

In another thread, someone posted a backtrace which showed this happening during a styles module update hook. Is anyone experiencing this NOT using styles module?

cpelham’s picture

I'm using Styles module and I did not turn off modules prior to updating. It was my (perhaps erroneous?) understanding that we did not need to turn off modules for point upgrades, only for major upgrades.

merlinofchaos’s picture

You do not need to turn off modules. I actually recommend against turning off modules, I'm just checking to see if that's happening for some people.

merlinofchaos’s picture

Other questions:

PHP version? Are you running APC?

merlinofchaos’s picture

Does anyone have a site where this is currently happening that I could investigate? Without being able to reproduce this, I am totally stumped.

merlinofchaos’s picture

#27: Your temp solution should use include_once() not include() -- that will solve your secondary problem.

Anonymous’s picture

subscribe.

i'm also having issues reproducing this. can anyone who can reproduce this post a copy of the 7.0 db and the 7.2 db?

dimmech’s picture

Same issue here. Updating Styles module after a 7.2 core update triggers this behavior for me. At First, Drupal attempted 4 updates after installing styles then produced the 'ctools_export_ui' not found error. I cleared the caches then tried the update again this time there were only 3 updates pending. Apparently the first of the 4 updates took I guess because it does not show up anymore. Anyhow styles will not update past this point in the process

file_styles module
7210 - Add support for media objects.
styles module
7215 - Delete duplicate entries from the styles table.
styles_ui module
7206 - Change menu.

I just posted this in hope this helps track down where things are breaking.

Anonymous’s picture

#38 was useful for me in terms of reproducing this.

1. D7.0 site with feeds, ctools, styles
2. update code to D7.2
3. run update.php, all is fine.
4. here's the trick - run update.php again, even though there are no pending updates, and you'll get a nice green "no pending updates" message
5. your site is hosed, fatal error for feeds plugin.

merlinofchaos’s picture

Status: Postponed (maintainer needs more info) » Active

Ok, justinrandell and catch finally figured out precisely what is causing this. Everyone rejoice. The bug is in core and right now, hitting update.php can screw up the class registry.

The only solution is to force a full registry rebuild. That can be difficult to do. The simplest way to this is to edit your index.php:


/**
 * @file
 * The PHP page that serves all page requests on a Drupal installation.
 *
 * The routines here dispatch control to the appropriate handler, which then
 * prints the appropriate page.
 *
 * All Drupal code is released under the GNU General Public License.
 * See COPYRIGHT.txt and LICENSE.txt.
 */

/**
 * Root directory of Drupal installation.
 */
define('DRUPAL_ROOT', getcwd());

require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
// Add this line right here:
registry_rebuild();
menu_execute_active_handler();

Edit your index.php to include the registry_rebuild() after the drupal_bootstrap() call. Hit your site ONCE and then put your index.php back the way it was. Your site should return to normal.

Until this is fixed in core, you will need to do this every time you hit update.php. So until this bug is fixed, I have to advise you to avoid hitting update.php.

merlinofchaos’s picture

Ok, webchick committed the patch to remove the registry_rebuild() from update.php. The next Drupal 7.x-dev will no longer be dangerous to hit update.php

steinmb’s picture

So all we need it to use this patch http://drupalcode.org/project/drupal.git/commit/624f5a7 to fix this?

merlinofchaos’s picture

Installing that patch will make update.php safe again. It will not, however, fix an already broken registry. You'll need to use my solution in #40 for that.

nfriend’s picture

I was able to get my site back up using the Index.php fix suggested (and after clearing my browsers cache for the site) however as soon as I try to login as any admin (user 1 and other) I get the message again. Am I missing a step?
Thanks
Neil

merlinofchaos’s picture

#44: Hm. I don't think you're missing a step. Once the registry is successfully rebuilt, as long as you don't hit update.php again the site should then work normally. Can you confirm the message you're getting? There have been several mentioned in the issue. I assume you're referring to the ctools_export_ui class not found?

nfriend’s picture

Fatal error: Class 'ctools_export_ui' not found in /home/percenti/public_html/gccorg/sites/all/modules/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3

It seems once I get this error I can't do anything until I clear my browsers cache - then I can use the site AND login as a non admin. I don't need to run the index.php again.

Neil

nfriend’s picture

Just an FYI - I have another D7.2 site that has ctools7.x-1.0-alpha4 and I'm not having the problem. I know Update ran all the way through right after I installed 7.2 - it's possible no other modules have required it.

Tried taking the site I can't access back to ctools alpha4 but makes no difference - hangs up with admin login.

Neil

nfriend’s picture

Okay sorry about the multiple entries but it turns out I was mistaken as the problem cropped up on the 2nd site as soon as I went to add a content type and then stayed there. However, the Index.php fix you shared worked fine and I was able to login and all is working.

So I tried clearing browser caches for other site - which I didn't do before running the modified index.php the last time but once again the admin login grabs the error. So what would an admin account do that would trigger this while an authenticated login wouldn't? Display Admin Menu?

Neil

merlinofchaos’s picture

You might grep your contrib modules for registry_rebuild() -- maybe there's another one somewhere that's also causing the problem?

nfriend’s picture

So if it runs a second time it can cause the problem again?

nfriend’s picture

The only reference I found was in the admin_menu so I deleted that module. I was able to then login as admin. But I had no menus and when I tried to access anything via command line like mysite.com/admin/modules I now get this error:
Fatal error: Class 'ctools_export_ui' not found in /home/percenti/public_html/gccorg/sites/all/modules/views/plugins/export_ui/views_ui.class.php on line 13

Which I think is a different line.

Getting close to going back to version D7 as I have spent too much time on this and not on real work. Certainly will be slow to go to D7.2 on other sites until I hear it's fixed.

Thanks for your help.

Neil

merlinofchaos’s picture

The ctools_export_ui not found problem is the same basic issue: The class registry is built incomplete. The method fix in #40 should fix it. If admin_menu is doing a registry rebuild in an incomplete state that certainly could be an issue, though I haven't run into that happening yet.

nfriend’s picture

Well the admin_menu folder is deleted, I ran the modified index.php again, I can log in as admin but I then get the error when I try various admin options though not all. Mainly I was trying to go to /admin/modules just to turn the core Toolbar back on since I don't have a menu but stopped by the "not found" error.

The rebuild looked like it did something... though apparently it's not rebuilding the registry 100% for me.

merlinofchaos’s picture

Are you certain you're putting the rebuild command after the drupal_bootstrap() function? It might also be valuable to put a drupal_flush_all_caches() right before it?

parksan’s picture

#36
thanks! try again.

parksan’s picture

My ctools version is 7.x-1.0-beta1.

I try with the #36's method--- "Your temp solution should use include_once() not include() -- that will solve your secondary problem."
Now, seems running normally.

thanks!

parksan’s picture

Everyone

I have another site, until today morning running correctly.

after update the following module
Styles UI
File Styles
Multiple Forms
something like these modules I installed right now.

got the alert as
"An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path:
http://www.***.com/blog/update.php?id=113&op=do StatusText: OK ResponseText: Fatal error: Class
'ctools_export_ui' not found in
***/sites/all/modules/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3"

I try with this temp solution---'http://drupal.org/node/1139732#comment-4526448'
Everything seems go back normally.

I assuming may be SOME ELEMENT LOSE THE PATH TO CALL 'ctools_export_ui.class.php'?
expect to ultimate patch

merlinofchaos’s picture

Yes, as is stated clearly, running update.php will cause this problem if you don't have the very latest Drupal 7.x-dev.

snjogu’s picture

Thought ma site was back on track after success with feedsPlugin only to be hit by the ctools bug.
Thanx to #40. the site is back for now[only if we don't hit 'update'].
Thanx, merlinofchaos. Keep up.
We definitely need permanent solution.

paulgemini’s picture

OK I followed the instructions here:

1. Added the lines to index.php and called it once. (#40)
2. Removed the lines from index php
3. Added that patch (#42) to Update.php and ran it.

This seems to have done something. The site is running a bit smoother...though I'm still having some odd issues manually checking for updates. And the Administration Menu loads erratically. Not sure if that's related, but figured I'd report it to see if anyone else has noticed it.

marcvangend’s picture

@paulgemini: "The site is running a bit smoother"? I'm not sure if your situation is related. This issue is about a fatal error, meaning it either works (problem solved), or it doesn't (fatal error).

paulgemini’s picture

Good point. I'm starting another issue elsewhere, though as a general FYI, I have two remaining problems since upgrading to 7.2:

1. Administration Menu is jerky and often doesn't show up (without pressing the "Stop" button on the browser).
2. Pages on the admin side load partially but the browser cycles endlessly (example: in Firefox, the spinning circle on the tab spins indefinitely. Clicking "stop" helps the site load.)

I have this issue on two sites. I've avoided upgrading on a 3rd site and am happy with that situation (though considering going to the 7.x dev when module start breaking).

This is my first time going through the new release process (I was using a site on 6.x for a couple of years), and it's been a huge learning curve, sometimes entertaining, but also quite frustrating. Out of curiosity - is it typical that a minor Drupal core bug-fix release causes so many problems? I ask not to be critical, but to understand whether it's preferable to wait for bug reports before the applying the next minor update. I didn't have any issues with my upgrade from 6.14 to 6.20 (or whatever it was), but I understand that at the 7.0 point, there are tons of moving parts in the module world and it's hard to anticipate whether a core update will interact with things that are updated every few hours.

merlinofchaos’s picture

No, this is not typical.

I assure you, it is just as frustrating on this end.

yareckon’s picture

Thanks for the amazing support you are giving in this thread merlin.

Well, I was very happy to see the initial change that update.php calls registry_rebuild because I had already been hit with a broken site twice when renaming a module folder. What is the long term solution for that problem if we can't update the registry on update.php because of this issue with class loading?

merlinofchaos’s picture

The long term solution is that Drupal 7.3 needs to have a proper fix for this so that update.php can rebuild the registry in a fully boostrapped environment.

Unfortunately for everyone, CTools is one of only 2 modules known to be implementing hook_registry_files_alter() so it very easily slipped under the radar when this went in. Plus, the problem is such an odd one, and it manifests in many strange ways. It is very difficult to trace until you figure out exactly what's causing it.

In the short term, upgrade to Drupal 7.x-dev, because that, at least, removes the registry rebuild from update.php. Also, apparently admin_menu can force a registry_rebuild at a bad time, though I am using admin_menu and I have not yet actually had this happen. I may not be running the proper version. This likely needs to be looked into a little more deeply.

Another possibility might be to write a piece of code to attempt to detect this condition, force a registry rebuild and then drupal_goto right in index.php. That could be somewhat dangerous but it seems like it could alleviate all symptoms of the problem until a proper fix can be had.

merlinofchaos’s picture

I just want to add: Lots of people have lost days of work on this problem. Thanks to all who are being patient and helpful. It has taken a lot of resources to pin down what happened here.

ohnode’s picture

happening at: http://artascious.com - also, Acquia Prosper by Fusion will not come up.
Fatal error: Class 'ctools_export_ui' not found in /home/crafter6/public_html/artascious.com/sites/all/modules/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3

merlinofchaos’s picture

And in contrast to my thank you, there's posts like #67 that apparently aren't interested in trying the solutions posted here.

#67: Please don't do that. Why add to the noise if you aren't interested in the solutions already provided?

marcvangend’s picture

Earl, you deserve a big "thank you" as well. You understand not only how Drupal works, but also how the community works. That's great.

Slaurel’s picture

#40 works for me Thanks !

After updating Ctools with a drupal 7.2 I saw an error during the update.php process, but was able to access and use my website. It's only at the end of the day that the first white screen appeared.

I was able to "access" to my site by switching off module (in the database) and switching on after.

And the same error happened few hours after.

thankfully #40 solution has made my day !

#65 long terme solution

I might be wrong but I will wait for drupal 7.3 or a fix than the very latest Drupal 7.x-dev.

Thanks Merlinofchaos for Your Time and your work

newtoid’s picture

+1 subscribing

sachbearbeiter’s picture

thanks for #40 - saved me a lot of time :)

Andy B’s picture

subscribing

tvb’s picture

#40 saved my day! :-)

Drupal core 7.2
Chaos tool suite 7.x-1.0-beta1

nathanghart’s picture

I tried the steps from post #40, but I get this error when running the index.php page for the first time

Additional uncaught exception thrown while handling exception.
PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: SELECT 1 AS expression FROM {variable} variable WHERE ( (name = :db_condition_placeholder_0) ) FOR UPDATE; Array ( [:db_condition_placeholder_0] => drupal_js_cache_files ) in variable_set() (line 804 of /nfs/c04/h01/mnt/67778/domains/[domain].com/html/2011/includes/bootstrap.inc).

Anyone else get the same or know what the problem is with this?

mcbjam’s picture

khiminrm’s picture

Subscribe

webchick’s picture

Status: Active » Closed (duplicate)
cpelham’s picture

Status: Closed (duplicate) » Active

Webchick, let's leave this issue open for now (at least until the other issue actually provides a working solution or work-around) because this one is, I believe, the only place to find the means of recovering one's site from this boondoggle.

As you are you, and D7 leader, I mean no disrespect, and if my statements or reasoning are flawed, then I apologize.

webchick’s picture

Ok, fair enough. :) I was just trying to do some housekeeping. No worries!

jackhutton’s picture

thanks for the input here;
I posted this comment http://drupal.org/node/1191082#comment-4613610
and melinofchaos referred me to this post;

ran through the steps..
w. views 7.x 3 dev version
and the Drupal 7.x-dev version posted manually..

the content page - listing of contents - filtering contents page ...
does not render..

i've attached a txt file w.the full error page..
the first couple of lines of the rendered page


Fatal error: Call to a member function pre_render() on a non-object in /home/sites/all/modules/views/includes/view.inc on line 992
Executed 44 queries in 13.38 ms. Queries exceeding 5 ms are highlighted.
ms
#
where
ops
query
target
3.76
5
DrupalDatabaseCache::getMultiple
P A E
SELECT cid, data, created, expire, serialized FROM ra_cache_bootstrap WHERE cid IN (:cids_0)
default
0.1
1
language_list
P A E
SELECT * FROM ra_languages ORDER BY weight ASC, name ASC
default
0.29
5

I've flushed the cache.. before & after.
when I do I consistently get this series of error messages..

Warning: Invalid argument supplied for foreach() in field_views_field_default_views_data() (line 206 of /home/sites/all/modules/views/modules/field.views.inc).
Warning: Invalid argument supplied for foreach() in field_views_field_default_views_data() (line 315 of /home/sites/all/modules/views/modules/field.views.inc).
Warning: Invalid argument supplied for foreach() in field_views_field_default_views_data() (line 315 of /home/sites/all/modules/views/modules/field.views.inc).
Notice: Undefined index: nid in view->fix_missing_relationships() (line 426 of /home/sites/all/modules/views/includes/view.inc).
Warning: Invalid argument supplied for foreach() in field_views_field_default_views_data() (line 206 of /home/sites/all/modules/views/modules/field.views.inc).
Warning: Invalid argument supplied for foreach() in field_views_field_default_views_data() (line 315 of /home/sites/all/modules/views/modules/field.views.inc).
Warning: Invalid argument supplied for foreach() in field_views_field_default_views_data() (line 315 of /home/sites/all/modules/views/modules/field.views.inc).

I have not run 'update.php' - but w the posted 7.x dev june 15th, is it ok to run update.php w/out a patch?

thanks for the feedback..

basicmagic.net’s picture

subscribe

rlaszlo’s picture

subscribe

rfay’s picture

If you find yourself with a broken registry, you may not be able to use #40 because you can't even bootstrap the system. (That's the situation I found myself in due to #1190842: 7.x-2.0-beta2 (and 2.1) breaks EntityAPI.)

I made Registry Rebuild as a workaround for this. Instructions are on the project page. It's pretty easy and it avoids hacking at your core.

AndyZhang’s picture

subscribing

l33tdawg’s picture

+1

andrebonfanti’s picture

subscribe

kehan’s picture

subscribe

MyXelf’s picture

Subscribing...

omercioglu’s picture

sub

jarush’s picture

Thanks #40.
Subscribing...

webchick’s picture

Status: Active » Fixed

This should be fixed in 7.4 now. The offending patch was rolled back. Though affected sites may still need http://drupal.org/project/registry_rebuild.

GStegemann’s picture

I performed a registry rebuild. But when updating translations I get this error:

Ein AJAX-HTTP-Fehler ist aufgetreten HTTP-Rückgabe-Code: 200 Im Folgenden finden Sie Debugging-Informationen. Pfad: /cm7/de/batch?id=489&op=do Statustext: OK Antworttext: Fatal error: Cannot redeclare ctools_export_ui_list_form() (previously declared in /var/www/html/cm7/sites/all/modules/ctools/plugins/export_ui/ctools_export_ui.class.php:1289) in /var/www/html/cm7/sites/all/modules/ctools/plugins/export_ui/ctools_export_ui.class.php on line 1292
rfay’s picture

@GStegemann, you have a damaged ctools, I suspect. Please remove it and reinstall again. Followups should not be in this issue though, because it has nothing to do with what's going on here, AFAICT.

Status: Fixed » Closed (fixed)

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

chichio9000’s picture

Thanks #40

lukus’s picture

A reg rebuild did it for me too .. sub.

ckopack’s picture

Registry rebuilding is easier now and fixed my problems. Thanks to the peeps who put this together:

http://drupal.org/project/registry_rebuild

And yes thank you #40!

synistics’s picture

Read through everything, the client's site is throwing a similar error on panels, but before I head down the road of #40 and reg rebuild, one question.

They are currently running on 7.12 and I will be moving them to 7.14. Has this been committed to core or will I need to do this anyway?

TIA

hollyfox’s picture

Thanks #40. This worked on my site after I restored it and kept getting a fatal error when going to my spaces.

krishnaveni.t’s picture

Added
registry_rebuild();
in update.php is solved this issue for me.

jwilson3’s picture

Issue summary: View changes

Encountered this during updates from an ancient site with (149 pending database updates!!!?!)

Neither #40 nor http://drupal.org/project/registry_rebuild (with drush) did not work for me due to other unrelated issues with other modules.

However, I found that adding registry_rebuild() to update.php #101 to work perfectly.

I know that previously there was a core issue #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap that added this line to update.php, and later removed this line due to other issues (not sure what, but possibly security?) So, if you add this line to update.php to fix the issue, you probably need to remember to remove it.

oknaru’s picture

trying since last two days not able to move forward with the following erro
Fatal error: Class 'ctools_export_ui' not found in /hermes/walnaweb02a/b870/moo.xxxxusacom/openatrium/profiles/openatrium/modules/contrib/panels/panels_mini/plugins/export_ui/panels_mini_ui.class.php on line 3

seemas’s picture

I have found a quick hot-fix that looks similar to other issue on https://www.drupal.org/node/1139732#comment-10631376

yogaf’s picture

#104 worked for me. thanks @seemas.
INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES
('ctools_export_ui', 'class', '%%%%%%/ctools/plugins/export_ui/ctools_export_ui.class.php', 'ctools', 0);

%%%%%% - replace this with the path prefix to your file.

jvieille’s picture

I experiment this bug on D6.
Running update.php always blanks a particular panel (not all).
Flushing class registry fixes it.

However, it also happens in other circumstances - not sure which ones.

leymannx’s picture

For me it simply was drush updb first, then drush rr that fixed the problem.