Cannot disable module

I tried this issue and couldn't reproduce it. The module is turned off correctly and become available on Uninstall page. I have Drupal 7.14

Thank you @ardas I also confirm that I can't find any traces of the module remaining after an uninstall as we even clean up the user tables.

@scrap2000 is there maybe some administration module you are using that may be causing the problem, we are all about the log in process and have no concerns with what is happening on the module page. Feel free to reopen this issue but kindly give us a step by step account leaving no room for us to stray. A list of enabled modules, user privileges, the host operating system details, database version etc will all help us to help you.

Thank you for taking the time to lodge this complaint please do not let this discourage you or feel that we don't appreciate the effort in anyway.

Keep up the good hunting! =)

I have a similar issue.

I have a site with 10.000 users.

When I try to disable the module, PHP throws an error : max execution time is exceeded (in my case 120 seconds which is quite big!).

I think the problem comes from remember_me_disable() which loads the whole list of users (hopefully I don't have many fields for each user, else I can't imagine how much memory this woulc consume).
And then, within a loop, each user is saved to empty the remember_me variable.

Maybe something could be done there to allow sites with many users to disable the module.

I have the same issue. Ideally the whole back end should be rewritten to use a separate table, but it a lot of task. So what I did are:
- do not call unnecessary user_save(), it's a very expensive call, so only call when there is actually data to remove.
- add an extra 5 seconds time limit for each user_save(), so this script basically could run forever, it might take very long to finish though.

Nicely done!

It won't run forever only for as long as it takes to process all users.

What happens if it takes longer than 5 seconds to save this user and before the next user to save is found.

The timeout is not because of user_save, I do agree with your assesment to only save when needed, but the problem is with many users, and which has not been solved.

Lets move the time limit outside the if statement and leave it 5 seconds I'm fine with that, if this single user cannot be processed in 5 seconds the script should fail.

We can get fancy and verify if all users were processed before exit and add watchdog log of success or failure but I think we have enough comments already and what we are doing is straight forward and simple enough that it doesn't need to be spelled out.

Great discovery you rock!

Hi, here's my fix for this. My problem was that user_load_multiple(FALSE) takes too much memory on the server because it tries to load all data of all users. To prevent that, individual users are loaded and the cache for them is reset each time. I've integrated the previous patch into mine, and most of the comments on that patch, I think.

I have tried both of the above patches. The older one still timed out while the second one did not apply. I have manually applied both of them and that has worked and enabled me to remove this module. I attach the patch resulting from my manual edit, in case you are following the security notice from today to remove this module. I wish there was a replacement one...

This still won't work, a site could have hundreds of thousands of user records, there's simply no reason to work that way.

How about updating the hook_uninstall() to erase values in the 'data' column for various forms of serialize(array('remember_me' => TRUE)) or serialize(array('remember_me' => FALSE))?

Here's a patch that directly removes the remember me flag from the serialized data on the user. Feels a bit improper but will allow the disable process to complete without hammering the system so hard.

Another appoach I considered was to use a Drupal Queue so that all of the work didn't have to be done immediately. Of course this wasn't possible because if the module had also been uninstalled the queue manager wouldn't have access to the queue worker any longer.

Hence, I submitted that hacky thing above...

@Ashley: That would corrupt the data because the number of items in the data array would change.

Of course it would @Damien, silly me! Hmm maybe that was a bit optimistic...

Here's a similar approach, which properly re-serializes each user's data (if they have the flag).

On my local install, this reduced time to run from 30 mins to about a minute.

Should have updated to Needs review. Doing that review now...

Massive improvement in performance. Our drush dis remember_me was taking about 4 minutes. With this patch that's reduced to a handful of seconds. We have heavily modified user objects and this doesn't appear to have messed with any of the existing data either.

I'm thinking this is RTBC.

Included in the latest release. Thanks to everyone who contributed and sorry for not checking this earlier!