WordPress 7.1 Mary Lou arrived on August 19, 2026, and most coverage lists the editor features: a Playlist block, a Tabs block, and Notes that support rich text and @mentions. Those matter to whoever builds the pages. This post covers what matters to whoever runs the server: what WordPress.org currently recommends for PHP and databases, how the new browser-side image processing changes server load (and where it doesn’t), and a speculative loading setting that hosts can now control. The facts below come from the official 7.1 announcement, the core team’s client-side media post, and WordPress.org’s requirements page.
Table of Contents
WordPress 7.1 Mary Lou Requirements: PHP and Database Versions
The 7.1 announcement doesn’t list new minimum versions, so the place to check is WordPress.org’s requirements page. It recommends PHP 8.3 or greater, and MariaDB 10.11 or greater or MySQL 8.0 or greater. PHP 7.4 and MySQL 5.5.5 still appear on that page, but only for legacy environments, and it warns that those versions have reached end of life. The page doesn’t name a WordPress release, so treat it as the current guidance for any 7.x site rather than a rule specific to 7.1.
In practice, if your hosting account still runs PHP 7.4 or older, upgrading PHP matters more than the WordPress update itself, because an end-of-life PHP version no longer receives security fixes. Many hosting control panels show the active PHP version on the account dashboard, and switching it is often a dropdown choice. Test on a staging copy first if the site uses older plugins, since a plugin written for an older PHP version can break on a newer one. Our guide to WordPress 7.1 plugin compatibility covers the plugin side.
Client-Side Image Processing: Less Server Work, With Limits
The biggest hosting-relevant change in WordPress 7.1 Mary Lou is that image work moves into the browser. According to the core developer post, compression, resizing, cropping, format conversion, rotation and generation of every registered thumbnail size now run in the editor’s browser, using wasm-vips (the libvips image library compiled to WebAssembly) inside a Web Worker. The browser then uploads the finished files. The feature is on by default in supporting browsers, and plugins can switch it off with the wp_client_side_media_processing_enabled filter.
The server-side benefit is real but conditional. The developer post says server CPU and memory use should drop, and PHP memory-limit failures during image processing should become less common. But the full pipeline needs a Chromium-based browser (Chrome or Edge 137 or newer), so Firefox and Safari fall back to the existing server-side path that uses GD or Imagick. The fallback also applies when a device fails its checks: more than 2 GB of device memory, at least two CPU cores, a network that isn’t flagged as slow or Save-Data, and a Content Security Policy that allows blob: workers.
So a site where everyone uploads from Chrome or Edge may see less image-processing load, while a mixed-browser team gets a mix of both paths. Because the server-side path remains the fallback, don’t remove GD or Imagick. The developer post also notes one trade-off: uploads carry more data, because the browser sends the original file plus every resized version. That is worth knowing before a large bulk import over a slow connection.
The same release changes which formats arrive. Per the developer post, AVIF uploads work even when the host’s server lacks AVIF support, because the browser does the processing, and iPhone HEIC photos are decoded in the browser and uploaded as JPEG, with the original kept as a companion file. UltraHDR JPEGs with HDR gain maps are supported too. The announcement also describes an opt-in conversion of animated GIFs to video, which typically produces smaller files; Firefox uploads the original GIF unchanged.
Speculative Loading Defaults and Your Bandwidth
Speculative loading is WordPress’s prefetching feature: it fetches a page a visitor is likely to open next so it appears faster. In 7.1, according to the announcement, its defaults can be set through environment variables or constants without a plugin, which puts that control in the hands of hosts and developers. Every prefetch is a real request to your server, so on a plan with a transfer allowance or limited CPU it is worth knowing the setting exists. Your host may already have configured it, so ask how it is set on your plan.
Other WordPress 7.1 Mary Lou Changes Worth a Staging Test
The post editor is now fully iframed for all themes, matching how the Site Editor already worked. An older or heavily customized theme that wasn’t built for that isolation can show CSS conflicts, so test the editor on a staging copy before updating the live site. The Media Library now defaults to infinite scrolling, with a per-user option to return to pagination; on a library with several thousand images, check that browsing still feels responsive. The SVG Icon API is now public, letting developers register custom icon collections and icons, which is separate from uploading SVG files to the media library.
Preparing Your Server for WordPress 7.1 Mary Lou
A short checklist before and after the update:
- Check your PHP version in your hosting control panel and compare it with the WordPress.org requirements page.
- Back up the site and test the update on a staging copy, including the post editor and the Media Library.
- Keep GD or Imagick installed on the server, because Firefox, Safari and low-spec devices still use the server-side path.
- Ask your host how speculative loading is configured on your plan.
- Stay on the latest 7.1 point release; our post on the critical CVE-2026-87902 patch explains why that matters.
If you are choosing a host for a WordPress site, our WordPress hosting page lists the plans.
Key Takeaways on WordPress 7.1 Mary Lou
- WordPress 7.1 Mary Lou shipped on August 19, 2026, and its server-side changes matter as much as the new blocks.
- WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or MySQL 8.0 or greater; PHP 7.4 is listed only as a legacy, end-of-life version.
- Client-side image processing in WordPress 7.1 Mary Lou can reduce server work, but only in supporting browsers; others fall back to GD or Imagick.
- Uploads carry the original plus every resized image, so bulk imports send more data.
- Speculative loading defaults can now be set by hosts without a plugin; ask your host how it is configured.