MediaWiki 1.43 LTS

[hairmare]

We want to update to the next LTS version of MW.

The version we are currently using is EOL in Nov 2025.

The goals of this ticket seem reachable, some parts can be worked upon now.

There are some blockers to reach this goal:

• We need a compatible SMW version to be released
• We want to update the base image to EL9, this means we might need to change the PHP deployment model to use FPM

This new LTS also affords us to consider doing some change:

• Get rid of the approved-revs plugin completely Remove ApprovedRevs Extension #286
• Review and potentially refactor the env variable magic in our LocalConfig.php
• Scale down out ExternalData usage (esp. the netbox integration thingy that is a pain to operate)
• Modernize, clean-up, and publish our mod_sec ruleset

While we are at it we could also add features

• Add Kroki as a long-term alternative to drawio Add Kroki as a Drawio alternative #284
• Implement double SSO so we can re-enable the api
• Improved Mobile Device View Improve Mobile Device Support #301
• Add a Helm chart (because we can, for testing, and maybe for "offline"ing)

This is going to be a major change that breaks backwards compatibility,

• Announce early that image is switching to a fpm runtime (e.g. in README.md)
• Create some migration docuemtation

I'm assuming there might be more to it than this summary and don't foresee us moving to 1.34.0 as proposed by #264.

[hairmare]

For SMW, we want to wait for at least SemanticMediaWiki/SemanticMediaWiki#5951

We can keep in mind that the official feature matrix tends to understate SMW's compatibility from time to time.

[hairmare]

Get rid of the approved-revs plugin completely

The approved revs plugin is now deactivated on our instance and ready to be removed completed from the image.

See #272 for how it happened.

[hairmare]

There don't seem to be any obvious external dependencies that are blocking us now that SMW supports 1.43.

My next steps are:

1. Start building out s2i style base images like we have for python
2. Build a container-image-php-fpm runtime
3. Make this repo use it

We can user either container-image-nginx or container-image-httpd as web server and do some emptyDir or hostDir magick in prod for now.

[hairmare]

1. Start building out s2i style base images like we have for python

I've been failing to find strong use-cases, and i've also found that the sclorg images don't fit our abstraction layer well.

I'll most likely skip the s2i step and just go for the runtime until we have more cases

There are also difffuse plans about breaking this monolith and moving to several container-image-* repos + a top-level service repo...