For the past few months I’ve been using Tiddlywiki as a memory dump but been having some issues. First started with the dreaded XMLHttpRequest error:
Error retrieving skinny tiddler list: XMLHttpRequest error code: 404
Which the available documentation offers no help with and the developers just shrug at. Then it just ate a fucken shotgun shell deep down its throat:
We en’t here for that shit so on we went looking for an alternative that treats markdown as a first-class white citizen in apartheid america. Found wiki.js, which seems to have that, and here we are.
What follows is a guide written after a week of bashing our head against multiple desks because devlopers are morons who don’t know how to write documentation, if they even bother writing any. What is available for wiki.js is fucken laughable or only applies to the 1.x series. Real developers are extinct, by the way.
This assumes DNS is already routing properly, outgoing mail works, and you’ve already dealt with your firewall. This setup gets you a wiki.js installation with nginx as a reverse proxy running security.
All commands are executed as root.
Install what you need
# aptitude install nginx-extras postgresql postgresql-contrib pgcli nodejs certbot python-3-certbot-nginx
Download and extract wiki.js (assuming we’re at
/var/www) like the documentation says:
# wget https://github.com/Requarks/wiki/releases/download/2.3.81/wiki-js.tar.gz # mkdir wiki # tar xzf wiki-js.tar.gz -C ./wiki # cd ./wiki # mv config.sample.yml config.yml
Edit your configuration file for nginx so it passes everything to the wiki cleanly through nginx. The original configuration was generated by nginxconfig.io and incorporates stuff from the official documentation
As of right now (2020-05-16_14-28) they are valid and working server blocks
Using Let’s Encrypt SSL certificates:
Go through the wizard and it will automatically fix the SSL entries on your server blocks. You could also do this if you know what you’re doing and don’t want
certbot to mess around with your files:
# certbot certonly --webroot -d wiki.domain.invalid --email email@example.com -w /var/www/_letsencrypt -n --agree-to-tos
Test and reload your configuration:
# nginx -t # service nginx reload
Watch out for any errors, as usual. At this point Nginx will be serving files but as wiki.js isn’t setup yet you’ll get HTTP 502 errors if you try to visit the site on a browser. This configuration plays well with other sites being hosted on the same server.
Secure your Postgres installation:
# sudo su postgres $ passwd
Then setup your database.
pgcli has smart completions turned on by default and looks pretty.
$ pgcli > create DATABASE wikijs; > create USER wikijs_user with ENCRYPTED PASSWORD 'Strong password'; > grant ALL PRIVILEGES on DATABASE wikijs to wikijs_user; > \c wikijs > CREATE EXTENSION pg_trgm; > exit $ exit
config.yml and make the appropriate changes:
Portshould match what was configured in the nginx https server block (3000)
dbsection, enter your database credentials
- Do not enable SSL unless you are not to run this behind a proxy. This might work on a developer workstation but on the public internet you’re asking to get it up the ass, no lube.
Once this is done, start the application and watch for any errors
# node server
At this point you can visit your site and go through the installation wizard.
There are a bunch of things the official wiki.js documentation only mentions offhandedly, or that you’ll only find out if you go rooting around in the issues tracker.
You can name it anything you want but if you make the path anything other than
/home wiki.js will freak out on you and send you on a loop.
By default wiki.js will keep all its shit on the DB, which is a fucken stupid bad decision. We like making good decisions so we need to tell wiki.js to keep its shit in the filesystem:
- Go to Administration > Storage
- Enter the desired absolute path for your stuff, like
- Enable the target
- Apply the changes
We’re unsure if this means wiki.js will actually use file storage to begin with, but at least you’ll be able to create quick backups of all your stuff. You have backups and you test them, right?
The default search is slow AF, so we’re going to use something better
- Go to Administration > Search Engine
- Select Database – PostgreSQL
- Apply the changes
This thing has potential but it’s got a long way to go before it can look up to MediaWiki. If you find issues with this holler at me on the twitters.