CSIs initial version live
pieterh wrote on 29 Oct 2009 14:01
Hi Folks, we've pushed a first draft of Cross-Site Includes. These are not the full design but a minimal first step, letting us add a sitename to the include name: [[include :sitename:category:page-name]].
I'm thinking about how to use these now. First, we can't include parts of a page or code blocks, so the current layout of the includes.wikidot.com site is not going to work. Second, I realize that we often need to include several pages, as a kind of package.
So here's my off-the-cuff idea…
- a new packages-style site that uses CSIs, let's call it "modules.wikidot.com" so the old site can remain for now
- modules are pages with documentation, description, etc.
- modules refer to 1 or more include pages, which are pure code, no description
- the modules site uses the Hammer pattern
Thoughts? I'll make this already and move the existing pages to that, and we can see how it works.
| Subdomain name for includes not well chosen | By gerdami | 1 Comments | 08 Nov 2009 10:02 |
Comments: 50
page revision: 3, last edited: 29 Oct 2009 16:35
We love you!
Yeah, :-) It's not quite working yet, does not accept a short sitename.
Actually, it's Michal we should be thanking, he's producing minor miracles every day.
Portfolio
Actually, it's not working at all for some reason… I'll be building modules.wikidot.com today, so watch that site if you want to follow what's happening.
Portfolio
Duh, my fault… using the wrong syntax.
Portfolio
It's working fine for me…
Thanks Michal and Pieter. This will be so useful.
Rob Elliott - Strathpeffer, Scotland - Wikidot first line support & community admin team.
Sure it can: here
Yes, it's working fine. I'm killing all the include:scrollbar pages and putting ':modules:include:3' directly into templates.
If you want to do this for your sites, cross them off on http://includes.wikidot.com/page:1
Portfolio
Great news. I'm just wondering if modules is the right name, as it could cause confusion with [[module...]] as in listpages etc.
Sue
Hmm, yes, there is this issue. At this stage it might eventually replace packages, since CSIs are so much more useful.
Portfolio
This is revolutionary. I must ask you something though.
If we wanted to put a calendar on our site, wouldn't it be nicer to put a code like this:
Rather than:
Wouldn't we prefer to "include a module for a calendar" rather than "include module include number 4" ???
Agreed. It would also be less prone to typing mistakes. And easier to debug.
Sue
Yes, but. What if you want two or three calendar modules? Who owns the obvious name? How do we ensure competition and the ability to fork modules?
IMO using names works if we have a few, it fails if we have many.
Let's see some examples in practice:
Hmm.
Portfolio
And further…
Portfolio
James, don't want to be critical but IMO the calendar is way too big for the modules site - it breaks too many rules. It would IMO work better either as a package or as a separate site that can be clone-imported into a target site. I'm afraid if we start putting fairly major apps into the modules site, it's going to get messy.
I've clarified what fits my view of "module" on the main page. Calendar is too large IMO. :-/
Portfolio
I agree completely…
Just FYI, the physical structure of the calendars application means that two pages (namely, the backend full & backend mini pages) cannot reside in an autonumbered category… those two pages had to break the rules for it to work.
Now we have something to discuss… where shall we store the calendar framework?
Store it in calendar-template.wikidot.com so that people can either clone the site, or import parts of it, and that cloned calendar sites automatically sync with updates.
I'm going to do this for, e.g. forum-template and similar, so that there is less maintenance. Rather than template and descendants referring to a module, descendants can directly inherit pages from the template.
It means creating an include: category on the template.
Portfolio
What I've once wondered is now confirmed — you're a genius.
Yeah, blah blah blah :-)
I'm starting this now for this site, so:
and you can obviously use nice names then, there is no risk of conflict.
Portfolio
Now listen Pieter. You are clearly displaying the first stage of grief… denial.
You will still need to pass through the Anger, Bargaining and Depression stages, but sooner or later, you're going to have to accept yourself for what you are. A genius.
Let me know when you reach the acceptance stage :)
the way that CSS is put in the "admin,change theme menu" from Iron Giant made me think so I did the experiment (without succes) to include some other blocks of "css"-code… but that did not work…
So I am wondering how that works because if we can do CSI's I really would also like to put the css in the include… not ask the "includer" (person who is using the include) to seperately copy CSS in his custom theme under the admin:manage —> appearence …
I know we can put inline styling in the code, but we can't do things like a :hover because in <html> the css would be
but in the wikisyntax "{}" are not allowed in the style-attribute
So would that be possible?
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
I'm waiting for the CSS module, and then it will work perfectly - put the CSS in the include, and finito. Until then, let's not roll out too far.
Portfolio
Okay,… nevermind the edit I made to the above… had not refreshed my page, so I did not see your comment
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
Have you tried {} in the style argument, and it's rejected? I'll make an issue to allow this, then.
Portfolio
Would you please make a note here if this is beeing adressed?
Thank you
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
I've made an issue for it but it'll be low priority. Wouldn't it be nicer to use the CSS module instead?
Portfolio
http://www.w3.org/TR/css-style-attr is a working draft and not a part of CSS specification. The long answer is:
There is nothing in wiki syntax that disallows this, e.g.
and renders properly to:
Div that is supposed to be red, but yellow on hover.
The reason it does not work above (at lest I cannot see it red on Firefox nor Safari) is that http://www.w3.org/TR/css-style-attr is a working draft, not a part of any CSS spec, and AFAIK with no implementation in modern browsers.
Michał Frąckowiak @ Wikidot Inc.
Visit my blog at michalf.me
This might not always be desirable, but it might be handy if you could choose to specify the page title for the included page in the [[include]] statement.
I just tried CSI'ing the help files to a forum-template clone that I made earlier and noticed the pages didn't have titles. That's because the template didn't have titles set. But it led me to thinking that if you have designed a whole page to be included somewhere, it may be desirable that the page title is inherited along with the code on the page. Otherwise, you would have to manually add a title to all sites that included the page. Of course there would be other situations when you didn't want this behaviour.
I'll add this comment to design:10 also.
Sue
This is a nice idea. Also, perhaps tags and some other meta data should be inherited too. But this becomes more of a "link to page X" (replacing the whole target page) than "include content of page X" (including content into the page).
So perhaps a different command such as "[[link … ]]"
Portfolio
I prefer the strict code include… just a chunk of reusable wiki-syntax-code, not a whole page
A - S I M P L E - P L A N by ARTiZEN a startingpoint for simple wikidot solutions.
The design brief currently allows for both whole page and part page.
Sue
Yes, there's a fine line here. I suppose it depends on how the navigation/flow of the site is designed. If the page is included (as a whole page or part page), then in a way it becomes part of the child site and, as such, control of it is embraced and its inclusion is seamless. If, however, the page is linked to (obviously as a whole page), then you are effectively handing over the control and flow of the process to the parent site. You may never see that user again as they navigate away from the child site, since linking to a page does not provide the elastic to pull the flow back.
Does that make sense?
Sue
I'm getting some strange results using CSIs in forum-template.wikidot.com.
Take a look at http://forum-template.wikidot.com/thread:2
Until these are resolved, caution…
Portfolio
The problem is that after the page is included, the %% variables aren't processed. A workaround for this is to do what I did with the Calendars template… replace all of your %% variables with {$} variables, and then use the CSI to include them properly.
For example, your _template page:
Your CSI page:
Should I push my "module.wikidot.com" to "modules.wikidot.com"?
Kenneth Tsang (@jxeeno)
Good idea!
Portfolio
We've just rolled out an update to CSI which handles templating properly (in fact includes never did this properly before).
You can see on this page that it's now working.
There will probably still be things that don't work properly. When this is stable we'll move ahead with the rest of the CSI design.
Portfolio
Thanks for that :-)
Thought: Currently when blocks are included, they are not stored on the Wikidot site's cache (/local--code/page/#). This means we can't cross-site-include CSS layouts, or Javascript code.
You mentioned that the (pending) CSS module would be able to help out for the first problem, but this doesn't solve the use of cached Javascript code blocks.
We've seen the problem of code blocks, and will fix that, asap.
Portfolio
I just went through and did an edit/save on all of the threads to recompile the pages affected by the CSI glitch.
Pieter, can you look at the section:_template page when you catch your breath? Pages in that category are still broken, but it's because the page that you're trying to include really doesn't exist. I tried to dig into it, but don't have permissions on the forums template site (that, and I have to quit playing with Wikidot and get to the office!)
It looks like the CSI capability is going to be pretty useful.
-Ed
Community Admin
Ack.
Portfolio