Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
search.module
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
22 Mar 2011 at 16:46 UTC
Updated:
3 Jan 2014 at 02:58 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
agentrickardSee http://api.drupal.org/api/drupal/modules--node--node.module/function/nod... for an example of the problem. It blindly returns a count.
If this is by design, that also needs to be documented.
Perhaps we should add a 'status' element to the return array instead.
Comment #2
jhodgdonI don't think this is necessary actually. The search module only invokes this hook on active modules -- see search_admin_settings()
http://api.drupal.org/api/drupal/modules--search--search.admin.inc/funct...
Right? So I don't think it's a problem if the hook doc stays how it is, and I don't think this is causing the other related problems you linked to?
Comment #3
agentrickardSearch module is not the only thing that invokes this hook. Contrib can as well.
Drush, in the issue above, is assuming that 0 will be returned for inactive search modules. Drush is wrong because the API is unclear.
I can prove that hook_search_status returns non 0, and the question is: do we put the burden on the calling module? If so, the hook docs should explictly say so.
Comment #4
agentrickardRead the current docs. The way they are written, it's up to the hook_search_status() implementation to return 0 if disabled. If so, that's implemented wrong in all cases.
Clarifying the docs is much easier.
Comment #5
jhodgdonWell... We can clarify the docs if you like. Changing how the API actually works for D7 at this point is a non-starter. I would also just point out that none of the other search hooks say anything about whether the search module is active or not. The individual module doesn't really know this -- search.module takes care of all the invoking of hooks and dispatching. If some contrib module is doing something other than what search.module does for hook invoking etc., then it's not really core's problem...
But OK, we can add something to say that the module doesn't have to check to see whether it's actually active or not. I am not thrilled with the exact language proposed in #4. How about something more like:
Implementing modules do not need to check to see whether they are active modules or not when calculating their return values, because search.module only invokes this hook on active modules.
Comment #6
agentrickardDrush is a bit more advanced than a random contrib module. Since they got it wrong, I suspect others will, too.
I prefer to warn them, since we can. The language you propose does at least suggest that. A slight reword might make that stronger.
Comment #7
jhodgdonThat wording is fine with me. Just needs a patch...
Comment #8
agentrickardYup. Hopefully a new contributor can do it. (Hence the novice tag).
Meta question: Do we have a general policy on hook documentation? There are two sides to a hook:
1) How to implement the hook.
2) How to properly call the hook.
We consistently do #1, but not #2. Is there a firm rationale for not doing so, or should I put that on my D8 target list?
We can open a new issue to discuss...
Comment #9
jhodgdon#8 - definitely a separate issue.
Still needs a patch with the wording on #6.
Comment #10
Reidsy commentedComment #11
agentrickardHooray! And a new contributor at that.
Comment #12
dries commentedCommitted to 8.x. Thanks Reidsy.
Comment #13
jhodgdonThe patch that was submitted and reviewed contains a grammatical problem. Can someone please fix that?
Implementing modules do not need to check whether they are active calculating their return values.
Some word needs to be added between active and calculating, like "when".
Comment #14
agentrickardJust needs a 'when'. Oops.
Comment #15
clayball commented'when' added :-)
Comment #16
jhodgdonThanks! This goes into 8.x.
Then we need to put the issue back to 7.x and make a patch combining #15 and #10.
Comment #18
clayball commentedI see what I did.. sorry, rookie mistake. I'll fix it soon and submit a new patch.
Comment #19
clayball commentedActually, I just redid this and came up with the same patch. I don't understand why it failed.
I'm new here so thanks in advance for your help and patience.
Comment #20
scor commentedI'm not sure you did something wrong cwells73, it seems the testbot was not able to retrieve the patch.
#15: 1101678-15-hook_search_status-fix-text.patch queued for re-testing.
Comment #22
jhodgdonThis test failure in the Comment module is not related to the patch. Another glitch...
Comment #23
jhodgdonComment #24
jhodgdon#15: 1101678-15-hook_search_status-fix-text.patch queued for re-testing.
Comment #26
jhodgdonThis is a doc-only patch. The patch applies. There is apparently something wrong with HEAD and a test is failing, which obviously has nothing at all to do with this patch. Let's just get this in (d7/8).
Comment #27
jhodgdonSorry. 8.x only. Then please mark "to be ported" for 7.x, because we need to get a combo of the fix in patch from #15, and the original patch from #10, in D7.
Comment #28
clayball commentedHere's a patch that combines the patched in comment #10 and #15 and is backported to D7.
Marked as 'Needs Review'.
Comment #30
jhodgdonPlease don't make the 7.x patch until the 8.x patch has been accepted. It is confusing for both the test bot and the comitters.
Re-attaching the patch in #15. Which is RTBC for 8.x only (assuming the tests pass).
Then please mark 7.x - patch to be ported, at which time we can re-attach the patch in #28 and run it through the test bot.
Comment #31
jhodgdonfix typo in tag
Comment #32
webchickWow, confusing. :)
Ok, committed #30 to 8.x. Moving back to 7.x.
Comment #33
jhodgdonRe-attaching cwells' patch from #28 to see if the test bot likes it.
Comment #34
jhodgdonIf the test bot is happy, this patch is RTBC for Drupal 7 (fixed already in Drupal 8, see above).
Comment #35
webchickCommitted to 7.x, too. Thanks!