Next Generation Wiki
As mentioned multiple times MoinMoin is heavily outdated hence we will start on migrating from MoinMoin to DokuWiki.
The decision is still pending and wiki-admins@ are currently playing with both Dokuwiki and Mediawiki.
I will setup the notes and changes as required here.
Anyone wants to give some inputs please feel free to modify or add notes here.
Important Notes
- No objection.
- Preserve all existing links.
- Use elbarto.nyi for this work.
- Be careful while PoC to block Search Engine Crawlers indexing the intermediate pages
Perhaps as part of the migration, a header should be added to every page stating that it has been migrated from MoinMoin and not touched since. Eventually, that will give us an idea of which content is alive and loved and which is stale and can be pruned.
SergioCarlavilla (Will need a good FreeBSD inspired theme)
- Will help with related themes
- The migration should focus not on a forever backward compat, but on a oneshot compat, aka the day we flip the switch, no new dead links
- Contribution Policy
- Expiration Policy(If you have not touched it in N years, we may feel free to delete it. Or, if after contacted, etc. N should be large, like 5 or something)
- FreeBSD Community Standard
fwiw, an easy search on "contains Category" returns the following: - 1574 results out of about 10647 pages Clearly out of those ten thousand, some pages are "more equals than others", but OTOH those statistics are enough to give me pause.
- Note that there are a few "historical" pages which I'd like to keep around. (A list of possible pages would be really helpful here)
Even If you have not touched it in N years, the page may still correct and useful, Example: https://wiki.freebsd.org/Ports/Userbuild
Tools
I am looking into different tools and will update here.
moin2doku
Moin2Doku is a converter but it requires older versions of MoinMoin and Dokuwiki. I will try to create a VM with some older versions and see how it goes.
moindump
MoinDump Creates a flat hierarchy html outputs which is somewhat useful to be used with pandoc but will involve some manual works. Need to explore
WikiMigration
WikiMigration is another tool which looks promising as it creates the both creole/html outputs in a similar directory layout which then can be used with pandoc
Caveats
Dokuwiki
DokuWiki does not support CamelCase filenames which is the default in MoinMoin
MediaWiki
We had a discussion with in the matrix channel with meena and Mia Luna Tearmoon who is running a Mediawiki on FreeBSD. They have shared their insights on Mediawiki which is kept here for future references in case we decide to go this path
- Please reconsider the URL scheme: using the root article path is generally not recommended and makes it a lot harder to scale the stuff later. I had some wikis set up this way and later had to invest some effort to change the scheme and keep thousands of redirects on my load balancer. Having a clearly delineated /wiki or similar that does not actually exist on the filesystem has noticeable advantages when it comes to caching policy
Note that ConfirmAccount regularly breaks for PostgreSQL and for any popular installation really gets inundated by account requests from spammers. (before I disabled it I was getting 30-60 account requests a day, and that is with captcha enabled)
MinervaNeue is best used with MobileFrontend extension (and if you run Varnish in front you can set up devicedetect and make MW flip between skins for unauthenticated users based on detected device) (there is also a responsive skin called Citizen, designed by Star Citizen wiki people; it has dark mode for those who need it)
- Make the redirects permanent and leave on for 2-3 years (1 year is enough for Google and most other search engines)
oh and regarding ElasticSearch: you basically need it if you plan to use various templates; it is not as critical if you do not rely on those. the issue with stock search is that it does not render pages for indexing, it runs off plain wikitext in the database
CirrusSearch+Elastica (the extensions for ES) actually render every page before indexing
- I ran everything on an E1230 with 24 GB RAM and spinning rust, and it was typically below 1.5 load avg. max request rate seems to have been 2400 and load avg was around 5 at the time
- but this is with Varnish in front, and you really want Varnish or something similar (maybe nginx? but you need to set it up for purge and for bypass for logged in users). you want to aggressively cache load.php for non-logged-in users
- that might also be true, I think I disabled CA when I was still on 8.0 also you really want
$wgResourceLoaderMaxage = [
'versioned' => 30 * 24 * 60 * 60, // 30 days
'unversioned' => 24 * 60 * 60, // 1 day
];(one important thing that is often missed: when using reverse caches you have to set $wgInternalServer to http://.../ because GuzzleHttp will otherwise CONNECT instead of PURGE). wgInternalServer is specifically for CdnServer requests
- reverse cache reduces server load by an order of magnitude so I highly recommend that, otherwise nearly everything pokes PHP
upgrading MediaWiki per official instructions involves extracting the tarball to a new directory, getting updated extensions/skins, then copying configuration over etc. which is why, and I forgot to mention, one of the first orders of business when setting up MW is to have the upload path (images) outside the MW directory you do not want to mv images every time, easy to forget (and takes a LOT of time)
- for patch version updates like 1.41.x you can apply the patch file they offer for major version updates, 1.x, you really should do the whole dance (to make sure your extensions are updated for the new version)
upgrading MediaWiki per official instructions involves extracting the tarball to a new directory, getting updated extensions/skins, then copying configuration over etc.
- A small patch file is usually made available for a minor version upgrade. You'll need to download patch to use this. Manually download and extract the patch file from the dumps site or follow the directions with wget below. Patches are incremental, you can not skip a version.
- MW has 'major' being the 2nd group
So you will move through the 1.36 -> 1.37 -> 1.39 or do minor patches on 1.35 and jump into 1.39(LTS) ? oh, personally I use most current version, typically, because of better compatibility and everything
- I would still suggest 1.39 LTS so you can update it with patches without much downtime at all pretty sure it has all the PostgreSQL patches backported
- MW is the only actually well supported wiki engine
Conversion
Convert MoinMoin to Mediawiki needs to be tested.