Wiki.js 2.0 [+]
Jun 12 2023
I've been using Wiki.js to organize my Basic D&D campaign. So why use this instead of RapidWeaver?
Multi-user: I can have multiple people editing the site. For examples my players could update their characters or have online notes. With multi-user support that also means some sort of permissions which means I can keep pages for my eyes only and have game master notes.
Editing Speed: If I show a page to my players and it has wrong information I can edit the page, save and it publishes at the same time, the can reload page to see changes. With RapidWeaver I could edit the change, publish the changes, sync then to my web server machine then players can reload page. Not much slower I guess though with a wiki I could make those changes anywhere whereas RapidWeaver I need my laptop.
Search: My RapidWeaver site is simple and static with no search capability (though could be added via Google). Most wikis have search built-in and Wiki.js has both a simple one (just titles) or you can enable a db-based one which does keyword searches.
Versioning: If you make a mistake you can rollback to a previous version. Version comparison is also there by viewing page history.
Diagrams: Wiki.js supports diagrams.net. You can insert or edit a diagram, it opens a page in diagrams.net where yo can edit, then save it back to Wiki.js as some sort of ascii-non-readable format but one which Wiki.js can render into a graphic. This is actually kind of nice for a table-top RPG so I can draw a map of what players can see then add to it as they move around. Mind you it's a diagram so vector graphics: not as precise as a painting program but easier to then edit elements.
One thing I haven't seen from wikis do is automatically creating/updating a feed rss file, which RapidWeaver does for Blog page type. I'd guess WikiMedia has an extension for this and as far as I can tell Wiki.js does not support this.
Why Wiki.js over other Wikis?
I looked at a few other wiki platforms. MediaWiki (which runs Wikipedia) and derivatives are fairly big and complicated to install and setup. I wanted a wiki simple to install and setup and Wiki.js is one. BookStack is another though its library/books/chapters metaphor seems a little limited.
Wiki.js is written in JavaScript and runs on Node.js, which is a JavaScript runtime engine, and uses Postgres DB so it's very portable and even though it's not really macOS specific it runs fine. Installation is fairly simple, for a server service that is, and should be doable for anyone with lowish level of command line experience.
Features
Wiki.js docs site at https://docs.requarks.io is actually a pretty good example of site. It has a blue and white theme (you can change themes though there are few available -- I guess you can install others and there are also lots of extensions but I haven't added any). There is navigation sidebar which is setup in admin setup (admin setup includes a bunch of stuff that I feel is more for a wiki site manager and hopefully that will be split up in a future version). Main content area might show a page contents side bar if the window is big enough (and if the window is smaller the navigation side bar is hidden, adaptive layout is nice for handling mobile phones to large desktop monitors).
If you have edit access you can: Edit, History, View Source, Convert, Duplicate, Move/Rename, Delete.
When you create a page you have to specify the editor: Markdown, Visual Editor, Raw HTML. Markdown is a text-based format where some ascii characters indicate HTML tags, e.g. start a line with # means this is a Header 1 line. Visual Editor is a WYSIWYG word processor editor. Raw HTML is a page that will be served directly. There is also AsciiDoc which is kind of like Markdown (I prefer Markdown as that is more of a widely used standard).
Whenever you save a page Wiki.js converts it to an HTML page so that serving it users is fast. Convert allows you to change the editor of a page and it's fairly good converting from Markdown to Visual Editor, back again mostly good though Visual Editor has more richness especially with tables so you may lose some of that. Markdown has the diagrams.net support so you lose that with Visual Editor. In general I like Markdown unless I need a fancy table.
All pages are kept in a directory structure and the navigation sidebar allows you to navigate the folder structure. When you link using the command you can choose the destination page. You can also tag pages which I guess then allows you to search pages by tag.
As I mentioned above search is just page titles though you can go to the admin setup and for postgres enable advanced search (I think it install a package into postgres to do indexing) in which case search includes page contents. The search results show page title, page summary (which you typed in when you created the page), and page location -- I'd like a bit of the page contents context around the found search term. If you search for multiple words it returns pages that contains all the words. You can't search for strings though, just words.
Users and permissions are done in the admin area. You can assign users to groups then assign permissions to those groups. You can also setup page rules for each group which is a rules-based engine. I find it unintuitive and would rather be able to assign permissions from editing the page though since you can't edit a folder structure that would be a bit of a problem. For secret pages what I did is give the non-admin groups a rule that if a tag matches "secret" then read/write permissions are denied which seems clumsy but at least works.
You can upload images and really any file via Edit Page > Insert Assets command (a bit clumsy again but it works). Assets are kept in the same folder structure as wiki pages (the folder navigator doesn't show assets) and the files follow the same naming conventions. Like any web server assets have to be directly getable from a web browser -- I use assets to store podcast feed.xml files which I can then serve (which is something I can do in RapidWeaver too though the URLs would all have /resources/ in them since the assets folder is fixed).
Summary
Wiki.js is easy to install and has a clean, adaptive default UI. Creating and editing pages is easy. User administration, navigation bar setup and permissions setup is clumsy (Wiki.js is more of a small workgroup solution than one for dozens or more editors). It's a very portable solution. It's open source and the source code is on github. Overall I'm pretty happy with it.
Multi-user: I can have multiple people editing the site. For examples my players could update their characters or have online notes. With multi-user support that also means some sort of permissions which means I can keep pages for my eyes only and have game master notes.
Editing Speed: If I show a page to my players and it has wrong information I can edit the page, save and it publishes at the same time, the can reload page to see changes. With RapidWeaver I could edit the change, publish the changes, sync then to my web server machine then players can reload page. Not much slower I guess though with a wiki I could make those changes anywhere whereas RapidWeaver I need my laptop.
Search: My RapidWeaver site is simple and static with no search capability (though could be added via Google). Most wikis have search built-in and Wiki.js has both a simple one (just titles) or you can enable a db-based one which does keyword searches.
Versioning: If you make a mistake you can rollback to a previous version. Version comparison is also there by viewing page history.
Diagrams: Wiki.js supports diagrams.net. You can insert or edit a diagram, it opens a page in diagrams.net where yo can edit, then save it back to Wiki.js as some sort of ascii-non-readable format but one which Wiki.js can render into a graphic. This is actually kind of nice for a table-top RPG so I can draw a map of what players can see then add to it as they move around. Mind you it's a diagram so vector graphics: not as precise as a painting program but easier to then edit elements.
One thing I haven't seen from wikis do is automatically creating/updating a feed rss file, which RapidWeaver does for Blog page type. I'd guess WikiMedia has an extension for this and as far as I can tell Wiki.js does not support this.
Why Wiki.js over other Wikis?
I looked at a few other wiki platforms. MediaWiki (which runs Wikipedia) and derivatives are fairly big and complicated to install and setup. I wanted a wiki simple to install and setup and Wiki.js is one. BookStack is another though its library/books/chapters metaphor seems a little limited.
Wiki.js is written in JavaScript and runs on Node.js, which is a JavaScript runtime engine, and uses Postgres DB so it's very portable and even though it's not really macOS specific it runs fine. Installation is fairly simple, for a server service that is, and should be doable for anyone with lowish level of command line experience.
Features
Wiki.js docs site at https://docs.requarks.io is actually a pretty good example of site. It has a blue and white theme (you can change themes though there are few available -- I guess you can install others and there are also lots of extensions but I haven't added any). There is navigation sidebar which is setup in admin setup (admin setup includes a bunch of stuff that I feel is more for a wiki site manager and hopefully that will be split up in a future version). Main content area might show a page contents side bar if the window is big enough (and if the window is smaller the navigation side bar is hidden, adaptive layout is nice for handling mobile phones to large desktop monitors).
If you have edit access you can: Edit, History, View Source, Convert, Duplicate, Move/Rename, Delete.
When you create a page you have to specify the editor: Markdown, Visual Editor, Raw HTML. Markdown is a text-based format where some ascii characters indicate HTML tags, e.g. start a line with # means this is a Header 1 line. Visual Editor is a WYSIWYG word processor editor. Raw HTML is a page that will be served directly. There is also AsciiDoc which is kind of like Markdown (I prefer Markdown as that is more of a widely used standard).
Whenever you save a page Wiki.js converts it to an HTML page so that serving it users is fast. Convert allows you to change the editor of a page and it's fairly good converting from Markdown to Visual Editor, back again mostly good though Visual Editor has more richness especially with tables so you may lose some of that. Markdown has the diagrams.net support so you lose that with Visual Editor. In general I like Markdown unless I need a fancy table.
All pages are kept in a directory structure and the navigation sidebar allows you to navigate the folder structure. When you link using the command you can choose the destination page. You can also tag pages which I guess then allows you to search pages by tag.
As I mentioned above search is just page titles though you can go to the admin setup and for postgres enable advanced search (I think it install a package into postgres to do indexing) in which case search includes page contents. The search results show page title, page summary (which you typed in when you created the page), and page location -- I'd like a bit of the page contents context around the found search term. If you search for multiple words it returns pages that contains all the words. You can't search for strings though, just words.
Users and permissions are done in the admin area. You can assign users to groups then assign permissions to those groups. You can also setup page rules for each group which is a rules-based engine. I find it unintuitive and would rather be able to assign permissions from editing the page though since you can't edit a folder structure that would be a bit of a problem. For secret pages what I did is give the non-admin groups a rule that if a tag matches "secret" then read/write permissions are denied which seems clumsy but at least works.
You can upload images and really any file via Edit Page > Insert Assets command (a bit clumsy again but it works). Assets are kept in the same folder structure as wiki pages (the folder navigator doesn't show assets) and the files follow the same naming conventions. Like any web server assets have to be directly getable from a web browser -- I use assets to store podcast feed.xml files which I can then serve (which is something I can do in RapidWeaver too though the URLs would all have /resources/ in them since the assets folder is fixed).
Summary
Wiki.js is easy to install and has a clean, adaptive default UI. Creating and editing pages is easy. User administration, navigation bar setup and permissions setup is clumsy (Wiki.js is more of a small workgroup solution than one for dozens or more editors). It's a very portable solution. It's open source and the source code is on github. Overall I'm pretty happy with it.