Can the Innerwiki plugin only show exactly the current setup of the current wiki, or would it be possible to e.g demo the current wiki but with installed plugins, different settings, etc?
If I can be allowed to answer so indirectly…
You can place any wiki you like in an iframe – obviously, without any of the benefits provided by innerwiki.
Thanks, yeah… and come to think of it, that is probably even how it has to be done for what I’m pondering… which is (of course?) the current discussions on how to show “editions” directly on the tiddlywiki.‍com site and it wouldn’t make sense with the innerwiki anyway since they probably should not be based on the populated tiddlywiki.‍com-site anyway…
With that said; the InnerWiki plugin seems to add some additional tidbits over merely an iframe.
Hi @twMat the innerwiki plugin starts out with an empty tiddlywiki with the same core version, and then you can both add tiddlers from the current wiki, or construct completely new ones that don’t appear in the wiki.
So, if you wanted to include a plugin in an innerwiki without it being installed in the host wiki, you’d store the plugin as a tiddler of a different type, and then use a custom <$data> widget to import that tiddler while also setting the correct type for it to be recognised as a plugin.
1 Like
Just gotta say; That innerwiki plugin - man, it is nifty! I had not looked closer at it previously because I didn’t have a use case.
I was not clever enough to figure that out by myself. An example of this in the docs would be useful (…but then, so would a lot of other docs.)
One thing that “feels off”, at least for my use case, is to have to store the tiddlers with the same title in the hosting wiki as in the inner wiki. It does not work to do this to “set” the title field:
<$data $tiddler="$:/hidden-in-host" title="visible-in-inner" />
I did not expect this to work (because the title is the tiddler ID, etc) but I’m wondering if you could propose any workaround? My own use case, and I’d imagine this might not be uncommon, is that some tids should ideally only be accessible in the innerwiki so one would at least want to hide ($:/...) them in the hosting wiki.
Thank you!
IMO you should “feed” inner-wiki with Compound Tiddlers. They can have different names in the host-wiki than in the inner-wiki. See. https://tiddlywiki.com/#CompoundTiddlers
Ah, thanks, that might be useful. I only looked at it briefly and will need to investigate the following closer:
- The docs only give very simple payload tiddlers. Would it be appropriate also for longer or complex ones?
- The docs don’t make it clear how to call/splitout/transclude/whatever-it-is-one-is-supposed-to-do with the payload tids to actually turn them into tiddlers…
- …because my need is to turn the payload tids into real tids, so I assume this can be done… right?
If you think I will not find answers to these questions, then I’d appreciate some comments on the matters here.
I think that this is a bug. I’ve pushed a fix for v5.3.6 here:
1 Like
In the past, I’ve disabled plugins in my host wiki, passed them to my innerwiki and they work, I assume you could bundle your new wiki with tinka as a plugin kinda like tiddlywiki-docs, then disable in host and pass to innerwiki. And of course changes could apply this way to, making the content hidden/not effect the host wiki at all. A thought.
Right. A cool idea would be to package/hide everything in a plugin to transfer it. I wonder if wiki settings could be transferred like this though… that would make double instances of shadow tiddlers… which one wins? Other conflicts?
1 Like
That… is an interesting question I think yes, by default I do believe plugins override core so I think you can package settings changes and stuff like that as tiddlywiki docs does this. Mileage may vary
Edit: You can make custom tidders with <$data> if need be allowing these variables to change and not effect the host wiki