Before the rollout of cross-site includes, %%content%% (and %%content{n}%%) was processed while parsing the include statement, so that content could provide argument name=value pairs. Now this no longer happens, which breaks some existing code. Note that content can still provide values, but that is not enough when templates need more than one argument.
Minimal test case:
testcase:_template
[[include testcase:_backend | %%content%% | result=%%page_name%%]]
testcase:_backend
Result: {$result}
testcase:success
Page title: Test one
(empty)
testcase:failure
Page title: Failure
result=Test two
Note that this works, and may provide a workaround for simple cases:
testcase:_template
[[include testcase:_backend | result=%%content%%%%page_name%%]]
testcase:_backend
Result: {$result}
testcase:success
Page title: Test one
(empty)
testcase:not-failure
Page title: Test two
Test two successful!
The problem is in the ORDER that the Wikidot engine processes these variables.
The current (BUGGY) order is this:
This is why your code isn't working. If the last two steps were reversed. Here is a proposed (BUGFREE) order:
This is something that, if fixed, allows for some very sophisticated things to happen within Wikidot… I have a couple of designs in mind that a majority of Wikidot would be interested in.
Please please please fix this!!!
Yes, we're redesigning the parser for a bunch of reasons, this is one of them. Thanks…
Portfolio
The problem is that the "include variables" processing are tightly bound to the include process — they happen at the include time. It is technically very challenging. And it is currently not possible without significantly changing the wiki parser itself… I guess we need to postpone this a bit.
Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalf.me
Yeah, but note that this used to work, and stopped working when we introduced cross-site includes…
OK, so I understand that this part of the parser changed when we fixed the problem described here: http://www.wikidot.com/forum/t-192484.
Either %%content%% is processed one way, or the other… but not both ways.
I'm closing/canceling this issue.
Portfolio
After some more discussion and thought… what is happening is that templating (including symbol resolution) on the page used to be done before include statements were processed. Then, we added an extra parser step to do include statements before templating.
So what needs to happen is:
We'll look at making this work.
James, this is not quite what you described in your comment. Could you give some examples of the 'sophisticated' things you are thinking of, so we can see what you mean?
Portfolio
I hesitate to associate myself or my wiki-designs with the word 'sophisticated', but does this qualify?
Having puzzled it through (much more methodically than anyone with real programming chops would have done), it seems like I'm entirely caught up in this question of parsing order.
Sorry Pieter! I must have missed your post!
As I have published here, changing the parsing order would make it possible to only show data depending on who is viewing the page.
i.e. Only allow non-anonymous people see this section… Only allow the admins to see this section…
Or another example of sophisticated code (which I have held in secrecy) is the ability to automatically pluralise correctly and automatically. Have a look at it in action.
If the ListUsers module according to my design was fully functional, we would be able to say how many users contributed to the current page, or to pages of specified categories:
I have some more examples of sophisticated code, but I need to have breakfast now — I'll reveal them later.
I believe we can just change the order in which symbols and includes are processed:
If someone wants to use "%%content%%" or "%%fullname%%" in include it needs to be passed as an include parameter, for example:
[[include content=%%content%% | fullname=%%fullname%%]]
and used as {$content} or {$fullname}
Piotr Gabryjeluk
visit my blog
Okay. But won't that mean that we can no longer CSI live templates? Any variables on the page being included would not be parsed… correct?
~ Leiger - Wikidot Community Admin - Volunteer
Wikidot: Official Documentation | Wikidot Discord server | NEW: Wikiroo, backup tool (in development)
Yes, Shane is correct. Piotr, CSI live templates would have to take the priority over this.
HOWEVER, the current issue is still very valuable for us Wikidot App Developers. So how about adding an additional step:
Edit: Currently we are doing this:
So logically, we are just copying the Symbol code and pasting it before the include code.
Hi again,
the problem with parsing some things twice is that you can have for example "%%content%%" in result of something that was parsed once and this being parsed twice, for example if we had the following parsing order:
(I'm not sure if this works at all, but that just an example), and with the following pages:
You should get:
And you would get:
This is because symbols are resolved twice, so the result of one resolving is passed to next resolving, which we don't want.
It's really hard thing. I'm not sure if we can fix the symbol resolving order in the way that keeps all existing pages and includes working.
Piotr Gabryjeluk
visit my blog
That's not quite right… What your proposing is this:
We don't want the fourth one.
I was talking about this:
And we (probably) want this:
So if we have a nice way to decide which symbols are "remaining", we would be (probably) fine with this.
Piotr Gabryjeluk
visit my blog
I'm trying to submit a new bug, but got an error message. Basically, the server software seemed to have been updated in the past couple hours, because I can view the contents of the page, and they are correct, but what is displayed is only in the category:_template page. The behavior before was I had a category:_template page, and when I created a new page, it would instianate a new instance with my specified title. Now all of the pages in the category seem to be trumped by the _template.
Please post a link to affected site. Thank you.
Piotr Gabryjeluk
visit my blog
Please take a look at a veeery detailed explanation on the projects site: http://projects.wikidot.com/thread:340
Piotr Gabryjeluk
visit my blog
PLEASE PLEASE PLEASE PLEASE PLEASE make this a priority!!!!!!!!!!!!!!!!!!!
We could do MORE TRICKS if this were solved!!!
I agree! :D
Timothy Foster - @tfAuroratide
Auroratide.com - Go here if you're nerdy like me
I know this is an old issue, but we are cleaning pending stuff. After looking into this one we decided to reject it. Not only we internally rely on the current page processing order, but some of the existing pages on various Wikidot sites would be messed.
The change would require too much work, testing and altering existing pages. Sorry guys.
Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalf.me