Using file:/// does not make tiddlywiki work; it opens the functional tiddlers to a new browser TAB
Any reply would be greatly appreciated
Can you just export the tiddler then import it via control panel or import option. Will it solve your issue ? Or just drag and drop the tiddler ?. I’m completely new here. I tried something similar and it solved …
1 Like
I just want to suggest if we had the context there may be other solutions. On Node JS there is an option for skinny tiddlers, and as we do with external images there may be better options that already exist.
- With single “file wikis” a file in the current source folder can be referenced with a relative fieldname.
Further, we need to ask the question “when”.
- Is it on wiki load?
- Is it on another trigger like a button?
1 Like
I expect it (single-file tiddlywiki) to be able to preload external functional tiddlers and apply functionality to single files without importing those external files, just as tiddlywiki references external images
Then there are a range of ways to do this, but there will be limits if not imported.
TiddlyWiki is ultimately a html document, if it can be done in a html document it can be done in tiddlywiki, however it is done according to tiddlywikis platform structure to keep it Complient.
You can use HTML methods like the object tag, use tiddlers with one of the “raw” tags, and more recently the message HTTP Request from 5.x.
- For example you can have an external stylesheet.
Can you share a simple real world example of the kind of content, why and what you then want to do with it?
- I don’t have all the answers here, but I do think I am asking the right questions.
1 Like
I haven’t yet seen a single-file solution that incorporates tiddlers from other locally-hosted wikis (though I would love to be able to do this), but @saqimtiaz has an ExternalContent plugin which will import content from an online wiki.
His approach does import the external tiddlers when the wiki is loaded (and frankly, I’m not sure it would be possible to work with tiddlers without importing them). However, you can choose to exclude external content from the publishFilter. This means it won’t get saved with the rest of the wiki, and thus it’s not permanently imported.
Depending on your usage needs, you may also be interested in the External JS plugin, which lets you move 1) the $:/core plugin and 2) any other plugins of your choice into external .js files, which will be incorporated into your wiki at load time but don’t get traditionally imported.
There are a few limitations:
- This plugin only externalizes plugins, so you’ll need to package any “loose” tiddlers into one or more new plugins.
- Externalized plugins still function like normal plugins: any changes you make to a shadow tiddler will get saved in a standard tiddler, which will be part of your wiki’s internal tiddler store.
- To make changes to the shadow version in the external file, you’ll need to update the plugin (with Tinka, for example) and then save a new copy of the external .js file to your folder before closing or reloading the wiki. Otherwise, your updated plugin(s) won’t get saved and your wiki will use the version saved in the folder next time it loads.
- All the non-core plugins you externalize in a given wiki will get saved to the same .js file.
- You can’t use External JS to incorporate auxiliary plugins from multiple external files—at least the way it’s currently written.
- I haven’t tried to change this, and I’m not sure how difficult it would be to do so.
However, if your primary goal is to reduce this size of your single-file wiki and/or to share a set of plugins between multiple offline wikis, the External JS plugin is a good option, and it’s the one I use myself.
1 Like
Thank you very much for thinking about shortcuts, my technology god, my goal is really to reduce the size of the single file wiki, because when it reaches 10mb I am afraid (computer local configuration is not too powerful), I first tried $:/plugins/cdr/external-js this plugin, The size of my test single file wiki is 4050kb, the pure web page after being stripped is 624kb, reduced by about 6.49 times, and the sum of all files after external data (myplugins-5.3.3.js:2153kb; tiddlywikicore-5.3.3.js:1189kb) is 84kb smaller than a single file, which is really amazing
Some minor problems: If there are multiple tiddlywikis installed in the same folder, but there are a few shared plug-ins, is it possible to strip out the common ones and save each unique plug-in content on a single file? Is need to upgrade them all to the same version to share the tiddlywiki external core as the other affiliated tiddlywiki versions in the folder?
Well, I’ve found a viable solution to modify the source code here, changing the myplugins-5.3.3 generic name to a custom name to accommodate custom references to different Tiddlywikis
Next I will try the tinka and gatha plug-ins
Please test these changes, after you did a new save. I’m pretty sure your custom changes have been overwritten.
What you do here is named “premature optimizations”. IMO If and only if you will have problems once your wiki reaches 10MB you should tackle the problems that may come up. The solutions to the real problems that come up may be different to the “solutions” you installed here.
The system you describe IMO gets more and more complicated to maintain… So for me it seems you put a lot of maintenance burden upon yourself for no real reason.
Experimenting with the possibilities is OK. But leave your “productions” stuff alone until you really need those “improvements”
Just my thoughts.
2 Likes
What RAM and disk is available on your computer, I don’t expect 10Mb wikis to be a problem. My Key wiki is at 12MB and I have had 20Mb one running well in the past. If it is slow to load, consider adding a splash screen, once loaded it usually performs well.
2 Likes
Splitting your wikis won’t help here if you want to reduce RAM or CPU usage, because a TiddlyWiki wiki must be fully loaded before it’s able to operate.
There’s an exception called lazy loading, mainly used for multimedia content (images, videos, PDFs), but the code (core + plugins + tiddlers) must be available anytime.
IMHO splitting wikis is mainly for network bandwidth or storage size reduction.
Fred
2 Likes