Wiki.js

I would like a navigation mode where the sidebar renders the page tree itself, the wayv2's Site Tree mode did, instead of a menu I build and maintain by hand. On 3.0.0-beta.592 the sidebar is driven entirely by a stored list of link, header andseparator entries. A new site ships that list empty, so the sidebar stays blank no matter how many pages exist. The navigation modes that do exist(inherit, override, overrideExact, hide, hideExact) all describe how a hand-built menu is passed down or suppressed. None of them renders thetree. features.browse only turns Browse on or off. Browse mode covers "what is in this folder", but it is a panel that closes as soon as younavigate. What is missing is keeping the structure on screen while you read, which is what Site Tree did in v2. The reason this matters beyond convenience is a hard limit rather than a preference.NavSidebar.vue renders two levels only: a parent with children becomes an expansion item, and those children are a flat list with no recursion,so anything deeper cannot be expressed at all. My content comes from a git repository. At 23 pages the menu is 25 entries and about 3.4KB of JSON, which is manageable. A repository of 1000 markdown files is three to five levels deep, so most of it simply cannot appear in thesidebar, and the part that can would be roughly 133 KB of entries to write by hand and rebuild after every import, rename or move, because nothingregenerates the menu from the page tree. What I am asking for is a mode that renders the page tree directly, honouring page rules, with a configurable root and depth, selectable alongside the existing static mode. One note for triage: this is not Folder View or Sub-pages list, both marked Added In V3. Folder View asked to see a directory's contents, Sub-pages list asked for child links inside page content. Both list children on demand. This is about the sidebar holding the whole tree persistently. Related discussion in #6573.

The new editor is amazing and great for use by technical people, but nontechnical folks are not going to understand it, unfortunately. It would be lovely if there was a WYSIWYM/WYSIWYG, simplified markdown editor.

Wiki.js provides us with very powerful multilingual functionality, enabling creators to quickly build pages in multiple languages. However, document translation and synchronization are major issues, especially when there are many languages involved (for example, I have an 8-language wiki. When I create a page, I need to synchronize translations for the remaining 7 pages. Moreover, if I later modify this page, I also need to manually synchronize the changes to the remaining 7 pages). The emergence of AI will make translation and synchronization work much easier. Users only need to enter an API KEY to let AI help translate a page into various languages, and when the page changes, it can also be quickly synchronized to pages in other languages. I think this can be applied to the localization of pages and navigation. Based on my previous work experience, I can provide a rough workflow for your reference: Users enter the API KEY, API Base URL, and other necessary information on the AI management page in the backend, so that Wiki.js can correctly access the large language model. Users can use AI to select single or multiple items on the page and navigation management interfaces in the backend, and then use the AI translation function. AI will translate all content of the original page into the specified language, but will not change certain fixed paths (URLs, images, etc.). It is recommended to use the default language as the "mother tongue" to determine the synchronization status of each page and navigation. This is very simple: you only need to compare whether this page exists in other languages and check their last edit times to know whether the page has been synchronized. AI translation sometimes has problems, so manual modifications are needed. (According to point 3, manually modifying interfaces or navigation in non-default languages will not break the synchronization status.) Not all pages and navigation need to be synchronized, so a blocking option can be added. On the AI management page in the backend, a glossary of professional terms can be maintained for the translation of special content such as company names and proper nouns. I hope these suggestions can be helpful to the Wiki.js team and contribute to making Wiki.js even better. Thank you for your time and for your continued work on this excellent project.

When duplicating a page, please also copy the contents of the Scripts and Styles fields in the page properties.

Currently when moving or renaming a page, all existing links point to the old page. The correct behaviour would be to update all links to the new page, either optional or explicit.

It would be useful, for non technical users, to have a draw.io integration in the Visual Editor (like BookStack has).

Hi, Currently you cannot center align an image in Visual Editor. There are options for "left" and "right" align, but instead of a "center" align option there's a "Full size image". Please add an option to center align an image.

Please let us use a color thats not the wiki.js blue, thanks

Ability to delete folders in the Image / File Manager.

Images should be pasteable via clipboard ctrl+V as a shortcut, similar to how Github's MD editor works. This would be a gigantic time saver.