(Answer) (Category) Faq-O-Matic Faq-O-Matic : (Category) Administrators' Guide : (Category) Upgrade : (Category) Version History :
Changes in 2.708 from 2.707
Jim Spath (jspathATbcplDOTnet) did some sanity checking on the HTML generated by FAQ-O-Matic, and found a number of bugs that are fixed in this version.
"Mark D. Nagel" (nagelATintelenetDOTnet) pointed out that the fuzzy URL matching (used to) stop on '?'s, which is pretty stupid considering most FOM (and other CGI) URLs have '?'s embedded in them. This is fixed for http/https urls. In the long run, I'm thinking about transitioning to a less fuzzy encoding for URLs embedded in the document text.
Peter Lawler (sixbynineATozemailDOTcomDOTau) suggested that we provide the FAQ-O-Matic's title as the subject line of mailto: links.
In the past, anything that looked like a URL in a 'natural text' part got 'linkified' when presented as HTML. Unfortunately, it's pretty tough to tell where 'something that looks like a URL' ends, and so this mechanism was pretty unreliable. It did have the advantage that any hyperlink addresses still appeared visible in printed copies (for example) of a FAQ. To solve the problem above, this version allows authors to delimit URLs with <>. Anything inside <>s becomes a hyperlink, but the <> and its original content still appear as they were. So if the <> are part of a program fragment (echo<foo>bar), they still read correctly, even if a nonsense link is introduced. <>'s can contain anything but whitespace and <>'s; so any <>'s embedded in URLs need to be escaped. Special URLs inside <>s are still recognized and given special treatment (faqomatic:, baginline:, and baglink: references point inside the FOM; server-relative http: urls are expanded to be absolute for posterity, and mailto: references have a subject line attached).

The old-style 'fuzzy matching' is still enabled, but I expect to someday turn it off (or make it an admin feature that's off by default), because it is brittle, and I want to encourage authors to use the less-brittle <-delimited links.

The handling of faqomatic: references in directory parts is now consolidated in one function and otherwise cleaned up; as a result, it should be even harder to convince FOM to corrupt the parent/child relationships between categories and answers.

If $pageHeader (or $pageFooter) begins with file=, the remainder of the name is taken to be a file in your meta direcotry to include in-line in the HTML output, rather that verbatim HTML. This is nice for those of you who need a big $pageHeader.
Note that the described behaviour for "<>" links does not work in this way for Faq-O-Matic 2.712 - this version removes the "<" and ">" signs for potential hyperlinks (i.e., if the regex matches). By this, the example with "echo < foo > bar" above misses the "<" and ">" signs. You could work around this by using duplicated "<<" and ">>", which will lead to displayed single "<" and ">" signs but still would contain the nonsense link (e.g.: "echo<<foo>>bar").
I raised MR number 539315 in sourceforge.net for this, and also uploaded a patch for OMatic.pm
[Append to This Answer]
Previous: (Answer) Changes in 2.707 from 2.706
Next: (Answer) Changes in 2.709 from 2.708
This document is: http://www.jonh.net/cgi-bin/faqomatic/fom?file=422
[Search] [Appearance]
This is a Faq-O-Matic 2.718d.
Hosted by SourceForge Logo and jonh.net.