I'm working on a project where I want to use Google Visualizations to display form data in a table. This requires using ListPages to create HTML block syntax. I can get ListPages to generate the output I need, however the output is treated as regular text instead of a HTML block. I've been working on this for hours trying to find a workaround, but am having no luck.
What I discovered is that ListPages is outputting HTML entities for the < and > characters instead of leaving them alone. The parser converts all HTML tag brackets (< and >) to their equivalent HTML entities except when we place them inside [[html]] or [[code]] blocks. I think the parser should be fixed so that it can recognize that we are building [[html]] or [[code]] blocks with ListPages and leave the contents of the ListPages output alone.
Rather than putting all of the details here, please see the very simple test I made to show what this issue is as I see it:
http://try.wikidot.com/listpages-prependline-and-appendline-html-block
Please fix this if you can. It would give us another way to do some clever things with our sites.
Edit: Based on the discussion below, I've edited this bug and title to more clearly (I think) describe what the issue is. The bottom line is that I'd like to see HTML tag brackets left alone if we are building a HTML or code blocks using ListPages. Whether this is seen as a bug or a wish, the end result I'm looking for is the same.
Same question here . would Universal escapwe help here : http://www.wikidot.com/doc:wiki-syntax#toc7 ?
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
The reason triangle brackets are converted to HTML entities is to prevent hacking. If they weren't converted to HTML entities, we'd be able to exploit Wikidot in several ways.
Therefore, it's not a bug, but an intended security feature.
If that's true, then what's to prevent someone from "exploiting Wikidot in several ways" using HTML blocks outside of ListPages? That reason doesn't make sense to me.
Community Admin
The HTML block places YOUR code in an iframe (effectively a sandbox).
If we were allowed to put actual triangle brackets inside source code, we would be able to do sneaky code like so:
Ed, I think the confusion is that you're bug reporting a symptom, not the cause.
You're saying that "ListPages is outputting HTML entities for the < and > characters instead of leaving them alone". So you've thought this is the cause of your problem.
The cause is that Wikidot have disallowed the HTML block inside ListPages. Any attempts will render your code as normal wiki syntax instead.
A symptom of Wikidot disallowing HTML blocks inside ListPages is that the code is converted to wiki syntax, which in turn converts triangle brackets into HTML entities.
Hopefully this clears things up for you.
You should change this bug report to say "Allow HTML blocks to be used inside ListPages modules".
You're right. I just did another quick test and see that ALL HTML tag brackets are converted to HTML identities by the parser whether output by ListPages or not. The only place they are "left alone" is when they are inside a HTML block or a code block.
So it seems that the real challenge here is how to tweak the parser so it can recognize that we're building a HTML block (or [[code]] block - it has the same issue) with ListPages and not convert the tag brackets into entities.
Community Admin
I made some tests with wdfiles.com code script(s) and included outcome of the ListPages module.
The wdfiles code blocks are neccessary - otherwise you will never get the sripts running.
It "hangs" at the moment where in the google vizualisation script the dynamic listPages output will be inserted.
The "manual" insertion of the Listpage output [http://helmuti-pdorf.wikidot.com/google-viz:_listpage3]
works well on
[http://helmuti-pdorf.wikidot.com/google-viz:_code2]
The manual insertion of the wdfiles code block does work on
[http://helmuti-pdorf.wikidot.com/google-viz:_code3] (shown on http://helmuti-pdorf.wikidot.com/google-viz:_code4 )
and on
[http://helmuti-pdorf.wikidot.com/google-viz:_code1] not the Include of the Listpages output
What here is needed to insert the ListPages output in the split of the scripts:
http://helmuti-pdorf.wikidot.com/google-viz:_start - the first part of thegoogle-sript
http://helmuti-pdorf.wikidot.com/google-viz:_end - the seecond part of the google script.
at the mpment where the dynamic content is to be inserted…
Any idea how thos could be managed and the bug is no longer a bug and we could use the google-visualization script
I need to "split" the script in to code blocks ( or is there another goog trick like a varaible "point" insertion?) beefore and after the include of the Listpages output.
Service is my success. My webtips:www.blender.org (Open source), Wikidot-Handbook.
Sie können fragen und mitwirken in der deutschsprachigen » User-Gemeinschaft für WikidotNutzer oder
im deutschen » Wikidot Handbuch ?
Thanks for the efforts here, Helmuti. You're running into the same issues I found when I was trying for hours to get this working. There's several ways to get output that looks like a HTML block, but it just doesn't work as I hoped it would.
Community Admin
Hi, all. It's imposible to use html inside modules in this way, cause Wikidot parser is linear, it parses wiki language in a specific order:
Modules are resolved after html blocks. Additionally each ListPages element (content of list pages module with resolved ListPages markup tags) is parsed by Wikidot parser itself to resolve wiki markup inside it.
Moreover each wikidot parser rule can be one of two types block (code, module, html, …) or inline (**, __, div, span, …). Block ones cut everything what is inside them so next parsing rules cant touch it.
To the point, to allow such and many more awesome things in Wikidot -> we will need to rewrite whole parser, to none linear. So each block rules will rune wikidot parser inside them (maybe with some restrictions), and it won't be backward compatible, very resource expensive, not easy at all.
Bartłomiej Bąkowski @ Wikidot Inc.
';.;' TeRq (Write PM)
Thanks for the detailed explanation, TeRq. I guess in this case, the duck test doesn't apply.
"Just because it looks like HTML, swims like HTML, and quacks like HTML, doesn't mean it will render like HTML." It's a bummer, but I can live without it.
Community Admin