I just tried out this module in an attempt to explain some of the trickier aspects of a large site.
Specifically, I have a few 'panels' pages made up of node teasers and blocks that are maintained individually elsewhere - mostly to keep the content admins away from the 'panels' interface, but also to take advantage of a few other node management things.

So I wanted to link help explaining the roles of these placeholder sub-nodes - from the dummy node itself. Seemed to work, but I go to add that help globally. Context help applied to the menu router path, not the node.

How can/should I add per-page help? I was going to write my own site-only module that just added 'help' using the help hook, but it looked like this module was a much better approach. Only it doesn't do the thing I wanted.

I tried munging the URL
/helpinject/inject/path/node/%2525
into
/helpinject/inject/path/node/1539
and submitted that. Bad move, as it went in but got lost.

Can there be support for helpinject on a per-page basis? Shouldn't be too hard UI-wise.

CommentFileSizeAuthor
#10 fine-grained-paths.patch12.52 KBrobertdouglass

Comments

robertdouglass’s picture

robertdouglass commented

I was having the same thought. I think where multiple contexts are possible some radio buttons would work out well. Something like:

X Inject this help on all pages with paths like node/%
O Inject this help on just the page node/123

Would that do it for you?

dman’s picture

dman commented

Yes please.
"Actual page" was basically the expected behaviour - applying to the wildcard is an 'advanced' option.
IMO.
Not too hard on the UI to provide the option. As long as it doesn't hurt too bad on the internals (I've not looked)

robertdouglass’s picture

robertdouglass commented

Internals should be fine. Will take a touch of refactoring, I suppose. Will change to current page being default as per suggestion. Won't get to this today, though, so you'll either have to sit tight for a week or give it a go yourself.

crashtest_’s picture

crashtest_ commented

Actually, this makes a lot of sense to me as well. Interestingly, the other issue: http://drupal.org/node/416068 about making the workflow easier, may work together with this. In the other issue, the request was made to go directly to adding the help book page from the + sign, and that makes sense unless you are creating a help that would be used in many places.

What I suggest in light of this issue, is that a user clicks the + expecting, as you say above, to be able to add help to that place, to that particular place, and the only reason my reasoning in the other issue works is if we are doing this in more than one place as I said there.

Sooooo, wouldn't the proper UI be to click on the +, have it take you to a help entry page that itself has the options to use that help specifically or globally? I know this opens up a different can of worms with altering the book entry form, or creating a custom entry form, but it would seem that we don't need all of the options on that page (menu settings for example), and we do have options that we would rather have access to.

Also, a little off topic for this issue, but does anyone need to know this is a "book page" when they are simply wanting to add "Help" to a page? Why bring that into it? I think we could create a default parent book during the module install that is called "HelpInject Book", and have all HelpInject pages automatically use that book as parent.

dman’s picture

dman commented

To continue the off-topic, I was actually a bit put off by having book.module as a pre-requisite. I hadn't needed it on the site (40+ modules and counting already). I didn't quite see the need. And now it's (book.module) left some clutter in the UI I need to (hope I can) clean up.
BUT it will actually be a useful approach to me formulating my documentation, so that's OK. Better practices in general. I was able to rename the content type to "Handbook Page", so I think it's a net win.

All I really wanted was a UI that let me add help text (in the help zone) directly to pages. Right there. Do I really need a [+]? I want the teaser text visible there on load.
Probably a different feature request. I guess I'll have to dig into it myself. :-B

robertdouglass’s picture

robertdouglass commented

That's also on my radar. That would allow you to add/alter the descriptions on pages and forms. Glad to hear that your need matches what I want for the module.

In some cases you do need the (?) because help text won't fit into the UI (Views module), so we need both.

dman’s picture

dman commented

Oh, we certainly need both. I noticed all the help buttons pop up next to the form items. Can't have them full-text there. ... Although that's why I experimented with a module that converted all my form element descriptions into js tooltips a while ago. Actually worked damn well.

But... Have you seen what the help injection does to the menu admin page? :-(
Another off-topic issue I was going to raise separately, but we are here now...
My main site menu is about 160 items. somehow this took 2 mins to load when the help injector was enabled. I need to be able to dial it back from the per-field rendering and just do the per-page one :-}

crashtest_’s picture

crashtest_ commented

All very good points.

So, it would be good if we had the following:
* Ability to add inline help to elements
* Ability to add advanced help to elements
* Single form, not necessarily book, to enter help text
* Same form, perhaps in collapsible field, to select existing help text
* Radio option to select node/% or node/123
* Radio to select whether this help is inline or advanced
* Ability to dial down the help add links from item to page (maybe)

Does that sound about right?

robertdouglass’s picture

robertdouglass commented

The list in #8 is good. I've got some slight variations or refinements for almost each one, but perhaps one of you could lend a hand by opening separate issues for the ones that don't already have them?

robertdouglass’s picture

robertdouglass commented
Status: Active » Fixed
StatusFileSize
new fine-grained-paths.patch12.52 KB

I totally rocked this issue. :D

Note that path injection and form (or views/blocks/panels or whatnot) are different. Paths have their own special levels of hierarchy and granularity (node/1, node/%, node) that the other types don't.

So for path injection the injection form is now multi-step. The first step asks you what granularity of path you're injecting for. It tells you which granularities have injected help. Other types of injection (form, for the time being), don't have this extra first step. This means you can now basically inject help down to any specific given page. Very awesome!

Committed attached patch.

dman’s picture

dman commented

Yay w00t thanks!
Great timing, I've got bunches of docs to write next week.
I'll try it out.
.dan.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.