Migrate wiki to MkDocs

[seancolsen]

Related to mathesar-foundation/mathesar#3079

Warning
I will be periodically rebasing this PR to handle conflicts as I see fit. Please do not push additional commits to this PR without alerting me first.

Changes handled in this PR

• Migrate content into a format which MkDocs can publish.
• Simplify home page significantly. Be more sparse. Don't attempt to serve as a marketing page. Direct people to the marketing page instead.
• Lots of content cleanup

Changes NOT handled in this PR

• Fix wiki call-out box content using {.is-info} {.is-danger} {.is-warning}

  (Now done by Kriti)

• GitHub actions for auto deployment

How to review

1. Pull this branch locally.
2. Open README.md and run through the steps to "Preview your edits locally"
3. Click through the local build of the wiki to test it out.

[kgodey]

@seancolsen I fixed wiki call out boxes in b399be9 (was pretty quick using regex).

[kgodey]

@seancolsen This looks great, thanks for moving this forward. I made a commit to fix wiki call outs and commented in the main PR.

Feedback:

(1) Please add redirects for the pages in https://wiki.mathesar.org/en/engineering/reports so the URLs still resolve. The GSoC website links to these reports, so we want them to work. Maybe also add a comment explaining this so if we ever clean up redirects in the future, we know not to delete these.

(2) Can we use the same extra stylesheet we use for the main docs (docs.mathesar.org) here? Dark mode with the default stylesheet is really hard to read.

[seancolsen]

@kgodey this is ready for re-review now.

• I made a commit to fix wiki call outs and commented in the main PR.

  Thanks for taking care of this!

• add redirects

  Good point. Thanks for raising this. I had intended to take care of this, but it slipped my mind. In 6fa9099 I added some redirects which I hope will address this concern of yours. I went a bit further as well, by using git diff --name-status 72049f5 to show all the files that had been renamed. Then I massaged that data a bit to produce what I think is a pretty high-quality mapping of old paths before this migration to new paths afterwards.

  In 3a3838f I also added a number of additional redirects to handle the fact that Wiki.js paths can optionally be prefixed with /en. Ideally, we'd be able to handle this with a wildcard redirect. I did some searching to see if there might be a way to handle wildcard redirects within MkDocs or a plugin. The mkdocs-redirects plugin that we're using does have an open issue requesting support for this, but it's unclear if the maintainers plan to take up this work. In theory, we could handle this at the webserver level, but the mechanism for doing so would be dependent on our hosting provider. I did a little searching for "GitHub Pages redirects" and similar, but I didn't come up with anything. Since we can't programmatically redirect all paths prefixed with /en, I had to identify the important ones to hard-code. For this, I searched the source code in the main Mathesar repository for "wiki.mathesar.org" and handled all such paths. Then I hand-picked a few others which seemed like they could potentially have links in the wild.

  Similar to the above, I it occurred to me that Wiki.js serves content with the .md suffix applied to paths, but unfortunately MkDocs returns a 404 when paths have a .md suffix. I tried to find a way around this but couldn't see a good solution. If any wiki URLs in the wild have .md suffixes, followers of those links will be out of luck. I'm inclined to cross our fingers for this one. Note that MkDocs does remove the .md suffix when rendering markdown for internal hyperlinks, so we're good there.

• Maybe also add a comment explaining this

  Hmmm. Where are you imagining such a comment would go? In mkdocs.yml? I wouldn't imagine we'd ever have an incentive to remove redirects from that file.

• use the same extra stylesheet

  Cool. Done. I forgot about this issue with dark mode.

Deployment

If you approve of this PR, I wonder how risky you think it might be to merge it into master now. Like, would this risk breaking the current deployment with the Wiki.js system? If not, I think it would be nice to merge it now, leaving the deployed site stale for some time while I sort out the new deployment. The benefit to this would be that I could stop continually rebasing this PR to handle changes to work log and project files.

[kgodey]

@seancolsen This looks good!

I'm inclined to cross our fingers for this one.

I agree.

Where are you imagining such a comment would go?

I don't think we need a comment now that the redirects are so comprehensive, the comment I was envisioning was to explain why we were redirecting only specific pages (and I figured it would be in mkdocs.yml, yeah).

If you approve of this PR, I wonder how risky you think it might be to merge it into master now.

I think we need to disable the git storage mechanism in Wiki.js (docs: https://docs.requarks.io/storage/git) before we merge this PR, otherwise it will attempt to reconcile the content and make updates to the wiki. Once that's handled, it's fine to merge it in and leave the wiki site stale while you figure out deployment. I assume you'll update the dev mailing list email thread once it's merged.