I need one function in a wiki platform that I haven't seen so far. When I write text, in its WYSIWYG editor, I need an ability to paste in an image (a screenshot that I just grabbed, let's say) and for it to automatically upload it and embed it into text. Does this support something like that?
It seems like they actually support it in Wiki.js however it requires you to first click "insert assets" and once that modal displays [0], you can actually paste into the page and it will be uploaded.
Not too different than JIRA really. But I feel like this feature would be improved if pasting into the editor itself yielded the same result.
"You can upload images from a tab in the media dialog, or by dragging and dropping a file into the editor, or by pasting an image from your clipboard. [...] The image will be inserted into the page when you are done."
I have been waiting for an online wiki with the usability of Apple Notes that I use locally on all my Apple devices. It works like a charm except that I cannot make it public.
This is why I often take notes rather than write blog posts on my website. If the wiki software was as easy drag and drop as Apple Notes, I’d just take notes and they turn into publicly available wikis!
I am yet to find that tool. I would happily pay for such a tool with one braking condition that it must be self-hostable. I will not write my content into something like Medium or Notion where I don’t own my content.
I've deployed this for the internal documentation inside a company I worked for (MediaWiki was a no-go even with a visual editor).
For each new feature, I was developing inside a clean new wiki, than I exported the changes once I was sure everything was okay. It is way more easy then to upgrade to the new XWiki version.
Since you can write arbitrary JS in extensions, no reason why that couldn't be implemented by a library.
Since I just got into MediaWiki and write my first extension (finally a dark-mode that works), I'll see if this can be implemented. Perhaps with https://www.mediawiki.org/wiki/API:Upload.
Interestingly Amazon just finished a multi-year effort to migrate off MediaWiki internally to comply with an infosec mandate that PHP is banned company wide.
I'm looking to launch an internal wiki and Wiki.js came out on top for my requirements:
- easy to use for technical and non-technical staff alike: multiple editing options
- third party authentication: really comprehensive offering
- quality search: comprehensive internal and third party search offering
- ease of maintenance: largely everything is built-in, so no module/dependency maintenance headaches
- user management: solid user/group management system
With internal tools you need things to stick, and fast. As much as I am fond of mediawiki, the editing experience is a barrier to usage for many. And the extension ecosystem, while rich and diverse, is just more of a liability than a single installation. A quality search is also really important to adoption, so having options there is great.
I'd been using Docsify on a small scale with authentication through GitLab to edit, GitLab CD to build and Cloudflare Access to secure the front end. It works really well, but the lack of user management and the editing experience mean that it's time to move on.
It would be great to hear if this is a case of the grass always being greener on the other side.
I'm not impressed. Wiki.js is supposedly "built with performance in mind", but its documentation wiki [1] is much slower than any DokuWiki site I could find [2]. It also requires JavaScript to be enabled in the web browser.
I find it really frustrating that every piece of software nowadays claims to be "blazing fast" or "built for performance", usually with no benchmarks to back it up. Makes it really hard to tell at a glance what the strengths of a project actually are. I honestly would be very grateful if a project up and said "we're not the fastest, but we trade performance for a simpler codebase and easier extensibility. If you need to do some-performance-intensive-task, try other-package instead".
I also don't like their theme choice, especially the "Table of Contents" is fixed and wasteful, and combined with navigation column they used 40% of the screen wide. I can't concentrate to the content because the other half is distracting.
docs.requarks.io, which is said to be using Wiki.js, straight up doesn't load without Javascript, and even with Javascript enabled it's a multi-page application that just feels slower browsing page to page than your average 10-year-old mediawiki install (probably also heavier on the backend).
I was excited for a moment when wiki.js.org rendered properly without Javascript but similarly disappointed when docs.requarks.io only showed a fairly typical white page.
Also noticed that it feels slow page to page, thinking that it might be an issue with my Firefox configuration I opened the page on a fresh profile and it's still slow, but if you open it in Chrome page to page becomes almost instant and is more comparable to MediaWiki. So maybe this particular performance issue on FF can be resolved but it does seem like a worse end user experience when compared to MediaWiki.
We needed a documentation solution at work. MY coworker had some experience with Wiki.js.
What sold me on it was that you can use markdown and it can keep itself synced with a git repo.
This gives us plan text files that are tracked in a repo. It uses the user as the author, so now I can "code review" edit's to our wiki.
The content of the wiki is easily cloned by cloning the git repo. It is markdown in folders so if wiki.js dies at some point I could write a pandoc script to turn it into web pages again, you do loose all of the cool UI features.
I used a Wiki for a long time. But I try to minimise maintenance ("foist it upon others"). I also try to resist the enthusiasm for Rube Goldberg machines and for installing bad tooling (such as PHP).
Now that git has become ubiquitous, I prefer git with a self-hosted git-daemon instance. git , grep , awk , and sqlite make a strong set of tools for knowledge curation.
Unnecessarily bashing PHP is soo 2005. Like javascript, it can be written poorly due to its loose roots. Also just like javascript, it is a very different language now.
That said, DocuWiki is pretty decent to get up and running quickly.
I wonder why it's AGPL and not dual-licensed or some different GPL. As it is right now it's dead in the water for any commercial usage unless you're manually installing the thing on a manually installed server somewhere (which you probably aren't).
With automation you'd build images based on their images but run via your own CI/CD with your own security scans and any additions you might need (like additional logging infrastructure). Doing that is not possible with AGPL.
At least for me, the fact that it is purely licensed under the AGPL and that the copyright is owned by multiple people makes me far more comfortable with using it. It's a guarantee that the project will remain open source so I don't have to worry about suddenly being in a situation where I have to migrate away because the company or person decided that they don't want to have this be free and open source software anymore.
I guess, to a certain extent, that's because I'm an individual, not a company, and one that tends to open source pretty much everything they write. This is the same licensing that I use for pretty much all my projects (AGPL with no CLA).
> With automation you'd build images based on their images but run via your own CI/CD with your own security scans and any additions you might need (like additional logging infrastructure). Doing that is not possible with AGPL.
> As it is right now it's dead in the water for any commercial usage
So what? If companies need a certain software, they can pay for it. I remember a time when FOSS was not about providing companies with free work, quite the opposite indeed.
I've been using Wiki.js for several months now on a production project (self hosted). It has worked nearly flawlessly for me so far. No complaints. Setup was a piece of cake too.
Just a minor nitpick. If there isn't an actual file called "wiki.js" that is self-contained, I would prefer it be called WikiJS instead of "Wiki.js" to avoid confusion. In general when I see ".js" I expect to see a single file I can import that does something useful to my code.
I'm assuming that's for every single download, including testing. I know that when I use a service for the first time, I do a few installs while getting used to the software and its configuration. I'd assume they'd have no other way to verify installs (assuming there is no telemetry).
Wikis are also useful for note-taking, I'm using Wiki.js to document a D&D campaign to have some canonical reference of what actually happened in past sessions.
Same here, it's been a great asset to have available to document stuff in my homebrew world and have it reference other stuff. Being able to link my wiki out to my players for their own use is very handy.
I keep a v2 instance running on my Windows laptop solely for taking notes and keeping need-it-eventually information organized.
It's just enough added structure and functionality to make the whole body of notes more useful, without having to learn a formal system or adopt someone else's idea of what my note hierarchy should look like.
Can we please not have SPA's eat wikis, too? Text-only content does not need... (checking...) 6.3 MB of JavaScript to display (checking...) 3.3 KB of text. Blank pages with JavaScript disabled or in non-mainstream browsers is a really terrible experience for content so plainly simple to display.
Wikis also don't need (or indeed, even permit) cumbersome Git and PR-based workflows just to get changes into the "wiki". Better for it to be a single-page app that actually implements a wiki, than to provide a service that doesn't actually support wikis but has no qualms about throwing the word around anyway.
I've used the 1.x release, and the Mongo requirement was always a bit of a pin. I think v2 fixes that, but I haven't yet upgraded. Anyone has feedback on v1 vs v2?
I've been using 2.x since Jan and have really liked it. I'm using it in docker with postgres iirc for a small team for infrastructure documentation. Very markdown friendly and gets the job done while looking nice.
Even better, you can run these in Docker as non-root. Security wise, while this wouldn't make your app itself more secure, it would insulate your host OS from getting infected. I just checked and they even have one-liner Docker commands that do just this:
Everyone should consider running a wiki locally just for yourself. It's like being able to organize your brain. I just got into it two days ago and basically spent the whole weekend dumping things into it in a way I can actually browse and revisit, like the short stories I'd written, spread out across Notes.app and random folders.
You don't need to run WAMP, MySQL, Apache, phpmyadmin or anything. Here are the steps for someone, like me, who hadn't checked in a while:
I tried DokuWiki at first (has flat file db which is cool). It's simpler, but I ended up going with MediaWiki which is more powerful, and aside from Wikipedia using it, I noticed most big wikis I use also use it (https://en.uesp.net/wiki/Main_Page). MediaWiki lets you choose Sqlite as an option, so I have one big wiki/ folder sitting in my Dropbox folder symlinked into my iCloud folder and local fs.
Really changing my life right now. The problem with most apps is that they just become append-only dumping grounds where your only organizational power is to, what, create yet another tag?
My advice is to just look for the text files scattered around your computer and note-taking apps and move them into wiki pages. As you make progress, you will notice natural categories/namespaces emerging.
I did start similar things over 10 years ago. Where I am at these days is just text files ( markdown ) nested into folder structures. I've found this the most sustainable for quite a few years and it's been super useful. Main thing is, do whatever, as long as you find it easy to sustain.
> I tried DokuWiki at first (has flat file db which is cool). It's simpler, but I ended up going with MediaWiki which is more powerful, and aside from Wikipedia using it, I noticed most big wikis I use also use it (https://en.uesp.net/wiki/Main_Page). MediaWiki lets you choose Sqlite as an option, so I have one big wiki/ folder sitting in my Dropbox folder symlinked into my iCloud folder and local fs.
or you can just use Zim which is a cross-platform desktop app which does not need any setup and simply save files as text files in markdown : https://zim-wiki.org
I'm getting back into the Zettelkasten note-taking technique which is like a tech-agnostic wiki system (it was originally implemented using physical cards). I originally tried a personal wiki but it was just more tech overhead than I cared to deal with. Plain markdown files with zettelkasten are doing it for me now. Zettlr adds some nice features like adding an easy ability to tag files (just hashtags in the markdown) and search files by tags. It all feels more freeform/lightweight than a wiki server.
I started writing a master thesis in a MediaWiki a long time ago. Did not work for me, maybe lack of keeping a proper index. It was a data graveyard. On the other hand, so is my whole home folder...
I created a mashup of Zettelkasten + bullet journaling + a linking system based on tagging and IDs that models the fact that knowledge is both hierarchical and associative - i.e. fractal.
My co-founder and I have been building a hosted version of this[1] for the last two years, because we recognized that while self-hosted wikis work great for techie people, there are a lot of other people who that label doesn't fit.
So we've been working to create a collaborative knowledge-base platform built around some key concepts:
1. Built around cards rather than documents, which allows for a lot of interesting and flexible features. Such as...
2. Granular sharing – on Supernotes, you can share an entire collection of cards, or you can share one card at a time. We also have recently introduced[2] a "friends" features that allows you to quickly drag-and-drop cards onto your friends to share with them.
3. Multi-parent nesting – there is no folder-style filesystem on Supernotes, we allow you to nest cards inside of each other. On top of this, we allow for this nesting to be multi-parent, so different users can fit the same cards into their own unique structure (effectively a collaborative / personalized version of symbolic links).
4. Public vs. private tags – cards can be tagged with public tags that everyone sees, but can also be tagged privately with only tags that you can see. This same idea is reflected across the platform, where we want the underlying content to be the same for everyone but want to allow users to personalize the metadata/structure to suit their own workflow.
5. Focus on speed – we have spent a lot of time making Supernotes speedy quick, and try to make it faster every time we release a new feature.
Anyway that is the rough idea. The goal of Supernotes is to be a sort of data-layer where you can keep all these compartmentalized pieces of content (as cards) and then mix-and-match at will to create very simple or very complex stores of knowledge. We also want you to be able to embed these pieces of content elsewhere (say in a Notion document or on your blog) with as little effort as possible (not quite there yet, but will be soon).
I've been using Obsidian for note taking recently, and as much as I really enjoy it - having hypermedia would be quite useful too. I can paste images in Obsidian, but it tends to put the pasted image in the root folder, and I can't display it inline with my notes.
EDIT: VisualEditor, the de facto standard for pasting things like screenshots into your articles seems to be a pain to install. Got my local env up and running though.. Will report back on success with this extension.
I use Zim for this, backed by Dropbox. It's just text files, and Zim is just an editor, not a server or anything like that.
If I ever tire of keeping a personal wiki for whatever reason, all of the content I've built up in it will remain organized as files within directories.
I almost went with MediaWiki, but ended up with DokuWiki. The fresh install of MediaWiki is 154 MB (!) and it's not exactly lightweight. DokuWiki is 10.9 MB and all content is saved in plain text files. Very attractive.
However, backlinks are not possible without hacks. A wiki without backlinks is kind of lame and I could very well use my good old plain text files.
Also wanted to get into creating a local 'wiki' or knowledge base. Sadly I didn't hit the sweet spot till now. My requirements are:
- future proof (at least not only a one man project)
- Fast search over all informations
- Fast creation of quick notes (inbox)
- Mobile iOS client
Currently I am stuck with Notion, which has a great 'database' concept. Which is fun to use. Sadly it's too slow. If I want to take a quick note on the go "Google for M6x40 Screws" I need 10-20 seconds with Notion.
Which "wiki folder" do you refer to? Are you talking about Wiki.JS, or some other wiki engine? I see you mention MediaWiki, are your simple steps for it?
If you're going to run it locally why not just use Apple Notes app?
If using a web app, it would be better to run it on a $5 server, so if you want to type in something while you're outside with just your phone, you can do that also.
I started using Wiki.js over a year ago to maintain documentation related to system admin duties.
We run this in a docker container with SQLite database and
backup the database daily to another server.
The private and public pages feature fits perfectly to our use case. We show system information, how-to guides and rules on the public pages and manage sysadmin documentation with restricted access.
DokuWiki used to be very much better for my use cases: easier to hack on/make plugins for and more built in functionality and less dependencies on top if that since it store the pages as flat files instead of using a DB.
Kontxt (https://kontxt.io) could be a perfect inline communication and engagement layer to enhance wikis and docs with inline highlights, comments, polls, @mentions, page navigation, shareable deep links, and permission-based sharing.
Keyframe|5 years ago
therein|5 years ago
It seems like they actually support it in Wiki.js however it requires you to first click "insert assets" and once that modal displays [0], you can actually paste into the page and it will be uploaded.
Not too different than JIRA really. But I feel like this feature would be improved if pasting into the editor itself yielded the same result.
[0] https://i.imgur.com/o04m6on.png
buovjaga|5 years ago
"You can upload images from a tab in the media dialog, or by dragging and dropping a file into the editor, or by pasting an image from your clipboard. [...] The image will be inserted into the page when you are done."
reacharavindh|5 years ago
I have been waiting for an online wiki with the usability of Apple Notes that I use locally on all my Apple devices. It works like a charm except that I cannot make it public.
This is why I often take notes rather than write blog posts on my website. If the wiki software was as easy drag and drop as Apple Notes, I’d just take notes and they turn into publicly available wikis!
I am yet to find that tool. I would happily pay for such a tool with one braking condition that it must be self-hostable. I will not write my content into something like Medium or Notion where I don’t own my content.
winton|5 years ago
dalf|5 years ago
* CKEditor: https://extensions.xwiki.org/xwiki/bin/view/Extension/CKEdit...
* Syntax: https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide...
Actually any wiki pages can define a Class and how to display this class and / or instances of a Class:
* https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/...
* https://extensions.xwiki.org/xwiki/bin/view/Extension/App%20...
The Script Macro is useful to make some dashboards ( https://extensions.xwiki.org/xwiki/bin/view/Extension/Script... )
I've deployed this for the internal documentation inside a company I worked for (MediaWiki was a no-go even with a visual editor).
For each new feature, I was developing inside a clean new wiki, than I exported the changes once I was sure everything was okay. It is way more easy then to upgrade to the new XWiki version.
tommoor|5 years ago
hombre_fatal|5 years ago
Since I just got into MediaWiki and write my first extension (finally a dark-mode that works), I'll see if this can be implemented. Perhaps with https://www.mediawiki.org/wiki/API:Upload.
Dennip|5 years ago
r0rshrk|5 years ago
schoolornot|5 years ago
Mediawiki has some UX and RBAC challenges that makes it difficult to scale to large organizations.
oneplane|5 years ago
Google has some motivations written down from their lawyer department: https://opensource.google/docs/using/agpl-policy/
It boils down to 'not worth the risk, do not use'.
ta20200710|5 years ago
Interestingly Amazon just finished a multi-year effort to migrate off MediaWiki internally to comply with an infosec mandate that PHP is banned company wide.
omegote|5 years ago
tweetle_beetle|5 years ago
- easy to use for technical and non-technical staff alike: multiple editing options
- third party authentication: really comprehensive offering
- quality search: comprehensive internal and third party search offering
- ease of maintenance: largely everything is built-in, so no module/dependency maintenance headaches
- user management: solid user/group management system
With internal tools you need things to stick, and fast. As much as I am fond of mediawiki, the editing experience is a barrier to usage for many. And the extension ecosystem, while rich and diverse, is just more of a liability than a single installation. A quality search is also really important to adoption, so having options there is great.
I'd been using Docsify on a small scale with authentication through GitLab to edit, GitLab CD to build and Cloudflare Access to secure the front end. It works really well, but the lack of user management and the editing experience mean that it's time to move on.
It would be great to hear if this is a case of the grass always being greener on the other side.
mard|5 years ago
[1]: https://docs.requarks.io/
[2]: https://www.dokuwiki.org/
Rotten194|5 years ago
a012|5 years ago
Hamcha|5 years ago
Who exactly is asking for slower software?
midasz|5 years ago
I'm sorry but it's right there in the name
newsbinator|5 years ago
Aengeuad|5 years ago
Also noticed that it feels slow page to page, thinking that it might be an issue with my Firefox configuration I opened the page on a fresh profile and it's still slow, but if you open it in Chrome page to page becomes almost instant and is more comparable to MediaWiki. So maybe this particular performance issue on FF can be resolved but it does seem like a worse end user experience when compared to MediaWiki.
mainframed|5 years ago
But yes, not loading without Javascript is a showstopper.
areille|5 years ago
Is Node.js that blazing-fast ?
aerojoe23|5 years ago
This gives us plan text files that are tracked in a repo. It uses the user as the author, so now I can "code review" edit's to our wiki.
The content of the wiki is easily cloned by cloning the git repo. It is markdown in folders so if wiki.js dies at some point I could write a pandoc script to turn it into web pages again, you do loose all of the cool UI features.
heresie-dabord|5 years ago
Now that git has become ubiquitous, I prefer git with a self-hosted git-daemon instance. git , grep , awk , and sqlite make a strong set of tools for knowledge curation.
edit: minor grammar fix
ArtDev|5 years ago
That said, DocuWiki is pretty decent to get up and running quickly.
oneplane|5 years ago
With automation you'd build images based on their images but run via your own CI/CD with your own security scans and any additions you might need (like additional logging infrastructure). Doing that is not possible with AGPL.
gary-kim|5 years ago
I guess, to a certain extent, that's because I'm an individual, not a company, and one that tends to open source pretty much everything they write. This is the same licensing that I use for pretty much all my projects (AGPL with no CLA).
andrewshadura|5 years ago
None of that is impossible with AGPL.
normalnorm|5 years ago
So what? If companies need a certain software, they can pay for it. I remember a time when FOSS was not about providing companies with free work, quite the opposite indeed.
unknown|5 years ago
[deleted]
w-ll|5 years ago
bauerd|5 years ago
unknown|5 years ago
[deleted]
Nuzzerino|5 years ago
dheera|5 years ago
techaddict009|5 years ago
I mean thats too large number. Is this of all open source software or I am misunderstanding something else?
jjice|5 years ago
yreg|5 years ago
zcdziura|5 years ago
pspeter3|5 years ago
gwbrooks|5 years ago
It's just enough added structure and functionality to make the whole body of notes more useful, without having to learn a formal system or adopt someone else's idea of what my note hierarchy should look like.
ddevault|5 years ago
cxr|5 years ago
lukaszkups|5 years ago
captn3m0|5 years ago
progval|5 years ago
amq|5 years ago
Vaslo|5 years ago
dvno42|5 years ago
amelius|5 years ago
acoard|5 years ago
xcambar|5 years ago
And choose SQLite.
Reubend|5 years ago
unknown|5 years ago
[deleted]
bobbydreamer|5 years ago
cptskippy|5 years ago
Marioheld|5 years ago
favadi|5 years ago
kinganurag|5 years ago
amelius|5 years ago
mbrd|5 years ago
hombre_fatal|5 years ago
Everyone should consider running a wiki locally just for yourself. It's like being able to organize your brain. I just got into it two days ago and basically spent the whole weekend dumping things into it in a way I can actually browse and revisit, like the short stories I'd written, spread out across Notes.app and random folders.
You don't need to run WAMP, MySQL, Apache, phpmyadmin or anything. Here are the steps for someone, like me, who hadn't checked in a while:
0. `$ brew install php` (or equiv for your OS)
1. Download the wiki folder and `cd` into it
2. `$ php -S localhost:3000`
3. Visit http://localhost:3000/install.php in your browser
I tried DokuWiki at first (has flat file db which is cool). It's simpler, but I ended up going with MediaWiki which is more powerful, and aside from Wikipedia using it, I noticed most big wikis I use also use it (https://en.uesp.net/wiki/Main_Page). MediaWiki lets you choose Sqlite as an option, so I have one big wiki/ folder sitting in my Dropbox folder symlinked into my iCloud folder and local fs.
Really changing my life right now. The problem with most apps is that they just become append-only dumping grounds where your only organizational power is to, what, create yet another tag?
My advice is to just look for the text files scattered around your computer and note-taking apps and move them into wiki pages. As you make progress, you will notice natural categories/namespaces emerging.
I just wish I started 10 years ago.
keithnz|5 years ago
jcelerier|5 years ago
or you can just use Zim which is a cross-platform desktop app which does not need any setup and simply save files as text files in markdown : https://zim-wiki.org
Normal_gaussian|5 years ago
This is the rub. I started a tiddlywiki last year, and stuck with it for several months, but now it has fallen to the wayside as too cumbersome.
indigochill|5 years ago
wukerplank|5 years ago
2rF7OoC47|5 years ago
I created a mashup of Zettelkasten + bullet journaling + a linking system based on tagging and IDs that models the fact that knowledge is both hierarchical and associative - i.e. fractal.
fastball|5 years ago
My co-founder and I have been building a hosted version of this[1] for the last two years, because we recognized that while self-hosted wikis work great for techie people, there are a lot of other people who that label doesn't fit.
So we've been working to create a collaborative knowledge-base platform built around some key concepts:
1. Built around cards rather than documents, which allows for a lot of interesting and flexible features. Such as...
2. Granular sharing – on Supernotes, you can share an entire collection of cards, or you can share one card at a time. We also have recently introduced[2] a "friends" features that allows you to quickly drag-and-drop cards onto your friends to share with them.
3. Multi-parent nesting – there is no folder-style filesystem on Supernotes, we allow you to nest cards inside of each other. On top of this, we allow for this nesting to be multi-parent, so different users can fit the same cards into their own unique structure (effectively a collaborative / personalized version of symbolic links).
4. Public vs. private tags – cards can be tagged with public tags that everyone sees, but can also be tagged privately with only tags that you can see. This same idea is reflected across the platform, where we want the underlying content to be the same for everyone but want to allow users to personalize the metadata/structure to suit their own workflow.
5. Focus on speed – we have spent a lot of time making Supernotes speedy quick, and try to make it faster every time we release a new feature.
Anyway that is the rough idea. The goal of Supernotes is to be a sort of data-layer where you can keep all these compartmentalized pieces of content (as cards) and then mix-and-match at will to create very simple or very complex stores of knowledge. We also want you to be able to embed these pieces of content elsewhere (say in a Notion document or on your blog) with as little effort as possible (not quite there yet, but will be soon).
[1] https://supernotes.app/
[2] https://supernotes.app/changelog
Mandatum|5 years ago
EDIT: VisualEditor, the de facto standard for pasting things like screenshots into your articles seems to be a pain to install. Got my local env up and running though.. Will report back on success with this extension.
unknown|5 years ago
[deleted]
bovermyer|5 years ago
If I ever tire of keeping a personal wiki for whatever reason, all of the content I've built up in it will remain organized as files within directories.
unicornporn|5 years ago
However, backlinks are not possible without hacks. A wiki without backlinks is kind of lame and I could very well use my good old plain text files.
Have you run in to trouble when updating MediaWiki, or is it smooth sailing? SQLite is not mentioned here: https://www.mediawiki.org/wiki/Download
VexorLoophole|5 years ago
- future proof (at least not only a one man project) - Fast search over all informations - Fast creation of quick notes (inbox) - Mobile iOS client
Currently I am stuck with Notion, which has a great 'database' concept. Which is fun to use. Sadly it's too slow. If I want to take a quick note on the go "Google for M6x40 Screws" I need 10-20 seconds with Notion.
I don't even mind paying for such service...
davidcollantes|5 years ago
emiliovesprini|5 years ago
unknown|5 years ago
[deleted]
ekianjo|5 years ago
mekster|5 years ago
If using a web app, it would be better to run it on a $5 server, so if you want to type in something while you're outside with just your phone, you can do that also.
jadia|5 years ago
We run this in a docker container with SQLite database and backup the database daily to another server.
The private and public pages feature fits perfectly to our use case. We show system information, how-to guides and rules on the public pages and manage sysadmin documentation with restricted access.
load|5 years ago
eitland|5 years ago
wutwutwutwut|5 years ago
Eldt|5 years ago
[deleted]
kontxt|5 years ago
emiliovesprini|5 years ago
Oh wait yeah.