INCLUDE needs to process external HTML literally

From Bugs:Item3123:

Test on LitterTray: Bugs:LitterTray/IncludeWebpageTest

The html at the h1 header looks like:

<h1 class="title" title="Permalink &#187; 36 Checks &#038; tips voor usability van formulieren" id="post-233">
         <a href="http://www.usarchy.com/2006/09/tips-usability-formulieren/" rel="bookmark">
         36 Checks &#038; tips voor usability van formulieren         </a>
        </h1>

TWiki interprets the 36 as a numbered bullet list, resulting in a completely messed up page. Setting raw="on" doesn't help.

I would expect TWiki does not do anything with bullet lists, or any item on the page.

AC

Actually, TWiki will still parse the included content, even with the raw parameter set. So, as in this case, if the number of spaces used in the included content incidentially is 3*x, some rendering might kick in.

Added a literal option to INCLUDE to allow for escape of the rendering pass.

-- SP

Isn't the literal option way too high on the nerdometer? With all due respect to compatibility: I'd never ever expect to have an included HTML page processed by TWiki. It is strange enough to have a .txt page processed by TWiki, but this may have its justification if someone attaches a TWiki topic, but for .html this is IMHO pure nonsense.

The <literal> ... </literal> wrapping should be applied to all .html files from the local attachment store, and to text/html files retrieved with getURL, and to no .txt and text/plain files.

-- haj

Would it break installations if we default to literal, so external files are not processed?

AC

We could change spec to add <literal> tags per default and change the parameter to render="on"?

Doing this triggers a compatibility issue, so it should go through the release process if this is the better logic.

As long as it is possible to do both logics with the included content, I'm OK.

-- SP

Proposal

When external web pages are included using INCLUDE, do not process the html text, but only when set explicitely with the new option render="on".

-- Contributors: ArthurClemens - 10 Nov 2006

Discussion

Harald wrote "but for .html this is IMHO pure nonsense". Yes and no. It is nonsense to apply TWiki formatting rules (headings, bullet lists) though there may be a valid justification for expanding %TWIKIVARIABLES%.

-- CrawfordCurrie - 11 Nov 2006

What's the use case for expanding variables? Write a HTML page, put %TWIKIVARIABLES% into that page, push it on a server and wait for some TWiki to %INCLUDE% it? Sort of a "post-processor" for HTML pages?

-- HaraldJoerg - 11 Nov 2006

possibly an unusual case: I had a nightly batch job on a previously unrelated system, that generated a twiki formfield definition table (served by its web server), which I then INCLUDEd into twiki. This meant that TWiki had a up to date list of options. As an added bonus, people started to use TML in that system, so that the TWiki based web frontend would process them.

-- SvenDowideit - 12 Nov 2006

Yep. The variables system in TWiki is quite capable of being used as a sort of poor-man's PHP. Can't recommend it myself, but it might be appropriate in environments where there is more familiarity with TWiki than with PHP (or any of the other page generation lingos). Or where plugin results are required in otherwise pure HTML pages.

-- CrawfordCurrie - 12 Nov 2006

I agree with Sven. Don't see any reason for not processing included HTML. This is no different from processing the HTML that comes from a template.

-- ThomasWeigert - 12 Nov 2006

Yes, but can we set this as an explicit parameter, and default to not parse?

-- ArthurClemens - 12 Nov 2006

Bugs:Item3123 released with 4.1.0.

-- SteffenPoulsen - 14 Jan 2007