Some argue that the Update module should be disabled on production domains. This module works around this:
how http://drupal.org/project/prod_check

Comments

Gabriel R.’s picture

Gabriel R. commented

Thanks for adding it here :-)

Gabriel R.’s picture

Gabriel R. commented

I am willing contribute effort and $ to have this developed.

Gabriel R.’s picture

Gabriel R. commented

Wait a minute ... you are saying on the Droptor web site http://www.droptor.com/tour#module-report :

Verify you have every patch you need
The module report details the status of every install module
The complete Drupal module report, just the way you like it. Update data is updated directly from Drupal, regardless of the last time your site checked in to the update report.

So you already have your own index of module statuses! Why require the Update module on the checked site then?

jemond’s picture

jemond commented

Hey Gabriel,

I think that is an old FAQ that I need to remove. This was the case for a brief time when that feature was rolled out. There were performance regressions related to it, so I had to disable it. So currently it gets update data from your Drupal site. I will take a look at prod check.

jpe

Gabriel R.’s picture

Gabriel R. commented

I am serious about contributing to the development.

jemond’s picture

jemond commented

Hey Gabriel,

OK, cool. What did you have in mind? Would you be coding?

jpe

Gabriel R.’s picture

Gabriel R. commented

Yes, we could code, or donate for the coder.

Depends what the cost is and how usable the code is.

doublejosh’s picture

doublejosh commented

This would be a requirement for use of Droptor for me as well. I certainly won't be turning on Update on my live production sites.

omega8cc’s picture

omega8cc commented
Version: 7.x-3.x-dev » 7.x-4.x-dev

This would be a must have option for all BOA users, since Barracuda by default disables Update module on all sites in Aegir which don't have the dev. prefix in the main site name. This is to avoid a giant overhead, especially when you have a few copies of the site in various dev/stage platforms and there is no point in slowing the site with useless frequent checks for updates on all those sites. Now, because BOA forces the Update module to be disabled, it effectively disables also Droptor module, so people can't use it for other purposes besides the contrib/core updates check.

jemond’s picture

jemond commented

This is odd, as the Update module doesn't actually have any major overhead for normal use on a site. It's fine to leave this enabled on a production site. It's possible to get the data this module provides right from D.o, but it's a huge dataset that needs careful attention to handle well. It's on the to do list, just no public ETA.

omega8cc’s picture

omega8cc commented

It does result with overhead / even timeouts etc, if the visitor (logged in or anonymous) happens to trigger it because the cache has been cleared (on cron, which can be set to run often, depending on the user case, or manually by site admin) etc. This is why it is often recommended to simply keep it disabled for performance reasons on a production site at least, similarly like it is recommended to keep Views UI disabled etc.

omega8cc’s picture

omega8cc commented

What I have in mind here is not to duplicate the Update module functionality. Rather to give the site admin option to disable/enable such feature in Droptor, so it could provide other functionality also when the Update module is (optionally) disabled.

jemond’s picture

jemond commented

Drupal cron should be scheduled to run via a scheduler, it shouldn't be configured to be triggered by visits (aka D7 poor man's cron port). Unless you use PMC this can't happen. User visits don't trigger the module to update it's data; only admins on certain admin pages can cause this to happen. And that it just a few (or less) users on a site. Unless I'm missing something, the overhead just isn't there.