Add an administrative search feature

This is awesome... but D5.x? not so sure.

Awesome feature, especially when you sit down and try it out; this will really help with usability. Searching for the correct administration page is a huge pain for non-experts, lessened by the admin reorganization of course. This could generate a lot of publicity. +1 for another "strange feeling" feature that takes drupal ahead of the pack. -1 for asking for reviews of a 15kb feature request so late in the release cycle though.

Applied to a current installation and it never finds anything (throbber seems to go infinitely). Clearing the menu cache fixes this.

It would be nice if the corresponding bubble (if it exists) also changed color when an item is highlighted in the dropdown list.

On /admin the "Find" text overlaps with "by module" if the window size is too small.

Searches that highlight menu items show a dark gray bubble that isn't clickable: searches such as "drupal", "help", "configure", "content", or "blog." Why show a bubble but not let the user click the link? (I see that this is a known issue for Garland)

It isn't immediately clear why some bubbles are gray and some are white (and some are dark gray) - maybe this could be explained to the user? Or there might not be a good way to explain/show the nesting aspect.

If you have an error on your admin page ("One or more problems were detected with your Drupal installation. Check the status report for more information.") and search for logs, the "status report" bubble will be incorrectly located below and to the left (see attached screenshot). (Known issue with inline links)

Searches with single quotes work, but searches with double quotes don't (i.e. they don't return anything). It seems reasonable to let users search with double quotes.

IE returns "invalid argument" line 174, char 5, code 0 when using the search.

Commenting out line 178 of help.js ('height': parseInt($('body').css('height')) + 30 + 'px',) removes the error, stops the background "graying" on search, and the functionality starts to somewhat work. The dropdown list is located outside of the page (top is correct, but left is too far to the right). Screenshot attached.

Attached patch fixes the initial IE attribute error by manually creating the body element & CSS within guideAutoAttach. It could be moved to somewhere more central though, like drupal.js.

Correction: the body element doesn't need to be manually created, just the css.

I too am conflicted about the feature going in this late. At the same time, my entire being resonates with the knowledge that it is a damned sexy feature. Anyone with core commit rights have thoughts on whether this would actually have a chance?

On principle, I would hope that if we were going to add some usability this late in the cycle that it would go for a really important usability issue to allow users to easily add blocks http://drupal.org/node/92630, instead of something sexy like this (although I agree with Eaton). But hey, my uid is 22975 not 10, so what do I know? =)

Perhaps the goal should be that we patch core just enough for this to live as a Contrib in Drupal 5. From a quick read, I can't find anything that has to change but i must be missing something. Anyone up for reworking as a Contrib module and a small core patch if needed?

Here's a basic conversion of the code to a contributed module; no core modifications are needed. I made the minimum number of changes necessary so it could use a bit more cleaning up if someone is interested.

is working for me. i suggest adding it to CVS and creating a project. we can refine in own issue queue.

+1 for contrib module (works for me as well) -- a nice addition for help in general for 6.x

The code still needs work in terms of being committed to d6.

project created - http://drupal.org/project/menuscout. use that issue tracker for future discussion. at some point, this should go into core though.

Let's get this into D7.

Sounds cool, but not exactly what I'm looking for, but ... Tracking

This definitely looks nifty. Subscribing. :)

Moving all usability issues to Drupal - component usability.

Giving this a better title...

This would be really nice although doesn't seem particularly likely for Drupal 7 at this point. Sounds like it would be a nice solution to the current problem in Drupal 7, where the new IA means there isn't really an admin page where you can even go and use Ctrl-F in Firefox to do an on-page search to find something. #699848: admin/by-task is confusing since it lacks links to config pages and looks similar to admin/config and friends would help with that too, though, and is much more likely for D7.

Yes, too late. Lets figure this out in Drupal 8, a bit uncomfortable though - since nothing like this exists in contrib.

In addition to http://drupal.org/project/menuscout (linked to above, but for Drupal 5) I just came across a newer module which looks like it does something along these lines for Drupal 7: http://drupal.org/project/coffee

Since help is stored in the codebase this will require API changes, a restructure that exposes the information to views would be a way to go about this for D9.

Seems doable in 8.1.x if we also do #2351991: Add a config entity for a configurable, topic-based help system.

A recent issue made this same request; some discussion there on how to do it with the configurable help topics: #2359519: Make a search plugin for full text help searching

I've filed a new meta issue to collect all the problems with the current help system and discuss the best route to fixing them; this issue is being added as Related there, and all of its concerns are listed in the Problem/Motivation section:
#2592487: [meta] Help system overhaul

I think it's more a question menu/searchability, asked in upcoming tuning of menu navigation #3391723-13: [PLAN] Accessibility review