Can't use Data Form variables in CSS Module

« back to the list of bugs

Can't use Data Form variables in CSS Module

Live templates are highly desirable because you can use variables (the user's data input) to manipulate the page.

One of my more clever coding applications used this code:

[[module CSS]]
%%content%%
[[/module]]

This would use the user's content as the CSS of the page.

This, however, is not functional with Data Form variables:

[[module CSS]]
%%form_data{css}%%
[[/module]]

Variables behaving inconsistently is what I consider a bug. Especially when it inhibits potential.

by James Kanjo, 1304950621|%e %b %Y, %H:%M %Z|agohover | 25 Comments

Status:

completed

Timothy Foster 09 May 2011 19:52

I actually tried this here a very long time ago, and if you encase the variable in code blocks, it doesn't work due to extra things being placed, like [[block]] [[/block]] or something. I don't remember if I placed this as a wish or bug somewhere, but I would really like it if variables could be used in these modules or code blocks.

---

— Blog ~ Life's Handbook ~ Wikidot Design & Development

leiger 10 May 2011 05:46

Bryce's newsletter templates site uses a data form to get the CSS from users, and then re-uses that in a code block.

The way this works is that instead of using regular CSS, he's using Div's and other things that work directly in the page. See the code for the "Number One" newsletter as an example:

[[block]]
\ [[div class="n-body" style="
\     margin: 0 auto;
\     width: 690px;
\     padding: 0;
\ "]]
\ 
\ [[div class="n-info" style="
\     font-size: 0.8em;
\     color: #666;
\     text-align: center;
\ "]]
\ 
\ You are receiving this newsletter because you are a member of [# mysite.wikidot.com]. 
\ ...
\ (etc.)

Copy and paste that directly into a page, and it works. Use it as part of a regular CSS theme, and it doesn't.

So maybe there is a way to work around your issue using this to your advantage?

---

Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.

Last edited on 10 May 2011 05:47 by leiger + Show more

Gabrys 09 May 2011 20:07

Have you tried with form_raw? form_data is self-enclosed, so it's never going to work inside of different constructs.

---

Piotr Gabryjeluk
visit my blog

James Kanjo 10 May 2011 08:03

I have tried it with raw, but that didn't work. I also tried it with both wiki field and text field.

---

λ James Kanjo
_{Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript}

Gabrys 09 May 2011 20:18

Ah, form_raw is only for pagepath and select types. Anyways, I don't think using data form values as [[module CSS]] contents is a good thing, since (in your example) you can't exclude possibility of someone ending your [[module]] tag and injecting some wiki syntax…

---

Piotr Gabryjeluk
visit my blog

leiger 10 May 2011 05:43

Anyways, I don't think using data form values as [[module CSS]] contents is a good thing, since (in your example) you can't exclude possibility of someone ending your [[module]] tag and injecting some wiki syntax…

This was always possible with the existing %%content{1}%% method listed above by James… and whilst there was always the chance of someone doing this and adding some other code to the page… what damage could this possibly cause?

• They could add a Redirect module. That only requires /noredirect/true to fix.
• Some code via the HTML tag… just use /norender/true to fix.
• Anything else they do… just revert history.

So not too much of an issue if people can maliciously insert unwanted code.

---

Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.

rurwin 10 May 2011 09:24

They could add an include and see the contents of a private category.

---

Copyright waived on Wikidot official and community sites — see profile for details.

Website: www.soronlin.org.uk
Diaspora*: ku.em.ecatstam.dop|nilnoros#ku.em.ecatstam.dop|nilnoros

leiger 10 May 2011 11:56

Well I'd see this as a problem with private categories, not data forms and the way fields are rendered.

If private categories are ever fully implemented, including a page that you aren't allowed to view wouldn't work.

---

Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.

Gabrys 09 May 2011 20:21

BTW, what field type do you use for saving CSS?

---

Piotr Gabryjeluk
visit my blog

James Kanjo 10 May 2011 08:04

I think I had it in wiki, but trying it in text didn't work for me.

---

λ James Kanjo
_{Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript}

James Kanjo 12 May 2011 12:56

So Piotr, if this was to be made possible, should I have my data-form field set to "text" or "wiki" ???

In terms of the possibility of wiki tag interference (i.e. User inserting "[[/module]]" in the data-form field), can we simply allow for this? I mean, given that we're using the “%%form_field{}%%” variable, it kind of anticipates wiki interference anyway. Mostly only developers, like myself, would use the "raw" variable.

Also, can you please, pretty please, consider this for me? I've made myself a CSS project manager to help me with theme designs, and data-forms would assist me immensely :)

---

λ James Kanjo
_{Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript}

Gabrys 13 May 2011 08:14

I'm not sure.

Field types are designed to just represent something — text is text, so it displays exactly what user entered, wiki is self-enclosed wiki, etc. I think we may want a different type, similar to text, but not being escaped on render, maybe raw. This would make it more or less consistent with the design and it would allow using %%form_data{…}%% variables (of this type) like %%content{…}%% variables.

---

Piotr Gabryjeluk
visit my blog

leiger 13 May 2011 10:46

Sounds good to me!

---

Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.

James Kanjo 13 May 2011 22:12

Okay, so you're suggesting a raw field type:

[[module css]]
%%form_data{css}%%
[[/module]]
====
[[form]]
fields:
  css:
    type: raw
    width: 50
    height: 5
[[/form]]

That would work for me — and it means that as Wikidot developers, we are not disadvantaged when using data forms compared with plain content.

---

λ James Kanjo
_{Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript}

leiger 14 May 2011 04:30

Being able to use match and match-error with this would be extremely powerful.

---

Shane Smith ★ Website: Wikidot Development & Programming. ★ STE Wikidot Editor: Windows. Mac. Linux. ★ Twitter. Google+.

Gabrys 17 May 2011 13:10

I'm going to introduce the "raw" field type, but it's going to be experimental (i.e. may be removed in the future, unless it really works well).

---

Piotr Gabryjeluk
visit my blog

Gabrys 17 May 2011 13:11

Please verify it's working as expected. Note it can break stuff when having [[form]] before the first "====" in _template. Documentation will be updated later (unless some of you wants to do it).

---

Piotr Gabryjeluk
visit my blog

James Kanjo 18 May 2011 14:00

Thank you thank you thank you thank you!!! You're a rockstar!!!

Thanks to this new experimental feature, I've been able to launch a new site: CSS Playground, which is essentially a sandbox for CSS themes :-)

Check it out!

---

λ James Kanjo
_{Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript}

Gabrys 18 May 2011 14:02

BTW, I'm more and more convinced this should be done the other way: instead of having "raw" field type which breaks displaying form, we should have %%form_raw{field}%% for text field type, which renders without being escaped.

---

Piotr Gabryjeluk
visit my blog

James Kanjo 18 May 2011 14:06

Wasn't there a reason we couldn't do that? I mean, didn't we create the URL field type for a reason?

Edit: That is to say, I think there was a reason, but I just can't remember it right now.

---

λ James Kanjo
_{Blog | Wikidot Expert | λ and Proud
Web Developer | HTML | CSS | JavaScript}

Last edited on 18 May 2011 14:07 by James Kanjo + Show more

Gabrys 18 May 2011 14:22

That's for different stuff. The idea behind the forms was they are mainly edited and displayed, not used in templates or ListPages, so they are no more "wiki", they are "data". And each type of data has a strict way of being displayed and edited. For example, date would be edited by calendar, but showed as MM/DD/YYYY, or if prefer DD-MM-YYYY (or even YYYY-MM-DD), geographical point would be edited by choosing a point on a map (or entering the geographical coordinates) and displayed as a point on a map. But something like "LOL" is not a geographical position, so also a filtering and constrains must be added. URL field is to edit&show URLs, text is to to edit&show text and so on. If you want to use text field in _template it works OK until you put it inside some markup.

Right now, Wikidot parser can't handle data form values as parts of more complicated templates, so the workaround is to allow overriding this sandboxing of values and using them more freely, forgetting about their constrains and possibly breaking some stuff. This is why it needs to be optional.

Imagine code like this:

##red|%%form_data{name}%%##

Ideally this should print whatever the representation of the field called name is in red. So if name field is of type "text", you should see whatever user entered there red. Yes, even if user entered there:

## my name is ##green|instead

Data form values should be safely escaped and resolved when they are safe to be parsed. We can't do it right now. This is more or less the same issue as the bug 16: %%content%% not parsed during include resolution. The parser should be more smart in general, doing its job in turns, resolving includes, names, remembering what already has been resolved etc. But it's not and not going to be anytime soon.

So what can we offer. As little as being able to say:

+ Unsafe but free:

##red|%%form_raw{name}%%##

+ Safe but restricted:

%%form_data{name}%%

But this comes with the same consequences you have when using %%content{n}%% variables. What's inside them can break what's outside. Your choice.

Considering ways of making this as safe as possible: one of the tricks may be putting a block you want to not interfere with what's around in a block section:

[[div style="background: pink"]]
pink here
[[block]]
It's quite safe here.
[[/div]]
[[/block]]
still pink here
[[/div]]

See:

pink here

It's quite safe here.
[[/div]]

still pink here

To break it, you need to have "[[/block]]" inside of it, which is way less probable than a random "[[/div]]" or "[[/module]]".

---

Piotr Gabryjeluk
visit my blog

Last edited on 18 May 2011 14:25 by Gabrys + Show more

Gabrys 18 May 2011 14:27

Going back to what's asked: I don't think there was a serious reason against having %%form_raw{field}%%. Just a hope the regular %%form_data{field}%% can work as expected in near future.

---

Piotr Gabryjeluk
visit my blog

Timothy Foster 19 May 2011 03:42

Wait, this works now?

By Jiminy, this is rather exciting! Interestingly enough, I needed this for the exact same reason as James: a CSS Sandbox meant to serve as a counterpart for the CSS Zone (which I planned to expand very much greatly over the summer).

I cannot wait to apply it to see what happens! Thanks Wikidot (:

---

— Blog ~ Life's Handbook ~ Wikidot Design & Development

Gabrys 01 Jun 2011 11:26

We changed this to work as described above.

The raw field no longer works, but you can use %%form_raw{field}%% on text fields, to get unescaped raw value.

---

Piotr Gabryjeluk
visit my blog

Gabrys 01 Jun 2011 11:27

We changed this to work as described above.

The raw field no longer works, but you can use %%form_raw{field}%% on text fields, to get unescaped raw value.

---

Piotr Gabryjeluk
visit my blog