Github user cdruan has made a TiddlyWiki plugin for externalizing TW core and plugins !
@telumire @Mark_S thank you! This is amazing. I’m really keen to make Tiddlyhost support this style of TiddlyWiki. This issue is tracking it.
There may be some limitations. My attempt to try it on one of my larger TWs (8mb) immediately got the RSOE, and I was unable to proceed further. Possibly it only works with 5.2.1 ?
Edit – problem plugin:
Motion - Vim-like keyboard shortcuts for TiddlyWiki.
Edit – misc problems
Some plugins might not be identified?
Edit - status
Worked with all but one of my current plugins. Some plugins are lacking the “name” field and don’t show up on list. Can I safely externalise them? The two plugins I encountered without names were:
- TiddlyClip
- GoToShortcut
Maybe …? Could you try to upgrade your wiki to the latest version before converting it ? If it still doesnt work then that’s a bummer
I noticed the same thing and did it anyway, on my wiki everything works fine - but just in case it’s always best to keep a backup
Is this compatible with TW 5.2.3? I assume this solution also externalize core, where in 5.2.3 TiddlyWiki itself support externalizing the core but not the plugin (already done by @cdruan).
You can now try a “external core” TiddlyWiki on Tiddlyhost.
See a demo here or try it out yourself by clicking “Show more types” when creating a site.
Right now it’s considered experimental, so it’s better not to use it for important stuff. Let me know if you find any problems.
Not so much a problem but have you considered using a CDN as raised earlier?
- It will potentially reduce the demand on your infrastructure a great deal.
Small (310kb) and loading is really fast!
Yeah definitely. Though even without that there’s still a large benefit for Tiddlyhost’s traffic and workload in general.
Actually I’m hoping they will be eventually be uploaded somewhere for all to use, as suggested in #7091.
And I added there
Great stuff, just consider being able to load a different core as per the TiddlyWiki version, maintaining back versions . Ideally this would be automatic, and please consider if the core can be switched to a new version later.
Thanks for describing the problems you’ve encountered. I’ve added a fallback display value when a plugin’s “name” field is missing.
As for the problem with the motion plugin, it could be fixed if you modify the content of the $:/plugins/benwebber/motion/modules/startup/motion.min.js
tiddler near the top:
The value of exports.after
should really be “render” instead of “startup”, e.g.:
exports.after=["render"]
Its init function tries to access rootWidget’s children, but they are only instantiated after the “render” module. It just so happens in the regular startup, this module is called after render, but unfortunately, in external-js mode, this startup module is moved up before render, causing the crash.
Hope this helps.
Welcome to the forum cdruan !
With your plugin, is there somewhere we can configure or overwrite to set:
- The path to the core library
- The path to the plugin library
These two paths are likely to be different, since there might someday be a universal core library location, but users will need to maintain their own particular plugin libraries.
Thanks!
You can, edit the files $:/config/ExternalJS/Prefix/Plugins and $:/config/ExternalJS/Prefix/Core, without the version and extension, example :
You need to do that before exporting the core and plugins
Thanks for the fix. I’ve released a new version of motion that changes its startup order.
I’ve just set up a simple external-core site via tiddlyhost. I did successfully save once – after modifying just the site title. But every attempt to save, after that first one, is prompting a “file changed on server” rejection. (At first I thought it was something about the mass of imported tiddlers I brought over. But I’ve reloaded the simple site and tried tiny changes, always the same result.)
Hmm, I can’t reproduce it. Generally that message should go away if you reload the site first. Maybe try a shift-reload to ensure it really does reload…?
About the tw-external-js plugin:
That’s correct, but I needed to make some tweaks to the plugin so filenames can be extracted properly from custom core/plugins urls. So, if you’re interested in configuring the library url, you’d want to retrieve the updated version (>= 0.1.3).
It was a robust problem (across computers, browsers) until I tried, just now, downloading the file from the tiddlyhost dashboard (a file which, as expected, could not open on its own) and then re-uploading it. Now saving is working fine. But it’s worth keeping an eye on whether the glitch happens again.
I’m surprised. It’s loading the file via a relative path. So it won’t reduce TH’s overall storage load unless behind the scenes the library is a symbolic link to a central library.
You can fix this in your own TW by (while still on TH) editing tiddler
$:/core/save/offline-external-js
Change the macro definition coreURL to:
\define coreURL() https://<your tiddlywiki name>.tiddlyhost.com/tiddlywikicore-5.2.3.js
Where <your tiddlywiki name>
is the name of the file that you have externalized (is that a word?). Save. Then download from your TH dashboard. Now you should be able to use that downloaded file as you would a stand-alone file, as long as you have an internet connection.