Closed (fixed)
Project:
Drupal core
Version:
6.x-dev
Component:
help.module
Priority:
Minor
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
10 Dec 2005 at 20:54 UTC
Updated:
13 Mar 2008 at 12:42 UTC
The current API documentation for hook_help says hook_help is called with a $section parameter with a definite set of values, enumerated on the page.
However hook_help is also invoked with at least two other non documented values:
- from the
admin/helppage, the hook is invoked with$section == 'admin/help' - from the
admin/help/<modulename>page, the hook is invoked twice:- once with
$section == 'admin/help#<modulename>'as documented - once with
$section == 'admin/help/<modulename>'which is not documented
- once with
While the second invocation on admin/help/<modulename> seems redundant and one of the calls might have to be removed or at least documented as obsoleted, the ability for the hook to be fired from the main help page is valuable in that it allows a module creator to insert documentation in the main help page, so the doc should be amended to specify that behaviour.
Comments
Comment #1
drewish commentedWould you mind posting a patch that begins to correct this? Having one would make it easy to start a discussion.
Comment #2
fgmIt depends on what core developers think is the right fix to bring:
admin/help#<modulename>be removed or documented ?admin/help/<modulename>be removed or documented ?admin/helpbe removed or documented ?because this makes for a different patch in each case, either to code or to doc.
IMHO, (3) should be documented, (1) should be removed, and (2) should be kept and replace (1) in the docs because, as this is a page all on its own, it does not respect the usual "fragment" semantics, which are supposed to access a part of a page at the client side as the web server is not supposed to receive it. See for instance:
However, drupal apparently makes heavy use of the fragment parts or URLs (syntax (1)) so, for the sake of drupal's internal consistency, and at the cost of consistency with the rest of the WWW, it could be better to keep (1) instead of (2).
Comment #3
fgmActually, there are even more values being passed. It seems almost as if all modules are fired on each help-related URL, even when this does not apply to the module. For instance, hook_help is fired on
admin/menu/item/edit/<mid>with the relative path as section.At this point, it seems more a code issue than a documentation one.
Comment #4
Jaza commentedThere seems to be a general misunderstanding in this thread, about the use of the '#' symbol in help paths. In the help module, the '#' symbol is NOT used as a fragment identifier - it is used to separate the page path from any special descriptors that may be needed. This is clearly documented on the hook_help page.
The correct way for a module to have its help text appear on an
admin/help/modulenamepage, is to use theadmin/help#modulenamevalue for its$sectionargument in hook_help. This may seem counter-intuitive, but it is the correct approach to let the help system recognise the special identifier (the module name, in this case), rather than putting the help text on the page directly.Also, I don't see where hook_help is invoked with calls to
admin/help/modulenameor toadmin/helpin the help module.Comment #5
fgmJaza, it may indeed be a feature as you suggest.
However, you say "Also, I don't see where hook_help is invoked with calls to admin/help/modulename or to admin/help in the help module.", but I just retested with 4.7.0:
so it seems the issue is still present.
Comment #6
magico commentedComment #7
ricabrantes commentedThis bug are fixed in D6.x-dev..
Comment #8
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.