Wiki.js

I am trying to build a generic RAG and a lot of companies already use this awesome project for their documentation , so instead of writing something which queries wikijs and writes to document db. i am thinking of implementing vector db support in wikijs itself to make it readily available for rag systems.

Can you add support for MinIO( https://min.io ), a self-hosted storage backend service with S3 Compatible.

Currently while using git as a storage backend there is no way to clone LFS objects. But once we install git-lfs in the container it seems to be working fine. Is it intentional to not add git-lfs binary in the docker image? If not, we can create a patch for the same :)

Currently the default language is saved within the Git repository root instead of an appropriate locale dir. Unfortunately, that creates a bug where Git repository link to edit by volunteers is pointing to a non-existent file, which would be in the locale dir, but resides in the root dir instead. Simple solution would be to save all locales to their respective directory, regardless of whether it is a default locale or not. This solution also makes sense from the semantic point of view, as each language has a distinctive directory. If we were to change the default language from Czech to English in the future for example, then what would happen to the files? The Czech locale would be transfered to "cs" directory, and English locale would suddenly swoop in to the root? That doesn't make sense. Because of this inconsistency, our wiki, which default locale is Czech (cs), GitHub link for external edits points to an invalid resource, and as such people might be confused. This suggestion was posted as per request in GitHub discussion for a related bug report: https://github.com/requarks/wiki/discussions/7121

Many times, images uploaded by editors will only be used in one page. So can a more convenient way of managing assets be added? For example, if the editor is editing /aaa/bbb/ccc, he can upload the image img.jpg directly in the page, and the image will be automatically stored in a path like /i/aaa/bbb/ccc/img.jpg. Within this page, the editor can use the image directly by url "img.jpg", and the html renderer will automatically complete the image url to "/i/aaa/bbb/ccc/img.jpg". When the editor deletes all img.jpg from the page and clicks Render, the renderer checks if the files under /i/aaa/bbb/ccc/ are used in the page. If not used, the file is deleted. Administrators can see the size of the assets owned by each page. This helps simplify the rules of image uploading and can remove images that are no longer used in a timely manner. Developers can set users to only allow access to assets on that page to enhance asset security.

For security reasons ssh port for my gitea instance is not 22, I customized it and there is no way (that I can find) to specify a custom port.

Uploading two files with same same seems to just overwrite the old one w/o any warning or info. Either just automatic rename in this case or don't present this filesystem at all (but rather let wikiJS internally handle storage - i think most of us just want to dump attachments and do not care about the actual storage situation). Or at least check if a file w/ that name already exists bf uploading and warn the user.

Instead that the user needs to decide where to store files which are then linked, would be userfriendly , that files could just be attached , so user creates a new document and attach the files he would like to havein his document just say attach and choose then the file he would like to attach, and upload then the file into the DB. So that when the main documente is deleted all attchments in this document are also deleted. Like you have a word file, and within the word file you have maybe some pdf.At the moment we create lost files, when the orginal file is deleted and the person forgot to delete all the linked files, they will stay forever.

This would be very useful for organizations on Office365.

Would it be possible to integrate with Google's API so that its storage mechanisms could be used (ie: Google Drive). There are a couple of projects out there that do this. This might grant some portability where users can run the front-end anywhere, but also include some redundancy in storage. Another service that is doing this now, also using Google Firebase, is "You Need a Wiki" https://youneedawiki.com/