Is there a plugin/extension mechanism for the tiddlywiki Node script itself?

I understand the tiddlywiki plugin mechanism, and have recently written one myself. I don’t want to ask about that. What I’d like to know is whether there is any extension mechanism for the Node.js script “tiddlywiki”?

Or if not, is there some nice way to handle what I want to do?:

I’m writing a documentation wiki that will be served mostly in a read-only format. I’ve been editing it by running the Node version locally, pushing it to GitLab, and serving it through GitLab pages, using a read-only mode mostly borrowed from Mohammad Rahmani’s TW-Utiliy plugin. This workflow has been fine when I’m the only author. But there will soon be others, and I’d like to simplify it to run the Git integration from inside the wiki, if that’s possible.

Any suggestions for how to do so would be welcome. My thought was to integrate another action to the save-wiki button that said something like “Push to Gitlab”, popped up an input for a commit message, and then passed that back to the server, so that it could do a push to GitLab. But that would involve the server knowing how to push to git, and I assume that’s not built in. (There are other open questions about auth, and so on, but if I can’t get the Node server to do this, then those aren’t worth pursuing.)

I have read Mohammad’s GitHub Saver tutorial, and I might look into that if this doesn’t work. But I really want the git granularity of separate tiddler files in the commits.

So, is there a way to add functionality to the tiddlywiki script without forking it? (This is absolutely not important enough for me to try a fork. Even if I weren’t too new at this, the other content writers are all competent git users, and we can work it out… although the StoryList will be a headache.)

Or is there another useful way to handle this so that the content is regularly checked into a shared git repo?

1 Like

Hi Scott,
I know there are simpler solutions. For example @saqimtiaz uses GitHub actions to publish a TW as a GitHub page using the public tiddlers when a new tiddler is changed and pushed to GitHub.

Also you may like to see the workflow by @sobjornstad or the one by @linonetwo.

I am sure there are other solutions I cannot remember all of them.

1 Like

That’s what I’m doing now (GitLab, not GitHub, but the same idea.) It works all right, and will be extensible to multiple editors, although with concerns about `$:/StoryList. But it would be cleaner if I could initiate that push to GitLab from my TW editor interface.

I’ll take a look if I can find them. Thanks.

As to $:/StoryList, I think it’s safe to simply not commit changes to that file (adding it to .gitignore.) Is there any reason that I cannot simply ignore this tiddler when publishing?

It is not required, and you should be able to ignore it!

1 Like

Supposedly you can launch various scripts from inside TW Desktop, which I assume means you should be able to from Node as well (since it has local file access). This thread may or may not give clues:

But it might depend on your operating system.

Another thought is that you could have a batch script that works on a loop. When it sees a certain tiddler appear (because you’ve just created it using a button) it automatically performs your git action and then deletes the tiddler. We used to do this trick when making our own DIY print-server back in the day.

Thank you. I’ll take a look.

That’s a very interesting thought. I could do that easily enough in Node, and I probably wouldn’t even have to delete it, just note recent modifications. I’d have to investigate the communications back to the user. I don’t know if changes ever come back the client side when changed on the server except during refresh, so I might not be able to communicate git save problems clearly, but I probably wouldn’t mind insisting on a refresh at that point if the user wants to know. Thank you very much. This would probably work and would likely be fairly easy to implement.

Cant you just se the default tiddlers?

Well of course the single file wikis save mechanisum uses the $:/core/save/all tiddler and there are already exceptions to the wiki save.

\import [[$:/core/ui/PageMacros]] [all[shadows+tiddlers]tag[$:/tags/Macro]!has[draft.of]]
\define saveTiddlerFilter()
[is[tiddler]] -[prefix[$:/state/popup/]] -[prefix[$:/temp/]] -[prefix[$:/HistoryList]] -[status[pending]plugin-type[import]] -[[$:/boot/boot.css]] -[type[application/javascript]library[yes]] -[[$:/boot/boot.js]] -[[$:/boot/bootprefix.js]] +[sort[title]] $(publishFilter)$
  • Here we would just add -[prefix[$:/StoryList]]
  • Regardless of course the initial value for the story list is set according to the default tiddlers $:/DefaultTiddlers and unless it includes [list[$:/StoryList]] and even if saved it is overridden.

I’m using a slightly different approach to create my example editions for WikiLabs.

I do have an eg: “docs-server” edition and a “docs” edition. … The -server edition is used to locally edit the documentation content

The docs-server uses the option

"includeWikis": [
	"config": {
		"default-tiddler-location": "../docs/tiddlers"

So, the server will load all tiddlers from docs edtion and it will create new tiddlers there too.

So the docs-server edtion only contains stuff, that is usefull for editing and the $:/Defaults and $:/StoryList … So they don’t pollute the docs-edition.

The docs-server also contains the tiddlyweb and filesystem plugins, which should NOT be part of the single file wiki

Additionally the docs-server edtion contains a package.json file, that includes all the scripts, needed to test, build and publish the docs-edition.

The whole process is not fully automated. The last step - pushing all my editions to GitHub is done manually. So I do have the chance to do 1 final check before I publish something.

My workflow looks like this. eg:

cd /path/to/docs-server
npm start

Will start the development server with all the utility plugins, that make editing easy.

cd /path/to/docs-server
npm run build

Builds a local docs.html single file wiki for easy testing

cd /path/to/docs-server
npm run stage

Will build a local docs.html edtion and copy it over to the staging area, which is a separated repository, for final testing.

cd /path/to/docs-server
npm run deploy

For me does the same thing as stage and prints a message:

"deploy": "echo # deploy is done with repo!"

Hope that makes sense. You can have a closer look at 2 of my repos that work that way.

editions/bundler-server at master · wikilabs/editions · GitHub and
editions/bundler at master · wikilabs/editions · GitHub

It works very well for m, but is not perfect. The next time I would do it a bit different. At the moment I use 1 editons repo, which contains all edtions and servers … I would split them the next time, so every plugin gets its own repo with server, edtion and plugin directories in 1 repo.

IMO that’s exactly the usecase, that you discribe

have fun!

The problem is at the git level, where this file is overridden continually. With multiple people working on the project, there will be inevitable conflicts over this file. But it sounds like I can simply exclude it from the git commit without harm, as others here have said. So I think that part of the problem is solved.

Ah, I think I ran across that when I was still too new to understand it. It all makes sense now, and maybe I can use that instead or as well. Thank you very much.

This workflow sounds like it might match. The big thing I’m trying to solve for is starting repository cohabitation :slight_smile: with coworkers. Since they are far newer to TW than I am, and we know there’s a learning curve in that, I want the rest of their path to be as smooth as possible. For me alone, my current workflow is almost sufficient.

But today’s all about content. I’ll read this more carefully tomorrow and look at your examples. Thank you for sharing.

1 Like