Multi-parallel-editing of a wiki

This post is related to an earlier post regarding multi-user editing.

I am commencing a TW development for a client that will be a register of monuments related to artillery pieces in the public domain. There are currently about 9 different docx files, one or more for each state.

The project aims to build an online version and TW’s facilities are really useful here except for one issue: content elements (ie tiddlers) may require editing in parallel. So, if an item moves or more info is available, its tiddler needs to be updated and of course, this could be for more than a single tiddler at a time.

So I am trying to think of a way to manage this facility

One thought is to mimic the current file structure and provide multiple wiki’s, say one or more per state so separate states can be edited in isolation. This means though that users wanting a cross-state view need to do whatever action they require across multiple wikis.

I like the idea of the single wiki though, especially from a user perspective.

My second thought it to have a single wiki and when someone wants to edit a tiddler, they do so, store the edited file on their computer and runs a script whereby, using modification date, those tiddlers that have been modified are exported as a json file. This file can then be imported into the master wiki and uploaded to the server again. Multiple edits will result in multiple json files each of which is imported into the master. There might be an issue with two users editing the same tiddler though and I am unsure how to sort that out except by file creation time info.

Anyone got any better suggestions?

bobj

BobJ,

I have being exploring the use of tiddlywiki-app which effectivly allows access to a wiki directly or in a browser tab through node.JS.

The MWS Multi-wiki server is most likely the answer, but with MWS And the below tiddlywiki-app both work best inside a single local network where other users have access to the wiki server/host. Of course if you can VPN into that network you would be able to get access.

As a single user on my machine I have found not real clashing but it seems to me if we wanted we could build a kind of checkout mechanisium for editing a specific set of tiddlers perhaps marked with a tiddler-type field of serial-edit.

  • The users would all share the one node wiki, and have edit and save rights
  • However tools in the wiki would force serial editing of the same tiddler(s)

Of course more can be developed on top of tiddlywiki - just some ideas.

  • I still need to work through the details but I will let you know if I discover more than may help.

@Bob_Jansen I agree that MWS should be the path forward.

In the past, GitHub - OokTech/TW5-Bob: A plugin that makes tiddlywiki a multi-user wiki on node was the best answer, and as far as I know still the only true instant edit reflection in all browsers. When one user clicks edit, all other users get a lock icon to prevent issues. It’s sad that this has not been maintained, as I used it with my team extensively.

1 Like

@stobot , thanks for the pointer. However, if I understand it correctly, each user would need to install a copy of bob on their platform, which for a public facing wiki is not feasible. Also, the wiki would be mounted on a web server and I can not see how bob works in that environment. But maybe I don’t understand it at all :slight_smile:

Only one install, only works on a local network. Essentially you run it (there are some settings inside to setup the broadcast to LAN) and then it gives you a local IP address. Anyone on your local network can use that IP address and multi-edit.

The new Tiddlywiki app also have this feature i guess

My understanding is that Tiddlywiki App (like the standard Node Tiddlywiki), can be served on a LAN. In Tiddlywiki App there’s a menu for it, in regular Node it’s by setting host to 0.0.0.0. See link for details.

Uniquely BOB incorporates tiddler-level locking. If Tiddlywiki App has that, I haven’t found a way to enable it yet. In the absence of that, multiple people can be editing it at the same time and it’s just last-save wins.

Again, BOB is a few versions behind so I’m not necessarily recommending it right now, but it does show potential future capabilities that can be built.

Ya multi edit may not be there

@stobot thats what I suggested in my post that we may be able to develop it. I like bob but its no longer maintained.

Since the last save wins let that lock the tiddler from everyone else editing it, ie hide the edit button. the editor can then unlock when finished (Again being the last to save) but this could even occur on save and close of the tiddler.

  • Needs further investigation

I agree, there’s a way we could implement a tiddler lock just by modifying the edit button (I think that’s what you’re probably implying). The sync process for all other node-based wikis seems to be up to a 60 second delay from my experience though, so it just introduces more risk. There was something unique that BOB did to make that sync process instant, I wonder if that “piece” can be extracted and applied to other Node solutions? Anybody familiar with how that was accomplished?

@TW_Tones @Bob_Jansen Simply download https://tidgi.fun/ , it allows creating multiple nodejs wiki.

图片

It is an Electron wrapper of NodeJS wiki, so everything works with nodejs wiki works with TidGi desktop. It could also import existing HTML wiki. (i.g. empty edition.)

And it supports deeplink between nodejs wikis, see https://tidgi.fun/#TidGi%20Feature%20Handbook%2FUse%20deep%20links%20to%20open%20workspaces%20and%20tiddlers

TidGi disable http server by default to protect privacy, in case you don’t want people sniffer your personal wiki on LAN, and prevent data lost when wiki state changes. LAN http server can be enabled on workspace setting.

That is why I make most of TidGi’s default template feature as plugin and publish them on CPL. If BOB.exe did that too, we could simply install that plugin and make it works.

Reading the replies to my initial rant and thinking more about the problem, I am coming to realise that I am asking for TW to become a public-facing multi-user content management system. That may be beyond what TW can provide at the moment?

BOB and TIDGI are all well and good but if they require the user to install/configure software, then they are not a solution I can apply. Also, from what I read, they are much more complex than just plain old TW and thus have a higher maintenance cost (my client is a low tech knowledge organisation at least those I’ve dealt with).

I still favour plain old TW but have to come up with a feasible update solution.

For a TW I have installed at a site, updates are disabled on the http-served version by hiding the editing button (as per a solution on TW-TALK some time ago) and having a single editable vesion that is just loaded over the existing server copy when updates have been completed.

The info I am missing at present is the actual number of updates, say per month. I assume not too many as these artillery pieces are cumbersome and heavy.

I guess the competitor to TW is mediawiki/a html content management system like Wordpress, etc.

If this simple update facility works for this new TW, my remaining problem is converting a almost 600 pages of info in docx into TW. For that I am looking at extracting the content into JSON format and manually having to add item specific content like images, footnotes, endnotes, etc.

Thanks for all your thoughts though, you are helping me sort my way through the morass

bobj

With Bob or MWS running on a server, multiple users can access the same wiki via a url, they do not need something installed on their device, just open in the browser.

  • To host it on the internet you need a reverse proxy etc…

@jeremyruston has a solution but commercial for something similar, I am not sure about the multi-user multi-editor status of his solution.

I have built the tools for what I call serial editing, where everyone who accesses the wiki has read/write access, but only when they have the wiki checked out can they make changes. I have all the technological pieces but it gets complex and needs more robust testing. I would love to get a collaboration together to Finish this. This solution is for single file wikis but could work just as well on top of a node or MWS.

MWS Multi-wiki Server

  • This has the ability to grant access to parts of a subwiki or wikis for each user as you may wish
  • Like Node and Bob it too needs a server so outside a LAN needs more effort for security sakes.

For complete strangers to access a wiki, such as to complete a survey, you can provide ways to let them answer questions and create/update some tiddlers *Read only wiki, but editable tiddlers in browser with local storage), then they can hit a button to zip the tiddlers and attach this to an email to send their answer.

  • Smarter people than me, could use html and a unique filename to store their answer zip online. This would be a great mechanism if generalised.
  • The Wiki owner editor could then import the zip file submissions and create a tool to import non destructively and collate the results.