- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
Today I was looking at some ways to get wikis for games that are very in depth offline for personal use. Wiki.js was one of the more prominent results so I looked into it. I’m no HTML pro, but I do know a few things, enough to make it look decent enough for my own curiosity and usage. I just wanted to share with others who might be interested in something similar!
I absolutely love the layout and how easy it is to move stuff over. Once I made the default theme dark, it was game on. I have spent the last 3 hours moving bits and pieces from the wikis I was interested in over to it. Give it a try!
I’m hosting it through the Apps feature in TrueNAS Scale. Not exposed to the internet. On TrueNAS, I set it up ACL (permissions) with a preset one that I made for quickly giving myself access to anything for my file browser.
THANK YOU to all the devs and anyone who has supported this project. Excellent piece of software!
Yeah, I noticed that when you choose a format, it’s that format or delete and start over with the new format. That would be a neat feature at least, but I can see the troubles of properly reformatting the file into the new format you want. Luckily, I’m just using it for giggles and a little bit of learning! Haha!
It isn’t! There’s a convert button in the little edit quick menu in the bottom right
Keep on using it, it’s pretty but, as a developer, I always prefer solutions like GitLab where the markdown is stored in a git repository.
I’ve never developed or anything like that. Just fiddled around with HTML, CSS, and markdown before. Can you explain the upsides to the git structure? I’ve never used it, so I’m interested to know from someone who has used it!
Git is what’s known as “Version Control Software” which basically means that it keeps track of the changes you make.
It’s primarily used for software development, and where it shines is when multiple people are collaborating on a project which will receive many changes. You can create a “branch” of the project with the changes you want to “commit” and then after they’re reviewed in a “pull request” you can “merge” them back inyo the main branch. If at any point in the process you discover that the changes cause issues, a history allows you to “revert” those changes back to what you had previously.
As you can probably see, there’s a fair bit of terminology in git. It’s a powerful tool that has a learning curve in order to use it.
While git is primarily used in software development, it doesn’t have to be. In fact, you could use it for any collection of files that receive changes. It’s not uncommon to see it used for technical writing , wikis, or large collaborative documents. I recall seeing a compelling argument that it could be used for drafting legislation, although I’m not aware of any government which uses it for that purpose.
Some people argue about whether or not you should use git with non-text files because the changes are much larger, but you don’t have to rigidly follow dogma.
I knew a guy who liked to use git for his RPG campaign notes. The main branch held his setting info, and when he’d run a game he’d create a new branch. If he was pleased with the game and wanted to enshrine it in canon, he’d merge it into main. Otherwise, he could leave the branch alone, but he’d still always be able to go back and look at the adventure with the details of the setting as it was at that time. I thought it was overkill, but he had fun.
You can sync wiki.js with git solutions. I use that option to allow my colleagues to make changes online or through their favorite text editor. Bulk editors are way easier in a text editor, then commit and it will sync with wiki.js