I don't want to put anyone on the spot, so I am not going to post examples, but I have been pondering something lately.

I have seen a decent number of questions where people have provided answers that go something like:

It looks like the Foo module should work for you.


I think the Foo module does this.

In some cases, it is obvious that the user googled for a solution and posted it. In others, there are other clues that the user knows about the module and what it does but doesn't have direct experience with it.

Should people be recommending modules that they have never used?

On one hand, helping the user is the end goal, so if it is correct, then it is a valid answer. Joel/Jeff have a meta or blog post about this, but I can't find it right now.

On the other hand, should people be posting answers that they don't know are correct, or at least posting them without a disclaimer?

I have no doubt that I have posted an answer recommending a module I haven't used before, so I am not claiming to be perfect here.

Given that so many questions can be solved by using an existing contrib module, I am curious what other's thoughts are on this matter.

3 Answers 3


It depends on the module. I'd have no problem recommending the Override Node Options module to someone if they needed more granular permissions for Sticky/Promoted settings. However, I don't use those settings, so I wouldn't need the module.

The amount of research one puts into the answer is not always related to its correctness, and if it is incomplete or incorrect, it will be downvoted as such.

  • Or the answer suggesting the module that is more helpful for the OP will be accepted.
    – avpaderno Mod
    Commented Apr 11, 2012 at 10:50

It depends from the question, but I generally don't see any reason why the user who is reporting a module the OP could use should answer only if the module has been used before.

Clearly, who used the module before can report any issue found using the module, and can also suggest what release of the module should be used (e.g. the beta release, or the development snapshot). The user who used the module described in the answer should give more information that is useful for the OP to understand if the module is worth using it.

Depending on the module, it could be helpful to describe the steps necessary to achieve what the OP is trying to do, or at least point to some specific settings the OP should apply. To make an example, supposing the answer for the question is the Views module, an answer that just says "You should use the Views module" is less useful than an answer that gives some hints about which view settings the OP should use.

Sometimes, when I find the module the OP could use, I install it on my test site, and see if it is straight to achieve what the OP is trying to do. If it is not, I consider adding the necessary information to the answer.

As side note, most of the questions asking for a module don't report what modules they tried. That leads me to think they didn't even search for a module to use, and that would explain why they accept answers that don't report more than the module name, and (eventually) the excerpt of the description given in the project page.


I'm in agreement with the two users who have already posted; as long as the rationale for recommending a module is well thought out then there's no reason why someone shouldn't recommend a module just because they haven't used it. It might be good to state "I've never used this module but I think it's worth trying because ..."

On a more general note, navigating the vast number of modules available on drupal.org is tricky and must be almost impossible for new users. More experienced users could really help by explaining the rationale behind modules they pick - e.g., "it's written by X" or "it's used on such-and-such a production site" - as this would help newer users develop their own way of deciding which modules are worth trying and which aren't.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .