The InnerWiki is fascinating.
The recursicve fundamentals of TW get in plain sight.
Have you used it?
For what?
1 Like
In the TW dev wiki the innerwiki is used to show the “widget tutorial examples”
Eg: Hello World Widget Tutorial
That’s the only usecase I know and that’s what the innerwiki plugin was developed for. To create examples, that do not mess with the “host wiki”
But the innerwiki is very heavy weight, since it creates a completely new TW instance in an iframe, the testcase-widget was developed. It works similarly but does not create an iframe and no new TW instance.
1 Like
Okay.
What if I used a PAYLOAD to create a New Wiki dynamically …?
<!--- DOCUMENTATION & OPTIONS ---------------------------->
<$data $tiddler="twBasic+ MANIFEST" />
<!--- this tiddler --->
<$data $tiddler="twBasic+/payload" />
<!--- SETTINGS ------------------------------------------->
<!--- wiki naming --->
<$data title="$:/SiteTitle" text="twBasic+"/>
<$data title="$:/SiteSubtitle" text="A base TW with minimal tweaks, plugins & themes"/>
<$data title="$:/config/SaveWikiButton/Filename" text="tw-basic-plus" />
<!--- social card --->
<!--- created tiddlers --->
<!--- sidebar --->
<$data title="$:/state/sidebar" text="no" />
<!--- story river --->
<$data title="$:/DefaultTiddlers" text="[[twBasic+ MANIFEST]][[twBasic+/payload]]"/>
<!--- editor --->
<$data title="$:/themes/tiddlywiki/vanilla/settings/editorfontfamily" text='ui-monospace, "SFMono-Regular", "SF Mono", Menlo, Consolas, "Liberation Mono", monospace'/>
<!--- THEMES & their settings ---------------------------->
<!--- vanilla --->
<$data title="$:/themes/tiddlywiki/vanilla/options/stickytitles" text="yes"/>
<$data title="$:/themes/tiddlywiki/vanilla/options/sidebarlayout" text="fluid-fixed"/>
<$data title="$:/theme" text="$:/themes/tiddlywiki/vanilla" />
<!--- added themes --->
<$data $tiddler="$:/themes/tiddlywiki/tight" />
<!--- palettte --->
<$data title="$:/palette" text="$:/palettes/Blanca"/>
<!--- PLUGINS & their settings --------------------------->
<$data $tiddler="$:/plugins/wikilabs/link-to-tabs" />
<$data $tiddler="$:/plugins/wikilabs/bundler" />
That creates a bespoke wiki? Alright.
I was hoping for use cases already.
TT
Ahhh, OK I think I can “see you”. — It should be possible to use a “Full TiddlyWiki” with all plugins, languages and themes to create a “configurator” to create new wikis.
That’s a good idea.
I did create a PR in 2020 to change GettingStarted and make it more configurable, with some checkboxes that create a TOC, create a basic ToDo app, show the Home button and so on.
It got rejected with:
Jeremy wrote:
I think we need to be more ambitious: for example, a wizard that guides the user through the initial setup, and teaches them the basics of the TiddlyWiki user interface. It would have to be a plugin, of course, with some mechanism for unloading it when it is no longer useful.
At this time the Tour plugin did not exist. So now with the tour plugin, there could be a tour, that explains the different UI elements.
Then using innerwiki and do “live modifications”. So the user can see, what’s going on.
If they have a configuration, they like, they can save the inner wiki and can start from there.
I think that would be a good project for the community.
The tools are there, so no developers needed.
Starting small. Eg: There could be several small tours:
- How to show the Home button
- Close all open tiddlers
- Use the home button
- Show the Journal button
- Explain what is it used for
- Explain Tags
- Create some tags
- Create a TOC using those tags
- Enable “New Here” in the tiddler toolbar
- Extend the toc with “New here”
- Explain the configurator
- Enable the home button in my “innerwiki”
- Enable the Journal button in my “innerwiki”
- Enable the TOC in my “innerwiki”
- Explain How to create a simple TODO app
- Use that app in my inner wiki
And so on …
Every 1st level bullet can be its own “tour”. So they are small and easier to test and easy to use.
Just some thoughts.
-m
FYi, in InnerWiki the Child Wiki can have Active Plugins on after virtual boot without save, and even if Mother has them disabled.
@pmario InnerWiki is, IMO, a potential great way forward here?
I like your points. Well taken.
I also like, with skilled programming, a dev could leverage InnerWiki to be a robust “preview before save” with near infinite options?
Are we talking the same theme still?
I experimented with it as a wiki factory. make a set of editions by defining a subset of inner wikis. once you select the components open the result, review and save the inner wikis to make it permanent.
- yes plugins can disabled in the master and not in the inner
- you may need to set the filename in the inner so you don’t save over the master. including the correct tiddler will do this.
the testcase widget shares some of the same widgets as inner wiki
I think you can drag and drop into or out of the Inner wiki.
I believe it may be possible to use some of the widgets to do things beyond what they were designed for 
I wrote those examples and I still use the innerwiki approach to create new experimental widgets. I find it very convenient to be able to edit javascript code live inside a wiki and activate it right away using an innerwiki.
This is an important point as it is a very dangerous pitfall. Always be sure you have backups before experimenting with innerwiki. Otherwise, as @TW_Tones said you can accidentally save the innerwiki over top the outer one.
I use the following data widgets to help avoid it:
<$data $tiddler="$:/core/modules/savers/custom.js" module-type=""/>
<$data $tiddler="$:/core/modules/savers/put.js" module-type=""/>
<$data title="$:/config/SaveWikiButton/Filename" text=<<currentTiddler>>/>
If your outer wiki is using Tiddlystow, the first line above will avoid the pitfall. If your outer wiki is using the put saver (i.e. webdav, or Tiddlystow v2, or https://tiddlyhost.com), the second line will avoid the pitfall. The third line is how to set the filename as @TW_Tones recommends.
If you are using some other saver, you may need something similar but different.
1 Like
I have kept ignoring innerwiki as it seemed to offer me nothing I wanted, but this is brilliant! My normal techniques for Node involve editing the JS code either in the browser or in my IDE, stopping and starting the server and reloading. For single-file wikis, I edit, save, reload, and often forget my context. This could be a great improvement!
Be aware the innerwiki/data widget combination doesn’t automatically refresh when the dependent tiddlers change (same for the testcase/data widget combination). It is possible to force a dependency using the list widget:
<!-- The innerwiki doesn't refresh on its own when tiddlers on the outside change, so use the list widget to force a dependency -->
<$list name=refresh filter=[[hello.js]get[text]]>
<$innerwiki width="600" height="400" style="width:100%;">
<$data title="$:/DefaultTiddlers" text="[[hello world widget]]"/>
<$data $tiddler=hello.js/>
<$data title="hello world widget" text="[...snip...]"/>
</$innerwiki>
</$list>
If you want a dependency on multiple tiddlers, adjust the filter accordingly and take care that the filter returns exactly one result. Otherwise you will end up with multiple instances of your innerwiki (or zero instances if no matches).
1 Like
A vero.
FYI. I was surprised as a non-dev that devs are (seemingly) not in decent numbers gung ho for it (except @btheado).
TT
Exactly.
That dynamism: the InnerWiki being instantly alive…
… allows, makes easy, fosters, 1001 things. Not least …
- easy testing of code, test new wiki design, creating bespoke wiki quickly
- a superb d&d environment etc.
A vero.
To get the best out of it it needs a few InnerWiki TIPS … for example …
-
set a tiddler with $:/tags/StartupAction in the container wiki to ensure the sidebar is closed on startup
-
the tiddler containing an InnerWiki should have minimal padding & margins, left & right
-
don’t activate an InnerWiki instance from the sidebar
Doing those 3 will ensure an InnerWiki is well proportioned (good size) in it’s mother wiki. And …
- it is advisable to give the InnerWiki a different $:/palette than the mother wiki
A big issue, which @TW_Tones and @btheado allude to, is getting confused about what is the Mother wiki and what is the Progeny innerwiki. Colour helps spot the difference.
- make sure every InnerWiki has a unique $:/config/SaveWikiButton/Filename in it’s payload
That really reduces the chance of overwriting the wrong wiki.
Do you have any other Tips?
TT
1 Like
I couldn’t get the browser debugger to work with the inner wiki and therefore mostly stopped using it. If someone found a solution, let me know since otherwise InnerWiki is great.
1 Like
It’s an iframe – what’s the issue exactly?
Hi @CodaCoder, the debugger always hooked into the parent wiki, I couldn’t e.g. set JS breakpoints and such in the Sources panel.