Developers ... have you used InnerWiki?

[TiddlyTitch]

@pmario

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”

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

[pmario]

@TiddlyTitch

I was hoping for use cases already.

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.

Show GettingStarted with Options Screenshot

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.

[pmario]

@pmario

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

[TiddlyTitch]

@pmario

It should be possible to use a “Full TiddlyWiki” with all plugins, languages and themes to create a “configurator” to create new wikis.

FYi, in InnerWiki the Child Wiki can have Active Plugins on after virtual boot without save, and even if Mother has them disabled.

[TiddlyTitch]

@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?

[TW_Tones]

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

[btheado]

@pmario

In the TW dev wiki the innerwiki is used to show the “widget tutorial examples”
Eg: Hello World Widget Tutorial

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.

@TW_Tones

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.

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.

[Scott_Sauyet]

@btheado

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.

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!

[btheado]

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).

[TiddlyTitch]

@Scott_Sauyet

I have kept ignoring innerwiki as it seemed to offer me nothing I wanted, but this is brilliant!

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

[TiddlyTitch]

@btheado

@pmario

In the TW dev wiki the innerwiki is used to show the “widget tutorial examples”

Eg: Hello World Widget Tutorial

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

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.

[TiddlyTitch]

@TW_Tones

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.

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

[Yaisog]

@TiddlyTitch

FYI. I was surprised as a non-dev that devs are (seemingly) not in decent numbers gung ho for it (except @btheado).

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.

[CodaCoder]

@Yaisog

I couldn’t get the browser debugger to work with the inner wiki

It’s an iframe – what’s the issue exactly?

[Yaisog]

Hi @CodaCoder, the debugger always hooked into the parent wiki, I couldn’t e.g. set JS breakpoints and such in the Sources panel.

[TiddlyTitch]

Making progress on a Tiddlywiki Breeder. With options …

[TiddlyTitch]

@Yaisog

the debugger always hooked into the parent wiki, I couldn’t e.g. set JS breakpoints and such in the Sources panel.

l’m not a developer so I’ll likely be idiotically wrong! …

I had thought some dev tools could isolate iframes and just observe them only?

I read this about Firefox dev.

Just a thought,
TT

[TW_Tones]

I suppose it is about what you want to achieve because a generated wiki can use tiddlywiki tools but on saving a wiki you could run it in its own tab.

[Yaisog]

Hi @TiddlyTitch and @CodaCoder, I looked again at InnerWiki and DevTools and it wasn’t hard to find out how to use it with the InnerWiki iframe. I have no idea why I failed before. Using Brave now and might have used Edge in the earlier tests, but that shouldn’t make much of a difference, both being Chromium-based. They don’t have the iframe isolation button that Firefox seems to have, but e.g. the Sources panel presents the iframe sources separately and lets me set breakpoints and whatnot to aid in debugging.

Anyway, I’ll be using InnerWiki again for working on JavaScript modules from now on.

[TiddlyTitch]

@pmario

In the TW dev wiki the innerwiki is used to show the “widget tutorial examples”
Eg: Hello World Widget Tutorial

That took me a little while to understand as JS is not my thing.

The simple <$data> Payload system of InnerWiki I find easier to grasp.

But I’m thinking, I guess, most about a “wiki-maker”; rather than educative tutorials (good as they are).

Best, TT