On Sep 12, 2007, at 2:17 PM, Larry Garfield wrote:
A single Drupal module to act as a controller / central repository for jQuery plugins, so that we don't have a dozen Drupal modules with the 20 lines of PHP (or whatever) needed to bootstrap the module just to call drupal_add_js().
Just to be clear, what I was proposing in the other thread about update(_status)? + jQuery plugins was that each jQuery plugin would have a .info file, and an *empty* .module file, only so that it showed up like a module with respect to update(_status)? and that the existing client code could check for newer versions of the plugins. My proposal wasn't at all concerned with the code to actually call drupal_add_js(), and I agree that a single plugin-manager would be better than a bunch of duplicated code for that. That said, the single plugin manager might be able to handle the case that the empty .module files was meant to address, and populate the {system} table with some new records for each plugin, just so that update(_status)? knows they exist and can look for new releases... Alternatively, we *could* modify the update(_status)? code to better handle this case, and, for example: a) allow checking for updates on modules that are present on a site but not enabled (i think there's already a feature request about this, in fact) b) allow it to find .info files directly, not just the .info files associated with modules (and, in D6 update.module, themes), so that *anything* with a well-formed .info file could be included in the available updates report. Cheers, -Derek (dww)