Use plain HTML help files

*The reader* here :) Updating extractor.php to support this seems to be quite simple.

awesome plan.

i wonder if there is any use in making the help files overridable with help files in the active theme dir

+  $help_filename = drupal_get_path('module', $module) .'/'. str_replace('/', '_', $path) . "$fragment.help";
+  if (is_file($help_filename)) {
+    return t(file_get_contents($help_filename), $help ? $help : array());
+  }

Could be replaced by far less code using glob (why we don't use glob in Drupal on other places has wondered me for ages). That way you can have an array of all available help-files ready, and you don't need to hit the filesystem twenty times on each load. Hittin the FS is notvery heavy, true. But the Files are locked-read-released, meaning that when hundred people load a Drupal page simultanously, the PHP for user 100 has to wait for 2000 (20 files, 100times) before it can proceed.

Bèr

as long as it is fast enough, this seems like a good direction. my understanding is that the phptemplate patch is a bit slower because of this same reason (more files), so it would be nice to address that and then get both patches in :)

Hmmm. While I think it is awesome to have the help text pulled out of the code where it definitely can't easily be edited....is it appropriate to include web-based editing as part of this effort?

If this is not deemed possible/necessary for core, then this should be done as a contrib (i.e. the deprecated helpedit module). WebCMS with static HTML?

If this goes forward, then I suggest wrapping the HTML source to fit a narrower width. Sure, it doesn't matter when the text is displayed by a browser doing its own wrapping. The problem is looking at patch files or diffs, when the lines can be huge and aren't wrapped. That just makes it unnecessarily hard to find small changes (e.g. a simply transposition typo) in a long line, which slows down proofreading of sources.
It also makes the patch larger than it needs to be, which is also annoying for proofreading purposes.

A corollary is that many HTML editors need to be avoided, because different such editors do their own reformatting of the source. Again, this wouldn't affect the resultant display, but would totally break the diff/patch mechanism (unless there's agreement on a single such editor). Personally, I use emacs with fill turned on for .html files, but even that could cause unnecessary reformatting.

A different question: How does this interact with localization? It's certainly easier to translate text when it's in a separate HTML file, but there needs to be a mechanism for picking out the correct file depending upon a user's language choice.

Gary, this patch changes nothing in localization. The localization would still continue to be delivered from the database, imported from PO files.

@Chx, I utilize the possibility of adding more help to some pages heavily. So I can add additional instructions without core hacking. This is a feature. Please do not try to remove it.

subscribing. more later when i have a chance to actually look at the patches here. ;) i'm certainly in favor of the general thrust, even if the details are still slightly murky.

:( patch no longer applies. (and i really like this idea too, btw)

# patch -p0 < help_5.patch
patching file includes/common.inc
Hunk #1 succeeded at 2309 (offset 902 lines).
patching file includes/menu.inc
Hunk #1 FAILED at 502.
Hunk #2 succeeded at 1021 with fuzz 2 (offset -4 lines).
Hunk #3 FAILED at 1053.
Hunk #4 FAILED at 1218.
3 out of 4 hunks FAILED -- saving rejects to file includes/menu.inc.rej
patching file modules/help/help.module
Hunk #1 FAILED at 120.
1 out of 1 hunk FAILED -- saving rejects to file modules/help/help.module.rej
patching file modules/node/node.module
Hunk #1 FAILED at 14.
1 out of 1 hunk FAILED -- saving rejects to file modules/node/node.module.rej
[root@h99846 test]#

Good idea, but needs to be moved to D7.

#299050: Help System - Master Patch