Changing $:/DefaultTiddlers doesn't have any effect when using TiddlyWeb plugin

[ghost]

The GettingStarted tiddler is all you ever see at startup. The wiki always uses the embedded $:/DefaultTiddlers (which contains the text GettingStarted), not trying to load it from the server:

https://github.com/Jermolene/TiddlyWiki5/blob/f9b4f747a13bc06bf48d4e97ea2424ad90b5b738/boot/boot.js#L945

[tobibeer]

Is the root of this problem perhaps the same as for #2693 where the server doesn't load the non-skinny version?

[ghost]

That's a separate one.

[Jermolene]

Hi @opennota it sounds like this is the same lazy loading problem we've discussed elsewhere: $:/DefaultTiddlers is used at startup, and thus needs to be baked into the HTML file, rather than dynamically loaded after startup.

[ghost]

@Jermolene Is there somewhere the full list of such "startup" tiddlers?

[ghost]

$:/SiteTitle and $:/SiteSubtitle are also used at startup, but they can be loaded lazily, and it works fine.

[ghost]

This is the server I use.

[ghost]

Russ Cox commented out the call to openStartupTiddlers here: https://github.com/Jermolene/TiddlyWiki5/blob/2f21cbc971c43595d4fe2691dd6db9584b7217d2/core/modules/startup/story.js#L33 While it doesn't solve the problem in question, it makes the wiki to keep the story between reloads.

[pmario]

While it doesn't solve the problem in question, it makes the wiki to keep the story between reloads.

Hmmm, Why don't you use the ControlPanel settings?

ControlPanel: Info: Basics: ... DefaultTiddlers set to: [list[$:/StoryList]]

There is a button right below the text area, that let's you set the right value, so you don't need to remember it.

[ghost]

@pmario

Why don't you use the ControlPanel settings?

Because, as I already have said, DefaultTiddlers are ignored by the wiki in the remote setup.

[danielo515]

Dear @opennota

This is a problem I have reported already, and it is a well known issue. I successfully addressed most of those problems on my own edition: NoteSelf. Some of the problems I faced and resolved includes:

• Ability to setup DefaultTiddlers
• Ability to install plugins and make them work
• Ability to create javascript macros
• Soon, I will publish a fix to load global macros too

All the above features usually requires to create a new html file, in my edition that was not possible because it is an online service. Everything works just reloading the browser.

Note that my edition it is a product targeted on my own needs, and it may not fit your requirements. But my point is, that after opening several issues here I ended creating my own version , so don't expect this to be resolved soon. If you want to take a look at my project the official page is at noteself.github.io

[tobibeer]

To me it sounds like something wants either refactoring or a kind of technical documentation that says: this is how it's (expected to be) implemented on this end and on that end in a client-server environment.

[Jermolene]

@tobibeer I think the situation is relatively simple.

The core is currently designed in such a way that tiddlers required at startup must be baked into the HTML file, rather than delivered asynchronously via the sync adaptor.

It doesn't affect things when using TW5 as it's own server, but tends to be a problem when using other server architectures which aren't set up to bake tiddlers into the HTML file.

[tobibeer]

It doesn't affect things when using TW5 as it's own server, but tends to be a problem when using other server architectures which aren't set up to bake tiddlers into the HTML file.

Precisely, this is what I find to be a blind spot when it comes to designing a sync implementation: the question of how the TiddlyWiki is baked that provides sync-abilities... but leaves the user enough room for customization, e.g. templates, macros, styles, themes, plugins, etc...

In the core, we have a tiddlywiki.info file that "prescribes a recipe" ...for other sync-server-environments, this bit of baking a deliverable appears to be somewhat missing from the picture... especially questions of how to extend and amend a given "sync-foo"-custom-core... since often, those extensions are possibly not delivered through the basic syncing mechanism.

[tobibeer]

So, the question perhaps is: What part of a full TiddlyWiki is being synced and what part isn't... and for the latter, how that comes into existence for a given sync-implementation.

Of course, we all know that we can just bake stuff into a TiddlyWiki under node or add stuff directly in the browser, but he distinction between the "sync application layer" and the end-user-wiki is perhaps too blurry, which is why I believe that there may be a slight lack in terms of abstraction when it comes to sufficientl encapsulating a sync mechanism while being able to extend the actual wiki core as needed.

In general, I think I would prefer syncers to be modules / plugins, that have a defined spot in the ControlPanel and where I can configure for each and every syncer what I want it to sync and where and what not to, e.g. via filters.

[ghost]

@danielo515 Thanks, I'll look at it.

[Jermolene]

Hi @tobibeer

Precisely, this is what I find to be a blind spot when it comes to designing a sync implementation: the question of how the TiddlyWiki is baked that provides sync-abilities... but leaves the user enough room for customization, e.g. templates, macros, styles, themes, plugins, etc...

The TiddlyWiki HTML file to be served is specified as the title of a tiddler via a parameter to the --server command. The user can customise the template to determine which tiddlers (or other elements) are included.

In the core, we have a tiddlywiki.info file that "prescribes a recipe" ...for other sync-server-environments, this bit of baking a deliverable appears to be somewhat missing from the picture... especially questions of how to extend and amend a given "sync-foo"-custom-core... since often, those extensions are possibly not delivered through the basic syncing mechanism.

I'm not sure what you mean here. Are you asking for better instructions for how to customise the HTML file that is initially served?

So, the question perhaps is: What part of a full TiddlyWiki is being synced and what part isn't... and for the latter, how that comes into existence for a given sync-implementation.

Are you asking which tiddlers get synced? There's a well-documented filter that determines which tiddlers get synced.

Of course, we all know that we can just bake stuff into a TiddlyWiki under node or add stuff directly in the browser, but he distinction between the "sync application layer" and the end-user-wiki is perhaps too blurry, which is why I believe that there may be a slight lack in terms of abstraction when it comes to sufficientl encapsulating a sync mechanism while being able to extend the actual wiki core as needed.

I don't know what you mean by "sync application layer". It sounds like you're asking for better documentation for how the syncer works, is that right?

In general, I think I would prefer syncers to be modules / plugins, that have a defined spot in the ControlPanel and where I can configure for each and every syncer what I want it to sync and where and what not to, e.g. via filters.

That filter exists, and can be customised, but is not exposed in control panel. Given the cost of including UIs (in terms of translations, testing etc.), I'm not inclined to put core UIs on seldom used options.