[drupal-devel] Module Review: spam_mtblacklist

[Earl Dunovant]

Probably opening a can of worms, but isn't there still work being done
on an installation system? That's where I'd rather have such checking
done...especially if you're checking for the existance and/or
structure of a table or two.


On Thu, 27 Jan 2005 21:12:01 -0600, D. Moonfire <lists at mfgames.com> wrote:
> I had a query, loosely related to this. I had this patch I was working
> on (mainly because it led to something I think would be very useful)
> that would allow a module to indicate if it had a requirement that was
> not being fulfilled (such as another activated module, a PHP library, or
> my personal problem, table structures). Since I haven't had any
> experience with adding patches to Drupal, I was lurking in the mailing
> list to get a feel for it.
> 
> Would it make sense to actually code up this? The basic idea was to
> create a hook (preload?) that is called only on the module selection
> page and only for activated modules. If the hook returns an error (I was
> thinking an array of strings error messages for translation fun), the
> module is automatically deactivated and a message is displayed.
> 
> As I original saw it:
> 
> spam_mtblacklist_preload()
> {
>   if (!module_exists("spam"))
>   {
>     return array("Requires the 'spam' module to be active.");
>   }
> }
> 
> I also thought it would be useful for the image module to precheck for
> the PHP libraries or functions. Or for the taxonomy_access module to
> make sure the patch is put in before it is activated. (Just ideas.)
> 
> Then, when the module is selected, it would automatically be unselected
> with an error message. This is still a rough idea (i.e. I haven't
> finished the code) since I'm a strong believer in implementing ideas for
> workability before posting feature requests, but is this something that
> would both fit somewhat into the Drupal framework and resolve this
> problem?
> 
> Cheers,
> Dylan
> 
> On Thu, 2005-01-27 at 22:48 +0000, Michael Jervis wrote:
> > Jeremy agreed it should be done as a separate module:
> >
> > >> I've been thinking, I intend to implement this as a new module that
> > >> requires the spam module and works with it to keep the code modular
> > >> and separate. I think this is the right way to go as it allows the
> > >> functionality to be totally removed if people don't want it.
> > >
> > >I agree it should be a seperate module.
> >
> > Sadly drupal's contrib system doesn't allow to distribute them together. (I
> > don't think)
> 
>