I have definitely discovered that US loses all its data whenever a module is enabled. I don't think this is necessary or desirable. I can *maybe* understand it on a new install of a never-before-seen module. However, it is totally unnecessary when an optional core module is enabled. I also know that I can drop in a new version of a module, without disabling it first, and US has no problem with that, so why should it have to rebuild its status if the module was disabled simply to bring in a new version? I also have modules (one of which is a contrib) that use hook_enable to reset options to the default, again, at the loss of US data. Is there some way to stop this loss of data?

Comments

dww’s picture

dww
we/he/they
commented
Status: Active » Closed (won't fix)

Currently, all the data for all modules is stored together in 1 giant array. It would be a lot of work (and a bunch more DB queries required) if we stored the data for each project separately. The safest (i.e. most likely to be correct all the time) approach is to invalidate the update_status cache everytime the modules page is modified, so that we re-fetch the data at the next cron job (or next visit to the update_status report) for all the currently enabled modules.

On any reasonable use case for a site, no one is enabling/disabling modules so frequently that this should be a problem. The only reason anyone would complain is if:

a) they're enabling/disabling modules all the time
b) they feel compelled to revisit the update_status report after each time they change something
c) they're so worried about bandwidth that they don't like the cost of re-fetching a bunch of XML files from d.o.

all 3 of those have to be true for it to matter, and i really can't find the concern to spend many hours refactoring the code to cache the data per-project instead of the current global array. not only would that risk introducing a host of new bugs, it would make the code more complicated to maintain.

for all these reasons, i'm setting this request to won't fix. if someone else wants to either provide 1) counter arguments, better yet 2) a patch, or 3) funding for this work, feel free to reopen this, but don't expect me to work on this myself for free.

cheers,
-derek