Wondering if I might actually just be missing something, as I am not seeing this issue by anyone else.
Installed Notifications 4.0-beta7, turned on some of the modules, all that I thought would be needed so far. Since, this site is currently only in building phase, there are many things I am working on at once, and went to my user profile, then subsequently to every user's profile to make sure that this error was there also. But alas, this is the error I had received.
Fatal error: Class 'Notifications_Subscription' not found in /path/to/sites/default/modules/notifications/notifications.module on line 646
Did some clicking around to see if the error was just on the profiles pages:
admin/messaging/notifications/events gives this error;
Fatal error: Class 'Notifications_Event' not found in /path/to/sites/default/modules/notifications/notifications.admin.inc on line 444
admin/messaging/subscriptions gives this error;
Fatal error: Class 'Notifications_Subscription' not found in /path/to/sites/default/modules/notifications/notifications.manage.inc on line 272
this is where I had stopped looking for errors.
I tried a delete and reinstallation but I am seeming to get the same results.
Any insights?
Comments
Comment #1
zeezhao commentedI think last time I saw this error on a previous dev version, if you clear your cache it disappears. Try this.
Comment #2
aliyayasir commentedi am facing this issue too
Fatal error: Class 'Notifications_Subscription' not found in F:\wamp\www\iiwy\sites\all\modules\notifications\notifications.module on line 646
Comment #3
aliyayasir commentedits working after clearing my cache .
Comment #4
reikiman commentedI'm getting this error, too, but clearing the cache (drush cc) isn't fixing it.
Note: It's Notifications_Subscription, not Notifications_Subscriptions
Notifications_Subscription is listed at the head of notifications.module in the autoload_info hook. It's defined in a .class.inc file in the includes directory. From there it's used as a class several times without preceding it with some kind of load-this-file instruction. The autoload_info hook probably sets up some mechanism somewhere to, uh, autoload stuff. But I haven't been able to find that.
../messaging/includes/drush_hack.inc - contains what they call a "hack" to cause notifications to work. This "hack" is not documented in anything that I could find.
The messaging module has a dependency on the "autoload" module, but where is it located?
Ah.. the autoload module is mentioned on the project home page, but not in the .info file. http://drupal.org/project/autoload
Comment #5
dave reidComment #6
Crom commentedThis is happening to me as well after updating autoload to 2.0 RC1
Comment #7
jose reyero commentedPlease,
Don't change version, specially if its a different branch (2.x, 4.x).
Don't add into the mix development versions of other modules (Autoload RC?). If we need to update anything for new versions of Autoload, please add a different issue.
Now if someone still has this issue with Notifications 4.x-4.0-beta7, stable versions of all other modules, and after cache is cleared (manually, not sure whether drush actually clears this), feel free to reopen.
Comment #8
dgastudio commentedFatal error: Class 'Notifications_Subscription' not found in /home/u2911/domains/****/sites/all/modules/notifications/notifications.module on line 646
6.x-4.x-dev 2011-Jan-21
Comment #9
dgastudio commentedComment #10
dgastudio commentedsolved by rolling back to 4.x-4.0-beta7
Comment #12
miro_dietikerThis problem is still/again present in 6.x-4.x dev.
Can't find the reason why...
The only solution that i actually found was to do a full load of the files in hook-init.
Comment #13
miro_dietikerIt turns out that after adding those _init loads, the system has a next problem on e.g. node view...
Is this somehow dependent of module weight? Do i need to reinstall those modules? Or is it even differentally - some old weights where in DB of our test system and that's why it remained working after upgrade?
It actually seems to me that some modules depend notifications.module but are loaded too early...
Comment #14
miro_dietikerOhhh ....
It turns our that a drush cc all sometimes is NOT enough... Autoload does not know enough after that.
We need to cc all via the admin menu ADDITIONALLY to make it work cleanly!
This is very strange but makes sense:
drush doesn't use tools like APC and possibly acts on the DB cache, while apache might access an own cache.
Actually we're using cacherouter and define own rules for caching tables. However i would expect that both drush and apache use the same source.
Any idea?
Comment #15
jose reyero commentedIt seems it may be related to one of the following:
- Autoload version.
- APC, other advanced optimization or caching tools
- Module weights
Please, on next follow ups, report whether you are using any of these and which version.
Comment #16
miro_dietikerAs written, we needed to cc via drush AND via web browser.
This seems to be autoload+caching related.
I'll check what causes this issue and add it to autoload issue queue..
At least here some architectural things go wrong.
Comment #17
ryan_courtnage commentedFYI - I've seen errors like these when using autoload-6.x-2.0. They go away if you use autoload-6.x-1.4. I believe the autoload API is different for 2.0...
Comment #18
wouters_f commentedClearing thee cache did not solve anything for me.
uninstalling the notifications / messaging module and then
installing autoload and at last re-installing messaging and notifications solved it for me.
Comment #19
JoeMcGuire commentedFor a possible fix please see and review #1351782: Autoload classes not found on enable.