Maintain toc-tabbed-internal-nav structure after static site export

[Glenn Dixon]

My local TW uses toc-tabbed-internal-nav and each section expands when clicked. But if I export the site, nothing expands when clicked, so all the sub-tiddlers are inaccessible.

Do I need to do something special with the export code?

[TW Tones]

I think you are perhaps missing the point of a static site. 

Sure you could redesign the way the static site export works but the TOC internal nav uses macros and widgets that are not active in a static site by definition.

Why are you using a static site?

My personal interest is a static site where all static pages links are to the tiddlers full wiki, with a splash screen to warn of loading.

• The static site would then have static tiddler files for search engines etc... but as soon as you need interactive features it loads the full wiki.
• You could generate a static html tiddler from your  TOC internal nav then export that. Keeping in mind it becomes static ie does not respond to interactive code.
• It may be possible to generate a site index and robots file to support single file wikis without a need to export a static site.

Regards

Tones

[Glenn Dixon]

I assure you, I am *not* missing the point. :) Most of my static sites are html, but they also tend to have at least a splash of javascript. The whole 'jamstack' thing. Generally just for menu toggling, similar to what the macros do inside TW.

I am using a static site because I want to simply display my TW publicly, w/out being editable. So are you saying that's not possible w/ the single-file TW? Would this be easier w/ the node.js version?

[Glenn Dixon]

ok, I should update this. While the 'toc-tabbed-internal-nav' is nice for displaying, it's not so great for actually *using* on my local desktop. As in, you can't actually open any individual tiddlers from that view. Which kinda defeats the purpose, no?

So, back to a more traditional TOC structure. Unfortunately the expandable items are still NOT expandable in the exported HTML files :( So - I'm back to square one on my original question...

[Glenn Dixon]

as a follow-up, I am now back to a single-file TW. I am also no longer invoking the TOC via macro, just simple HTML using toc-selective-expandable. For some reason using the macro was indenting everything, adding ordered list numbers, and causing most entries to wrap and generally creating chaos in the layout display.

[Glenn Dixon]

Re-reading your email here. I think one issue I'm having is that I don't expect much, if any, interaction on my existing static sites. Wikis are, by definition, interactive! So if you post your wiki publicly and someone makes a change or an addition, how do you capture the new information back to your other copies of the wiki? Also how do you prevent spam?

On Friday, December 18, 2020 at 10:13:34 PM UTC-6 TW Tones wrote:

[TW Tones]

• Interactivity can be as little as responding to a search request, building an index or allowing User Interface customisations. 
• Unless they have save permissions they can at best save changes in their browser and never commit the change to the website.
  • No spam
• Unless you are prepared to allow users write to the website you need to build other methods for their changes and feedback to be sent to you.
  • eg generate a file they can email to you.
• "Bob and Bobexe" offers a multi-user multiple-simultaneous access solution on a per-tiddler basis if you need multiple simultaneous editors.
  • But that is node server based and a little more complex to make it internet facing.
• I may be wrong but I consider static to also mean all that is active is HTML and Links (thus javascript is not part of it, unless to export supporting javascript) then the site is no longer "static".

I hope that helps "frame the issue". 

Tones

[Glenn Dixon]

TW,

If you look at the current working usage of the term 'Static Site Generator' - especially in the new Jamstack context - you'll see that having javascript in html is presumed. So they are plain html, but with many scripts and connections to 'microservices' and API calls, etc. So not the original usage of 'static' but still superfast and if javascript is turned off most of the content is still there. And they *can* still be non-javascript, depending.

Any way, I think I would be happy with a wiki with a sidebar menu that collapses/expands and comments that somehow save to each tiddler. I have this working inside my own local wiki, just have not been able to get it running on my VPS web server. The workflow will not conform to my usual SSG > Github > Netlify workflow for my 11ty sites. At least I haven't figured out how to do it yet.