mediawiki replacement

Website
1

I do not think we have a thread for a mediawiki replacement alraedy.

Continuing the discussion from whonix.org wiki translation / mediawiki extension translate - technical discussion:

Whonix vs Qubes Docs - #8 by Ego

disadvantages of mediawiki?

A bit outdated perhaps, not fixed, open for discussion:

I regard the discussion on how the new Whonix home page (and perhaps also Whonix download page) should look like in future and with which technology it will be implemented somewhat separate. They are related, but a non-mediawiki Whonix home page would not force us to entirely abandon mediawiki. (Discussion thread: https://forums.whonix.org/t/new-qubes-website-new-whonix-website )

question about the mediawiki replacement:

  • How does the new solution make sure translated pages do not get out of sync? I.e. when the English original is modified, how is this change reflected or at least noted on the translated version?
  • Can we make it pretty? Usable, modern presentation?
  • Can we have a mostly imported migration process from the old to the new wiki?
  • What about internal links?
  • What about wiki templates?
  • What about special markup such as {{Code2|...}} etc?
  • Can we add meta tags (for seo, social media)? (Example below.)
<meta name="description" content="Privacy protection. Anonymity online. Anonymous Operating System." />

Here are my notes on what I do not like about how one can contribute to Qubes documentation which is also based on jekyll.
https://www.whonix.org/wiki/Dev/jekyll

I can summarize it as saying that contribution to Qubes documentation is for me a lot more cumbersome than just a whonix mediawiki edit. If I had not had available the convenience of mediawiki, I would likely not have created so many edits and content in Whonix wiki. So usability of editors (including mine!) has a direct influence on quality.

The reason why I picked originally of all the solutions mediawiki was wikipedia. It is undeniable that wikipedia has become useful in the mainstream so the underlying technology must not be that bad. Whether the specialized Whonix community without mediawiki engineers who can make things pretty is also best suited for mediawiki is of course open for debate.

2

Good day,

That is something I can’t gurantee/test at the moment, as exporting mediawiki never worked. Will thus have to create a “demo mediawiki installation” with which I may test this.

Absolutley understandable, is a focus for me as well and the main reason I threw my first few “purely Jekyll based” attempts to the wind. A solution which uses markdown/plain text files seems simpler to implement as well and would make export for offline documentation, etc. far easier.

It definetly isn’t. The thing is just, that, as far as I’m concerned, a lot of the things we use (like translation, templates, etc.) aren’t used by wikipedia. There wikis are completley seperate for different languages and the style has been almost unchanged for the last few years. “Translate”, for example is an extension made for mediawiki which was never used by wikipedia or any of its “sub-sites”, so a trouble-free user experience can’t be guranteed as oposed to other features which have been tested and refined by the people behind wikipedia.

Like I’ve said in the other thread, I will have a few alternatives running and integrated with the new homepage design finished soon, so you and everyone else may test them and decide what is best.

Have a nice day,

Ego

1 Like
3

Alternatively…

All media files are here:
WhonixWikiBackups/mediafiles at master · WhonixBOT/WhonixWikiBackups · GitHub

We have current backups of all media wiki pages in mediawiki markup format here:
GitHub - WhonixBOT/whonix-wiki-backup: Backup using git-mediawiki. Alternative to XML Backups https://github.com/WhonixBOT/WhonixWikiBackups

4

Good day,

Ok, great, will use those to base the demo(s) around.

Have a nice day,

Ego

1 Like
5

Good day,

First of all, on http://egobits1.github.io/wiki/, you may find two buttons (labled 1 & 2) which lead you to two new, purely Jekyll and markdown based potential alternatives to mediawiki. I also wanted to include a fresh mediawiki and dokuwiki version for comparison, though this was apperantly not possible.

Now, regarding the two new wiki’s:

The first one is simple. I mean REALLY simple. You have a bar on the left to select topics, it may be edited via prose.io and everything works without JS.

The second one is more interesting here. Not only does it have a unique and interesting look, as well as nice effects, it is also smaller, easier to edit (because the folder structure is even simpler) and just gerenally looks more professional.

However, it uses JS for the effects. The thing is though, that after messing with it for some time, this seems to not be an issue anymore, as not accepting JS won’t lead to the site beeing inaccessible (like the forum), but just look more simplistic with less effects. And even then it arguably looks better than solution one.

So, in summary, I’d apprichiate a bit of input here, what fits better, what could/should be changed, and so on.

Have a nice day,

Ego

P.S.: I admittedly didn’t look trough the complete list, though a lot of files I got from the backup you linked where sadly rather empty, only containing a few lines of code…

P.P.S.: Just noticed that I pushed the wrong “build” (if you can even call it that) of the first wiki and now nothing works, am currently fixing that…

P.P.P.S.: Should work now.

1 Like
6

V2 has a blocker, since chapters without javascript are not auto expanded. This would look very strange.

V1 might be okay. I am not so impressed by it at the moment, because the skin does not look that great. That may or may not be work in progress?

Currently whonix.org mediawiki (with the strapping skin) does not look that great either. It looks better than default mediawiki with the space wasting sidebar. Our table of contents at the top of bigger pages (such as the Bridges page) may not be ideal either. A table of contents on the side may be better?

I am also very worried the new wiki will be feature rich enough.

  • wiki templates (otherwise stuff like vpn documentation and other repeating stuff gets unmanageable)
  • footnotes (to somehow get all the information organized the geeks are asking about, and notes to myself)
  • expand buttons
  • footer (for legal purposes, imprint)

I am also not feeling ready to pick a mediawiki replacement. I am still trying to collect advantages / disadvantages of mediawiki:
Dev/About Infrastructure - Kicksecure

To avoid spending a lot work on the migration and then recognizing that something is a blocker.

I was also wondering… Instead of inventing this, are there any comparable projects that already found a solution to this?

Please tell me if I am over complicating this. I hope I am not irrationally emotionally attached to mediawiki. Don’t get me wrong. As a person appreciating security, I literally hate mediawiki requiring mysql, mysql backups. Too much of a blackbox. Hate, that there is no plain text file representation that can be easily backed up and restored.

7

Good day,

Understand where your comming from, am looking into the things you mentioned at the moment myself.

Like mentioned before, dokuwiki claims to offer a lot of benefits over mediawiki, though I’m still working on integrating it properly with the rest, as it very much seems to need to be in the root folder of a server…

Don’t worry about that, it makes absolute sense to want to be sure that everything works, seeing how much would need to be transfered once the decision is made. I personally feel sometimes the opposite effect actually, that I might appear to be to attached to killing of mediawiki as fast as possible…

Have a nice day,

Ego

1 Like
8

(I wanted to answer this a long time ago but somehow slipped through.)

To be expected because many pages are outdated/deprecated/merged/moved to other pages. However, it is all there…

While I did not make a complete verification, for all random samples I took, it looked complete. So I am quite confident that we do have a backup in mediawiki markup format of all wiki pages.

However, it would be possible to make the backup better looking and perhaps clean the wiki a bit by breaking / deprecating older redirection links such as whonix-wiki-backup/AppArmor%2FHexChat.mw at master · WhonixBOT/whonix-wiki-backup · GitHub which are probably not that important at this age. I was itching me to do that and I was wondering if that was a good idea.

9

Either a mediawiki skin or mediawiki replacement is very much needed. We have a ton of great content that evolved over the years but the presentation is awful.

(Medaiwiki skin: some websites look professionally, yet based on mediawiki. Possible to do with a skin.)

Example: Nym Servers and Pseudonymous Emails

Nymservers

About this Nymservers Page
Support Status stable
Difficulty medium
Maintainer HulaHoop
Support Support

Contents
[hide]

Tons of white space everywhere. The user has to scroll a lot until the actual page starts. First impression is “wtf is this about”.

Also too much white space left and right. I am already having blinders on (meaning knowing it too much about the place myself so I fail to notice the obvious “dirty” spots) and using browser zoom to make up for the white space issue.

1 Like
10

My opinion is probably going to be unpopular because of the work involved but I think a mediawiki replacement is the way to go. A new skin is like putting lipstick on a pig and kicking the can down the road. We will still be stuck with a shoddy platform that can’t be used for offline documentation. The great data that was collected is locked in to online hosting since running a local edition needs too many dependencies.

11

Agree that the generally great content here is made to look cheap by the shitty mediawiki appearance (even the Firefox website looks cheap). I particularly dislike the titling, sub-titling, and limited options for nice tables and general presentation.

Would be nice to find some middle ground where it could be made to look sexier, without a ton of work to bring the content across.

So maybe a decent skin is a good option in the short-term, with full mediawiki replacement in the long term(?) (I know squat about these tools in general)

Definitely too much white space in all directions.

Also, limited options for highlighting text, putting things/quotes etc easily in presentable (pretty) boxes to make it stand out and many other things.

12

Any other content management platform does not necessarily give us offline documentation either. Even if there is an option for it, it does not mean it will be in a presentable that works for us without a ton of additional work.

mediawiki advantages from Dev/About Infrastructure - Kicksecure (also disadvantages collected there):

  • community contribution friendly - flagged revisions - usable way to allow anonymous users to edit and to let admins review changes before these go live
  • seo - plugins provide good OpenGraph meta tags and meta settings (description, images)
  • wiki templates
  • footnotes
  • expand buttons
  • footer
  • mobile view
  • mediawiki markup text file backups (but are not easily importable)
  • short and detailed buttons (probably not unique to mediawiki)

The ones in bold are easily lost when migrating to another content generator other than mediawiki.

Don’t get me wrong though. I would love to get away from mediawiki. I literally hate its database being stored in mysql. The html files being generated from clean human readable source files would be very much preferable. This is like Qubes does that. However, Qubes website contributions are much harder since users practically end up using github web editing and they don’t have wiki templates either. Also their TOC requires javascript. Among some other/similar limitations wrt stylistic options.