[D7] CacheFlusher

There are over 8000 modules in the Drupal contrib space, which can often lead to new user confusion as they try and figure out which of 5 similar modules is the best one for their use case. As such, duplication of module functionality has become a hot topic within the drupal community; which has adopted a mantra of 'Collaboration vs. Competition'.

The How to Review Full Project Applications contains the following statement:

Module duplication is a real problem on drupal.org, and continues to grow. Again, to ensure that the code on drupal.org is useful to the community of people using Drupal, it is important to ensure that module duplication is avoided.

As the functionality of this module is a complete duplication of functionality provided in 'Devel', I'm afraid it doesn't meet the 'duplicate module' check which is a key component of this review process. In addition, the code doesn't really contain enough substance for a reviewer to get a true sense of your understanding of the Drupal APIs. (I'm not suggesting that you don't understand them; only that it's difficult to confirm your understanding in 35 lines of code.)

However, I certainly do appreciate the motivation for such a module, and that many people would value having this capability without needing to install the full 'Devel' module ... to this end, I would encourage you to consider submitting this as a development code snippet or tip in the 'Module HowTos' section of the Drupal developer's documentation.

I misspoke ... While your module doesn't duplicate 'Devel', the functionality of your module is completely duplicated by 'Devel'.

For users that do not want to use a block, they can install Devel and create a custom menu item pointed at 'devel/cache/clear'; without needing to enable the block.

The duplication argument is not mine ... and I've argued that it needs to be slightly relaxed ... but your point regarding duplication in other modules is exactly why the duplicate module check is being strictly enforced in the code review process. Once approved, each contributor has the ability to create projects without restriction - one of our roles is to ensure that they fully appreciate the desire to reduce duplication (and the confusion that it creates for users) before being 'turned free', so to speak. For more background on this initiative, I'd suggest checking out webchick's presentation from DrupalCon Copenhagen, or dman's Open Letter to Maintainers.

I'm not trying to discount the usefulness of your contribution ... but consider the implications of a dozen contributors coming forward with other very specific modules which duplicate functionality included in Devel. Before you know it, we have individual modules for clearing the cache, executing PHP code, editing variables, rebuilding menus, and reinstalling modules ... and the 8000+ modules in the Drupal Contrib space very quickly becomes 16000. It's a slippery slope, and thus we've been guided to strictly enforce the no duplication policy.

If you'd prefer, I can certainly request a second opinion from members of the Code Review group ... but a brief tour through the Project Application Queue will show this same conversation occuring in a dozen applications.

I still agree that the community could benefit from the approach contained within this module ... please consider posting it as a code snippet within the Drupal documentation - but I'm afraid that I can't see any of the git administrators vetting this application, for the same reasons I've outlined in this review.

Thanks for your understanding, bhosmer.

I actually brought the question up in IRC, assuming that there must be a reason that the core 'clear caches' functionality was made a button/form, instead of a link. The general consensus is that a permission alone wouldn't completely protect you from cross-site request forgery, and having the 'clear caches' item as a menu callback could leave a site open to a possible denial-of-service attack on a large site (by never letting the cache get established).

The way around this would be to generate a callback with token verification; but I don't believe this tactic is currently used in core ... creating it as a form button (with built-in validation via the Form API) accomplishes the same thing, and is the generally preferred approach.