Test on LitterTray:
IncludeWebpageTest
The html at the h1 header looks like:
<h1 class="title" title="Permalink » 36 Checks & tips voor usability van formulieren" id="post-233">
<a href="http://www.usarchy.com/2006/09/tips-usability-formulieren/" rel="bookmark">
36 Checks & 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
TWiki:Codev.IncludeNeedsToProcessHtmlLiterally
This should be mentioned in the release notes, closing.
--
SP