Recent Changes - Search:
Main /

There has been a history of wikis for the Devuan project, PmWiki is the existing one as I write.

Around mid December 2024 onefang (me) took over the Devuan wiki system at wiki.devuan.org, so now I'm the wiki herder as well as the package mirror herder. I see my new job as looking after wiki.devuan.org the server and the software that runs on it, it's the Devuan teams job to decide what to do with it.

Wiki audit.

There's a bunch of wikis installed here already, so my first task is to audit the server, see where the actual content is. Then herd them together. First measure the size and shape of the mess, then decide how to clean it up, then clean it up. I'll report things I find here . I eat my own dog food.

My basic conclusion is that I should write my own wiki, eventually. Convert and combine the existing content into one common wiki system.

What I have been doing.

So I started writing code to automate converting and combining the remaining two wikis that are on this server. Both systems use their own bespoke wiki syntax, with nothing to convert it to anything else, and both are a pain to admin. On top of that, neither is in Devuan repositories, so I have to update them manually.

In a few months I have written code that is basically a front end to the existing wikis. It converts the pages from the existing wiki systems to a common wiki syntax that is easy to convert to and from a variety of other wiki syntaxes. It then combines them into one big site of static pages. It has to jump through hoops to do the conversion step.

Currently each page has a link at the bottom to the original page on the original wiki system, where you can edit the page if you log on there and have edit permissions for that page.

I have manually curated the combined results to build what our wiki should look like. This is based on the structure people where building on the other wikis, wedded to any content people created that fit into what was empty pages.

What we need.

Most of a wiki systems users are the readers, the people that come to the wiki site to find some information. So most of the job of a wiki system is to serve pages that are mostly static, but might get edited every now and then. The web server that was installed on wiki.devuan.org is nginx, which is well known as being very fast at serving static pages. Have to have happy content creators to, or there's no content, which requires a dynamic backend.

What we have so far.

We have that now. The presentation layer of a wiki system. What I'd like to do is write the rest of that wiki system, which I'm gonna do for other purposes anyway. Given that I have written what is essentially one third of a wiki system just in combining and converting the existing mess, in a few months, makes sense to just keep going and write the rest of a wiki system.

What's next.

http://sledjhamr.org/notYetAnotherWiki/TODO.HTML and http://git.devuan.org/onefang/notYetAnotherWiki/src/branch/master/TODO.md is the TODO page for the notYetAnotherWiki software I'm writing to do all of this.

I need to add a search system, then that's basically the needs of the readers taken care of. An added bonus would be history, diffs and an ATOM or RSS feed. A search system needs a dynamic backend on the server, coz you can't do all possible search results as static pages. History, diffs and ATOM / RSS I think I can do with static pages. A dynamic backend would also be needed for members and editing, but I should get that right for search first, safer that way.

I need to add a member system, and then a system for those members to edit and manage the pages and wiki directly. It's entirely possible I can write a member system that can use existing credentials from the existing wikis, maybe even single sign on. I've done that before, I'll be reusing that code.

Finally, most wikis have some sort of talk page linked from each page, add that.

Might only take a few more months to get all those basics working. See how I go.

Other PmWiki members should be able to edit the bugs and features below to add any they find / want. Maybe I should hook this up to our existing bug system?

I want to move the existing PmWiki to pm.wiki.devuan.org, I had already moved the Foswiki to fos.wiki.devuan.org.

Using git

I mentioned using git for the content, and the home page of nYAW does exactly that. It uses cgit over there, which is useful for displaying history and an ATOM feed of the entire project, but is missing any management stuff. Devuan currently uses gitea for git, which does provide a management layer. This wiki has adding it's own management layer in this roadmap. A git management layer is different from a wiki one. So I'll go ahead with this roadmap's wiki specific management layer.

I have no idea if we even want to put our wiki content on our gitea.

Using git is still a good idea for history, and history is good for ATOM / RSS feeds. This is what I'm thinking -

Use a local git for the results of the nYAW converted content.

Hook up to Foswiki and PmWiki saving mechanism. Convert as it's doing now. Diff the changes in the converted .md files for history and ATOM, commit them to the local git.

I can get git to set the author of any given commit to be the actual author of the change to a page, but it does require some sort of email as well as name. wiki.devuan.org doesn't have any actual email infrastructure. I can either just have a fake one, or use something like AuthorName@wiki.devuan.org, perhaps including the originating wiki system. So any changes I make to this page on the PmWiki system would have onefang@pm.wiki.devuan.org as the authors email. It might be possible to tell git to just forgo the email bit entirely, dunno yet haven't looked. Not gonna have any real email addresses, and I'll try to make sure the fake ones are not visible to spammers, if git allows.

If we want our wiki content on gitea, it can mirror this local git, which is a feature of gitea where it does an initial clone, then pulls every eight hours from an external git. This local git will be that external git.

Creating ATOM and RSS feeds from diffs looks simple enough. Maybe just ATOM though, which has more or less obsoleted RSS.

Known bugs

These seem to be one off corner cases.

It's good when someone else creates a huuuuge and complex test case for you.

Features needed

  • Search page.
  • History and diffs.
  • ATOM and RSS feeds.
  • Member management system, so people can create their accounts, and admins can manage them.
  • The ability to edit and manage the CommonMark files directly by members.
  • Talk page for each page.
  • Better accessibility.
  • Better HTML and CSS, though still try to avoid JavaScript.

Scorn, snark, and suggestions

Well, maybe less of the first two, and more of the last. B-)

http://nyaw.wiki.devuan.org/users/ChomWitt/MyPmWikiNotes.HTML where chomwitt has some interesting ideas, I'll add some here as suggestions.

  • The toolbar issue can be solved by a customizable toolbar, once a member is logged in.
  • Collapsing headings I had already added to the nYAW TODO.
  • "section-granularity page editing" fits in with that, if you want to hide them during reading, you probably don't want to see them during editing.
  • * Also allows for different people to be editing different parts of a document at once.
  • * Two people editing the exact same thing at the same time gets tricky, think I might want to avoid that.
  • Interesting idea about notifying someone if you reference one of their documents, potentially promoting some collaboration.