Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I tried to update Entity Registration 7.x-1.4 to 7.x-1.5 but couldn't proceed or navigate to any pages due to the following fatal error:
Fatal error: Class 'RegistrationTypeController' not found drupal...
When I switched back to 7.x-1.4 (was unable to update database) my site displayed again.
In the change log there is this:
Override RegistrationTypeController::export() to ensure our data fields get exported.
Do I need to do something prior to the update to go foward?
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | registration_fatal_error_class-2546836-6.patch | 1.96 KB | heddn |
Comments
Comment #2
gcbThat's strange. RegistrationTypeController is new, but it's in the lib directory there and you can see it getting included in registration.info. Can you confirm that when you upgrade you see this file:
And that the file is included in the .info?
If it is, you may need to rebuild your registry to get that file recognized. You can do that with drush: "drush rr".
Sorry about your trouble, and let us know what else you learn!
Comment #3
lias CreditAttribution: lias commentedThanks very much for your reply.
I dug a little deeper and the error seems to have been caused by a Rule that fired an email message when a registration was submitted.
The message was using the token: [site:url]node/[registration:entity-id]
When I replaced it with: [site:url][registration:url]
I was able to update the module.
What gave me a clue was this issue https://www.drupal.org/node/2230359.
-----
Comment #4
lias CreditAttribution: lias commentedComment #5
PascalAnimateur CreditAttribution: PascalAnimateur commentedI experienced this problem when upgrading from 1.4 => 1.5,
drush rrsolved this for me.Comment #6
heddnTwo things are needed.
1) A hook update to flush the registry.
2) A wrapper inside the hook_entity_info_alter to check if the RegistrationTypeController class exists.
Without the second, I cannot rebuild the registry because hook_entity_info_alter is called during a registry rebuild and the class doesn't exist in the drupal registry yet. The first is necessary because we need to rebuild the registry. One should not have to install rebuild_registry to update this module.
Putting a class_exists in there is safe because once all update hooks are run, cache is flushed. At that point in the cache rebuild process, the new files are in the registry and the entity info alter should function just fine. Bumping this to critical because the update path from <1.5 is broken at this point.
Comment #7
cweagansLGTM. This completely WSOD'd a client's site on update. This should go in ASAP and a new release should be tagged.
Comment #9
Greg BoggsI am unable to replicate the upgrade path issue in a Drupal Standard install. But, I've confirmed that the patch doesn't cause any problems. So, I've committed the patch to 7.x-1.x
Comment #10
Greg BoggsComment #11
heddnThanks for the quick commit. I wonder how much of this related to the use of panels and panelizer. I noticed those modules in the stack trace.
Comment #14
cartagena CreditAttribution: cartagena commentedJust want to say thanks to all for the module and the fix. Got rid of my WSOD, I'm grateful!
Comment #15
Sam MoorePatch in #6 worked for me.
My registration module was in the Commons profile, but all other details apply.