Upgrade Wagtail to 7.4 and install Wagtail AI

[JakubMastalerz]

Link to Ticket

Wagtail 7.4 Upgrade

Changes:

Upgraded Wagtail to 7.4.0

• No direct code changes related to upgrade considerations

Packages

• Upgraded all python packages, except Django to newest versions
• Upgraded node packages with the following exceptions: Skipped (major-only): copy-webpack-plugin 13→14, cssnano 7→8, eslint 8→10, eslint-webpack-plugin 5→6, postcss-custom-properties 14→15,
  sass-loader 16→17, stylelint 16→17, stylelint-config-torchbox 4→5, typescript 5→6, webpack-cli 6→7.

Wagtail AI

• Installed wagtail-ai

Additional

• Switched Debian from Bookworm to Trixie

[damwaingames]

All of the major versions you held back are bumpable, and don't require ridiculous amounts of code to implement. I have separately sent you some examples of upgrades where I have bumped them.

[damwaingames]

You can bump these and with a rework of the webpack config, drop dependence on url-loader and file-loader

[damwaingames]

When I pointed you at the sue-ryder commits, it turns out I'd bundled the actual fix into the same commit as a pile of workarounds ("optimizations to build process"), so there was genuinely no way for you to tell what was load-bearing and what was noise. You copied the Dockerfile split, the most visible change, totally reasonable, but that was never the thing that fixed it.

What was actually wrong: Tailwind 4 auto-detects which files to scan for class names, starting from the current working directory. Our Docker frontend stage has no WORKDIR, so cwd is / — and Tailwind cheerfully tried to scan the entire container filesystem (/usr, /var, the lot). That scan runs in native Rust (lightningcss/oxide), off the JS heap — which is exactly why bumping --max-old-space-size did nothing: there was no JS heap limit to raise, the memory was all native. It'd churn for ~11 minutes, then get OOM-killed (and take OrbStack down with it).

Locally it was always fine, because there cwd is the project root, which is bounded (node_modules and .gitignore'd dirs are skipped).

Why the Dockerfile split didn't fix it: the split only stops the dev image from running webpack. The production build still runs npm run build:prod, and still scanned /. It's a good change — smaller image, leaner dev builds, keep it — it just wasn't the fix.

The actual fix is one block in main.scss:

  @import 'tailwindcss' source(none);   // stop the cwd/filesystem auto-scan
  @config '../../../tailwind.config.js';
  @source '../../**/*.{py,html}';
  @source '../**/*.{js,ts,tsx,vue}';

source(none) turns off automatic detection; @source says exactly where to look. Docker frontend build went from 651s + OOM to ~3 seconds. It's on support/wagtail-74 (commit 89b3660).

How I pinned it: rather than keep guessing, I instrumented the build and pointed Tailwind's file scanner at /tbx vs /. /tbx found 4,500 class candidates in 155ms; / never finished. That's when it clicked.

Leaning on a working reference that I pointed you at was a good instinct, the lesson (that I re-learned too) is that when a "fix" is a pile of commits, the real cause can hide inside it, and it's worth instrumenting to find the root before copying workarounds. Sorry again for the detour, you chased it exactly the way I told you to.