After updating the module I cannot access site.com/user

I ran into the same problem recently. Because I am on shared hosting, I don't have access to a shell so I cannot use drush.
But I have found this: http://drupal.org/project/registry_rebuild.
It worked very well for me.

We have this problem as well and are in a shared hosting environment. However, we can ssh and use drush.

What didn't work:

• drush cc all on docroot
• rebuilding the registry using drush rr,--which came back as 100% successful for the rebuild, but then we got the error again directly following the success message
• truncating our cache tables in the database

What did work:

1. uninstall Mollom completely from the site (which we did after copying over the database backup and reverting back to our master code)
2. removed Mollom from our new branch, switched to the new branch on our server, and made sure everything worked fine prior to the Mollom update
3. printed out Mollom settings and a list of all content that was using it
4. added the newest Mollom back to our branch
5. installed Mollom module
6. ran update.php
7. reapply Mollom everywhere we were using it and rekey all of our settings

Rebuilding the registry didn't work for me either.

This is a multi site setup. I updated mollom on site 1. That site still works.

But the other sites just get a white screen.

I disabled mollom on site 1.

I can't disable it on the other sites. I can't even log in because of the white screen.

How do I disable mollom in the other sites when I can't log on?

The sites are hosted at Bluehost.

Did anyone of you follow the regular procedure for updating a module?

1) Remove the existing module code/directory entirely.

2) Download and extract the new code into the former directory.

3) Run update.php

If you cannot access update.php after updating the module, because you did not log in as uid 1 upfront, temporarily change the $update_free_access in settings.php to TRUE. Do not forget to revert it to FALSE after running updates.

If you need to update a module on a site that involves a custom multi-site setup, then you need to double-check what tables are shared between your sites and re-run update.php separately on all of your sites.

In case re-running update.php on a custom multi-site setup fails for a subsequent site, then this means that the database tables of the Mollom module happen to be shared, but that info is not properly declared and propagated.

Also, if you're using Drush to perform updates, make sure that you're running the latest stable version.

@Sun, Yes. We followed the regular procedure, but in order to get the module to work we ended up having to completely uninstall the old version. Removing the existing module code and replacing it with the new module code, unfortunately, did not work for us.

This has happened to me on two sites so far when upgrading from the 1.x branch to 2.6. I upgraded with drush which does sun's 3 steps automatically (and clears the cache i believe.) On the most recent I ended up disabling mollom with drush and then "drush pm-uninstall mollom". I then enabled it again and set it back up with the keys and the adding the forms.

Not the end of the world, by any means, but hardly your optimal upgrade experience.