Wiki subpages

[bySebastian]

This issue is:

• Feature request

Now I can add pages, but it would great to add also some subpages to a page.
E.g.

• Analyse
  -- Homepage
  -- Detail page
  -- Contact page
• Meeting notes

[lastlink]

This is supposed to be a simple wiki plugin. You're welcome to do a pull request. Most wiki's at least the ones I'm basing off of don't do this (github, taiga, etc). What you can do is a table of contents with the first page.

[lastlink]

I think with my pending reorder feature, you'll be able to add -- (dashes) and do your own subpages this way. I don't really plan to directly support these though. Pull requests are always welcome. I close this issue when the reordering support is finished.

[bySebastian]

Okay, thank you.
At the moment I don't have time to make a pull request. Maybe in future...

[imfx77]

Hi there, quite new to Kanboard and its plugins at all.
Yet catching up quickly as I have some serious dev background.

Anyways, on the topic - wiki is an awesome addition to a project management as they go hand in hand - been using quite some of both management and documentation software. And I was going to make that same enhancement request myself as did @bySebastian. Having a fairly complex project that requires Kanboard management in most cases implies that it also requires a fairly complex documentation. Which a flat Wiki structure, even if you can re-order the pages, can hardly comply with. So, no offense, but if there's gonna be a Wiki plugin to the Kanboard, it would be not just great but absolutely necessary to allow for pages hierarchy. Otherwise I think people will just use outer alternatives, in this way breaking the whole integration thing 😕

On the technical side. I haven't dug into the impl, I don't know what is the effort to impl such an enhancement. I can only assume that the data structure and the code for the tasks are reused in order for the wiki to co-exist in the same database and codebase. And regarding that I just wander how complex is it to have each page keep an ordered list of child pages (thus implementing a hierarchy)? And maybe it is possible to impl this by reusing the structure and functionality for the tasks and sub-tasks? It's kinda the same relation - of course on a multilevel page structure this is likely to introduce cycling in the hierarchy that must be handled appropriately.

If the whole thing is too much to ask, I guess I'll try to make some hacky workaround to my local copy to cover my needs. I just thought there would be more people interested in an actually structured Wiki.

Greetings,
and Thanks a lot for the work so far 👍

[lastlink]

@imfx77 reorder feature now working. I don't know if I have bandwidth to implement subpages. But prs are always welcome. You can organize with the reorder by adding dashes - to the subpage name and dragging in order preferred.

[imfx77]

@lastlink
I actually intended to try implementing this feature in my fork at some point, solely for my own needs, as I got the impression that Wiki is stale and going nowhere.
But in the meantime, I got quite involved in developing another plugin, which will hopefully cover most of my needs and expectations that I initially had for the Wiki. So I want to finish and release that first, then I can spend some time on the Wiki supbages feature.

What I can say, now that I've already gained some experience in making KB plugins is:

• On the visual side - there are some existing jquery plugins that can be either fully integrated or partially adopted for the specific purposes of the Wiki Contents Tree (like this or that) - won't be quite trivial, but is doable imho.
• On the backend - obviously the tree structure needs to be persisted in the DB in some way, so an eventual PR will inevitably introduce schema changes - most certainly a separate new table for the content tree structure, and probably some new column(s) to the wikipage table.

Both aspects may grow immensely complex depending on the expected features. So, in the first place, I think some reasonable basic requirements must be strictly defined - such that will serve the needs of most users. And then structural and visual changes can be negotiated, a specific implementation approach considered, and some roadmap planned to deliver smaller chunks of functionality.

So, I guess I will first sync my fork, update the Wiki plugin to the latest, and see if it suits me well enough as is. Then when I have some free bandwidth of my own, I can ping back to say if I am still interested in taking over implementing this feature as true subpages.

[lastlink]

Yeah it looks doable. Idk if I'd prefer to do a drop-down button or just display everything. Technically schema wise all you need added is a parentId column.

I'm a bit concerned about pagination. If you have more than 50 wiki pages on a project the html dom will be slow on mobile devices

[lastlink]

@imfx77 I almost have it finished in https://github.com/funktechno/kanboard-plugin-wiki/tree/f/subpages

[imfx77]

Wow, you're fast 😮
I see you made use of the jquery-sortable, hope it wasn't a big pain.
I've got some domestic problems, and also dug into a hairy refactoring of my Wysiwyg-MD-Editor plugin.
Actually, made quite a mess on my local server, and need to sort out things first.
So haven't yet updated even the latest Wiki from master.
If I manage to wrap everything up before you release officially the feature, I will give the subpages branch a try 👍

[lastlink]

@imfx77 it's finished and working. Has all core features pending website update kanboard/website#512. Nested and dragging all work. Besides styling enhancements should be fully flushed out. If there are requests I could build out the rest api, but there hasn't been much of a demand.

[alfredbuehler]

Unfortunately, it doesn't work here. It always crashes as soon as I want to display a wiki page. Did I miss something?

[Tue Jul 23 10:59:36.429947 2024]
[php:error]
[pid 1356901:tid 1356901]
[client 127.0.0.1:46466]
PHP Fatal error: Uncaught TypeError: count():
Argument #1 ($value) must be of type Countable|array, null given in
/home/abu/prj/Wiki-orig/Template/wiki/detail.php:48

[imfx77]

@lastlink
Same thing here, as @alfredbuehler said ;/

I thought it was because of the existing pages that have no parent set, but a new page did trigger the same issue - and its parent_id in the table is also NULL, so guess NULL is a valid value for "no parent".

What puzzles me though, is that I don't see any code in Wiki controller or model that sets the children property of a page, which is also passed to renderChildren().

Since you've already removed the subpages branch I can't tell if it was working there, I can just suspect that some code might have not been merged properly to the dev/master.

Any chance you have some local uncommitted changes?

[lastlink]

I missed a file when checking in changes, I'm updating the release now. see #79

kanboard/website#513

[imfx77]

@lastlink
I confirm it is functional now 👍
There is definitely what to be desired UX-wise, but I guess that can wait 😏
I might propose some convenience improvements in a PR at some later moment.
Thank you! 🙏

[imfx77]

@lastlink
Sorry to bring bad news 😒
I just observed that introducing the plugins/Wiki/Asset/vendor/jquery-sortable/jquery-sortable.js breaks the drag-n-drop behavior of tasks in the board. Haven't dug deep to detect the exact cause, but this script is the main culprit.
Wiki subpages drag-n-drop works just great, but everything else drag-n-drop doesn't ;/
Should I open this as a separate issue?

[imfx77]

As far as I can see, KB comes with jQuery UI - v1.13.2 which includes the sortable functionality used by KB for drag-n-drop. I guess jquery-sortable.js v0.9.13 overrides that, and because of the different impl and usage, the references from KB board and other pages don't work anymore. The standard sortable only supports flat lists without nesting.

I would try renaming the export from jquery-sortable.js v0.9.13 to smth different than sortable e.g. sortableTree (or even more use specific e.g. sortableKbWikiContentTree) and using it only for Wiki contents. If my guess is right, that should solve the problem, as the original sortable functionality of KB wouldn't be overridden.

I think the export is the last line of jquery-sortable.js v0.9.13 :

  ...
  }(jQuery, window, 'sortable');    <========

[lastlink]

@imfx77 I have the fix out already. I'll only load the javascript on the details page.

[lastlink]

pending kanboard/website#514