Thanks for clarifying, Tones and Soren. I had the impression that TiddlyWiki was more cookie cutter, or could be if I didn't add or alter code. "A no-code personal wiki system," I heard TW called. But yes, I was seeing this as a future-proofing mechanism where I might want to migrate some- or everything stored in TiddlyWiki to a different platform in the future.
For more context, I was trying to set myself up to be able to transfer my info from a digital garden on a more cookie cutter platform to a later less cookie-cutter one, once I learned to code a bit. Starting "non-technically," in the sense Maggie Appleton's articles impressed on me. https://github.com/MaggieAppleton/digital-gardeners https://maggieappleton.com/nontechnical-gardening It seems I still misunderstand the question of going from a manageable Digital Garden to a more complex one, not having data transfer be an issue. On Thursday, August 19, 2021 at 8:36:03 AM UTC-4 Soren Bjornstad wrote: > As Tones said, I think we need a bit more information about what you're > hoping to accomplish to give a complete answer. Are you seeing this as a > future-proofing mechanism where you *might* want to migrate something > stored in TiddlyWiki to a different platform in the future? Or you want to > use TiddlyWiki as a CMS and then publish using a different tool? Or > something else? > > On a straightforward level, it's possible to quickly render some or all > tiddlers to HTML, at which point you can post-process them using whatever > tooling you want. I've been using this to crosspost my sabbatical updates > from my Zettelkasten > <https://zettelkasten.sorenbjornstad.com/#SabbaticalUpdate/20210813> to my > Jekyll blog > <https://controlaltbackspace.org/sabbatical-updates/week-2-neatening-up/>, > using the following rule in my Makefile: > > sabbatical_updates := $(wildcard > zettelkasten_dir/tiddlers/SabbaticalUpdate*) > sabbatical_files: $(sabbatical_updates) > rm -rf /tmp/twout > cd $(zettelkasten_dir) && tiddlywiki --output /tmp/twout --render > "[prefix[SabbaticalUpdate/]]" "[is[tiddler]addsuffix[.html]]" "text/html" > '$$:/sib/Templates/Export/SabbaticalUpdateCabCrosspost' > python3 automation/crosspost-sabbatical-updates.py > /tmp/twout/SabbaticalUpdate/* > > The Python script is about 70 lines and primarily sets up a YAML header > with appropriate metadata so Jekyll understands what to do with the post. > This is also the purpose of the > $:/sib/Templates/Export/SabbaticalUpdateCabCrosspost template -- it embeds > certain fields in the HTML where this script can retrieve it. If you > preferred, I think you could use pandoc at this point to convert back to > Markdown or a similar format; since I'm keeping my source of record in > TiddlyWiki, I'm fine just leaving the posts as HTML in Jekyll. > > Of course, if you take advantage of dynamic features of TiddlyWiki that > can't be represented as HTML with 100% fidelity, e.g. dynamic lists based > on filters or displays of backlinks, you'll end up losing some > functionality when you do this. > > On Wednesday, August 18, 2021 at 2:31:10 PM UTC-5 jamm...@gmail.com wrote: > >> I'm looking to see what the transfering of tiddlywiki to a more >> self-coded platform, such as jekyll, gatsby, or others, can look like. My >> concern is the transition being difficult, long, etc. Any resources? >> > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/d3b80bb4-7a4d-404f-9d33-c67dc02aa147n%40googlegroups.com.
