RE: [drupal-devel] Module Review: spam_mtblacklist
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)
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@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)
participants (2)
-
D. Moonfire -
Earl Dunovant