Whats New in MediaWiki 1.43.0: Key Features and Updates

1. User‑Facing Tweaks That Feel Like a Breath of Fresh Air

• Edit recovery, re‑imagined. The new “edit recovery” feature now auto‑saves a snapshot of your draft every few seconds, even before you hit “Show changes”. If your browser crashes or you accidentally navigate away, a friendly banner pops up offering to restore the last saved version. No more “I lost my work because I clicked the back button” moments.
• Improved visual editor toolbar. Buttons have been regrouped, and the “Insert reference” icon now lives next to the citation tools, making it less of a scavenger hunt. The toolbar also respects user‑defined CSS, so extensions that add custom buttons still play nicely.
• Better mobile experience. The mobile skin now supports lazy‑loading of images and a slimmer header that hides the search box until you tap the magnifying glass. It’s a small change, but on a 5‑inch screen it feels like a big win.
• Enhanced watchlist filters. You can now filter by “edited by me”, “new pages”, or “pages with pending changes”. The filter UI is a simple dropdown, no need to remember obscure query parameters.
• New “Page Tools” dropdown. Actions like “Move”, “Delete”, and “Protect” have been consolidated under a single dropdown, decluttering the top bar. The dropdown remembers the last action you used, so if you frequently protect pages, it’s right there on the next visit.

Honestly, these aren’t earth‑shattering, but they smooth out the daily grind. I’ve already found myself clicking the “restore draft” link more than once – a tiny safety net that feels oddly reassuring.

2. Sysadmin‑Centric Additions (Because You’re the One Keeping the Ship Afloat)

From the server side, 1.43 brings a handful of under‑the‑hood improvements that can save you a few headaches.

1. Configurable edit‑recovery interval. The default 30‑second snapshot can now be tweaked in $wgEditRecoveryInterval. Set it to 10 seconds for high‑traffic wikis, or stretch it to a minute if you’re worried about storage bloat.
2. New $wgEnableContentSecurityPolicy flag. Turn on CSP with a single line in LocalSettings.php. It adds the usual default-src 'self' directives, plus a few sensible exceptions for Wikimedia CDN assets.
3. Improved job queue handling. The job runner now respects $wgJobRunRate more accurately, preventing runaway processes during peak load. There’s also a new $wgJobQueueWatchdog setting that aborts jobs stuck longer than a configurable threshold.
4. Database schema upgrades are now resumable. If a migration aborts halfway (say, due to a power flick), you can re‑run the upgrade script and it will pick up where it left off instead of starting over.
5. Better logging for extension failures. When an extension throws an exception during a hook, the error log now includes the stack trace and the exact hook name, making debugging less of a treasure‑hunt.

One thing I wish they’d added is a built‑in health‑check endpoint. You can roll your own, of course, but a native /status page would have been a nice touch.

3. Developer Features – New Hooks, APIs, and Library Updates

If you write extensions or consume the Action API, you’ll notice a few new entry points and deprecations. Below is a quick cheat‑sheet.

New Hooks

• EditPage::beforeSave – Fires just before the edit is persisted, after edit‑recovery has stored the draft. Handy for sanitising content on the fly.
• UserLoginComplete – Replaces the older LoginFormValidError for post‑login actions. It passes the User object and a boolean indicating whether the login was via password or OAuth.
• PageContentSaveComplete – Now includes a $context array with the request source (web, API, or CLI), letting extensions tailor their behaviour.

Action API Changes

The API got a modest facelift. A few parameters were renamed for consistency, and a new formatversion=2 is now the default for JSON output. Here’s a quick example of fetching page revisions with the new format:

{
  "batchcomplete": true,
  "query": {
    "pages": {
      "12345": {
        "pageid": 12345,
        "ns": 0,
        "title": "Example",
        "revisions": [
          {
            "revid": 67890,
            "timestamp": "2025-09-20T12:34:56Z",
            "user": "Alice",
            "comment": "Fixed typo"
          }
        ]
      }
    }
  }
}

Note the removal of the “rvprop=timestamp|user|comment” string; you now pass an array of properties directly.

Library Updates

• PHP 8.2 is now the minimum supported version. If you’re still on 8.0, you’ll need to upgrade before the next major release.
• Composer dependencies have been trimmed – the symfony/http-foundation component is now optional, only pulled in if you enable the new HttpRequestHandler service.
• Internationalisation (i18n) now uses MessageLoader with built‑in caching, reducing the number of file reads on high‑traffic wikis.

4. Security – The Quiet but Crucial Upgrades

Security never makes the headlines, but 1.43 quietly hardens the platform in several ways.

• Content Security Policy (CSP) support. As mentioned earlier, you can enable a sane default CSP with $wgEnableContentSecurityPolicy = true;. It blocks inline scripts unless you explicitly whitelist them, a big step toward mitigating XSS attacks.
• Improved password hashing. MediaWiki now prefers Argon2id when the underlying PHP installation supports it. If Argon2 isn’t available, it falls back to bcrypt with a higher cost factor.
• Refined OAuth token handling. Tokens are now scoped more granularly, and the expiration window can be set via $wgOAuthTokenExpiry. This reduces the risk of long‑lived tokens being compromised.
• Saner file upload validation. The new UploadBase::isValidExtension method checks MIME types more strictly, preventing files with mismatched extensions from slipping through.

In practice, these changes mean fewer “Oops, my wiki got hacked” stories. I’ve already enabled CSP on a test install and the console warnings dropped dramatically.

5. Migration – What You Need to Keep an Eye On

Upgrading from 1.42 (or earlier) to 1.43 is generally straightforward, but a couple of gotchas are worth noting.

1. Deprecated configuration variables. $wgEnableUploads is now deprecated in favour of $wgAllowFileUploads. The old variable still works, but you’ll see a deprecation notice in the logs.
2. Extension compatibility. Some older extensions still rely on the removed Parser::getOutput method. Check the extension’s README or the MediaWiki Extension Compatibility list before you push the upgrade.
3. Database schema changes. The revision table now includes a rev_timestamp column with higher precision (microseconds). If you have custom queries that assume a specific column order, you may need to adjust them.
4. Job queue changes. The new JobQueueWatchdog may abort long‑running jobs that previously would have timed out silently. If you have custom jobs that need more time, bump the $wgJobQueueWatchdogTimeout setting.

My own upgrade script now runs php maintenance/update.php --quick twice – once before enabling CSP, and once after – just to be safe.

6. A Few Personal Observations

Reading through the release notes felt a bit like flipping through a well‑organized grocery list. Everything is there, but the excitement comes from the little things – the edit‑recovery banner that actually works, the CSP flag that you can toggle with a single line, the watchlist filter that finally lets you see “my own edits”.

There’s also a subtle shift toward modern PHP practices. If you’re still on an older PHP version, the upgrade will force you to move forward, which is a good thing. The new hooks feel more granular, giving extension authors the chance to intervene at just the right moment without resorting to hacky workarounds.

On the flip side, the documentation could use a bit more real‑world examples. The API section, for instance, mentions the new formatversion=2 but doesn’t show a before‑and‑after comparison. A short snippet would have saved a few minutes of trial‑and‑error for developers.

7. Bottom Line

If you run a wiki that sees regular traffic, the security hardening alone makes 1.43 worth the upgrade. Add to that the smoother editing experience and the admin‑friendly config tweaks, and you have a release that feels like a genuine step forward rather than a routine patch.

Of course, every upgrade comes with its own set of tests and backups. Take the usual precautions: clone your production database, run the update in a staging environment, and verify that your critical extensions still load. Once you’ve cleared those hurdles, the new features will start to show their value in everyday use.

In short: edit recovery that actually saves you, CSP that you can enable with a single line, and a handful of developer‑friendly hooks that make custom extensions feel less like a patchwork quilt. That’s the essence of MediaWiki 1.43.0.