If you have devel, you could probably scan the query log for a close guess. As for the "launch a missle" scenario, consider simple things like Throttle, which will disable certain things - possibly even your monitoring. Nancy Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.
________________________________ From: James Benstead <james.benst...@gmail.com> To: development@drupal.org Sent: Sun, January 9, 2011 3:36:27 PM Subject: Re: [development] An automated way of locating unused modules? Thanks Gábor, that answers my question - looks like it might be an interesting and potentially useful project; I'll post back if and when I get some time to work on it. --Jim -- My IM and Skype details are at http://state68.com/contact On 9 January 2011 20:18, Gábor Hojtsy <ga...@hojtsy.hu> wrote: On Sun, Jan 9, 2011 at 8:58 PM, James Benstead <james.benst...@gmail.com> wrote: >> Although I agree with Carl that this is an administrative rather than a >> technical issue, I think that the module I have in mind would still be >> useful for site auditing purposes: for example, when taking over a site that >> has been put together by another Drupal shop. >> Assuming that such a module would be desirable, the question remains: would >> it be technically possible to build such a module? > >It is probably technically possible to write monitoring which gets to >**a close guess**. Whether a module is used or not can only be >determined in runtime environments. You can monitor the use of modules >(eg. inclusion of their files, last access time of their include >files, use of the module's strings for translation, etc.). > >However, assume a module's job is to launch a missile in case of >nuclear attack. That module will not be used / useful until a nuclear >attack happens, but then its value would be essential. So you can >monitor its use but whether in the given time sample the module should >have done something or not depends on its role. (Replace missile >example with sending mail notifications only under certain rare >circumstances, automated blocking of spammers on the site, things that >kick in when on high load, things that kick in when running site >updates but not on the runtime site, etc). > >Gábor >
