I have a custom node server that runs a few panels and other stuff that I want to access from multiple computers around the house. I would love to also host TiddlyWiki there, but I don’t want to have to manage two node servers. Is it possible to idk import tiddlywiki package into my node server and run it from there?
Not sure - someone else might give you a direct answer.
However, FWIW, I use TiddlyServer which itself is a node server allowing you to use node-based TW AND flat file wikis at the same time. It’s self-contained – I never have to “manage” it other than starting and stopping it on extreme rare occasions.
Look - over four years old…
Oh, I forgot, I edited settings.json a few days ago
Really the important part is I want them running on the same port as different “pages” That’s easy with a static site, but having it auto-save makes it more difficult. I was hoping I could somehow pass it from one node server to another to take care of it for me.
I’m not sure I follow; are you asking to have TiddlyWiki running on one host, while access occurs from other hosts on a connected network?
That’s what I do. TiddlyWiki is housed on an internet system under HTTPS, with passwords of its own, so it doesn’t matter where the user access occurs. Is that, at least sort of, what you have in mind?
In-house access (on, say, 192.168.12.34), in multiple instances, was what I was doing before we wanted to get at it from Out There.
I have a server running on an IP + port. It would be nice to have a tiddlywiki running on that port as well. I wish to have my express-js route to it when a certain page is called on that IP + port.
It seems that this is possible with express-http-proxy. I’ll try that, but if anyone knows a way to do it directly that would also be nice
To be sure: by “port”, we mean, say, “port 443”, the port used by a web server on HTTPS – or “port 80” on HTTP?
So, there’s a web server holding that port, which is why we can’t just tell TiddlyWiki to use said port. Correct?
If that is your aim, then yeah, you’ll have to tell the process which houses the port to pass the traffic along to TW-or-whatever. If I misunderstand…
The port 443 one. You have it right. That’s why I was wondering if I could incorporate the tiddlywiki server into mine. Instead, I likely will just have to use a proxy.
Yeah, one port, one program. “Proxy” just means the web server you’re using (I’m unfamiliar with it, but anyhow) passes the traffic along. So I think that’s the answer to what you want to do. “Proxy” doesn’t mean anything bad, in this case anyhow.
(Anyhow.)
Yep, I know. There would be some small benefits to not having to use a proxy, which is why I went that route first, but as far as I can tell that route is a dead end.
Well thanks
You can, see TidGi for example TidGi-Desktop/wikiWorker.ts at e1abf4f30f730a023f52428131fb463e185daadc · tiddly-gittly/TidGi-Desktop · GitHub
You can just run code using worker_thread, so each tw can have its own memory space.
that’s helpful, thanks
I was trying to get this line to work, but endless errors:
const wiki = spawn("tiddlywiki", ["tiddlywikis/mynewwiki", "--listen", `port=${port+1}`, "path-prefix=/tiddlywiki"]);
I think error message will give you some clue.
But I use wikiInstance.boot.startup({});
instead to avoid most of the problems.
using spawn will require the tiddlywiki
“bin” to be in the “path”, which may be a problem for your script.
Thanks a lot, that works far far better.
The only issue I have now is a head request fails. Does not seem to effect anything, but I don’t like 404 errors:
Request URL: http://127.0.0.1:7300/tiddlywiki
Request Method: HEAD
Status Code: 404 Not Found
Remote Address: 127.0.0.1:7300
Referrer Policy: strict-origin-when-cross-origin
My one other issue you may know the answer too is to use a custom path with the proxy (which I need to do) I need to:
- Configure the client by creating a tiddler called
$:/config/tiddlyweb/host
that contains$protocol$//$host$/path/to/my/wiki/
Now the server this is running on my change. Is there a better way dynamically set this tiddler other than just creating / editing the file? Maybe through the tiddlywiki package?
I think these little erros is totally ok, HEAD and OPTION 404 is common, they may just be auto preflight check sent by the browser.
I think you can package these files as a plugin, and use them like TidGi-Desktop/wikiWorker.ts at a660d989f69a54abb51136ab44779ff9caf52fc9 · tiddly-gittly/TidGi-Desktop · GitHub
Plugins are just pack of files that will be added to the started wiki.
hmm, great idea, but the only issue is I need the path to the wiki to be dynamic based on the name of the folder it stores.