WordPress 7.0 Is Here. Will Your PDF Invoice Plugin Survive It?

WordPress 7.0 landed on May 20, 2026. Most of it is plumbing you will never see. But if your store emails invoices, there is a real chance the update quietly changes what those invoices look like, and you will not find out until a customer replies asking why their receipt is full of empty boxes.

Whether that happens to you comes down to one thing: where your PDFs are actually rendered.

The part of 7.0 that matters to you

Skip the release notes. Three changes can touch a document plugin.

The biggest is that PHP 7.2 and 7.3 are gone. The supported floor is now PHP 7.4, with 8.3 recommended. If your host is still serving 7.2 or 7.3, code that ran fine last week can start throwing fatal errors the moment you update core, and PDF libraries that never modernized are prime candidates.

The other two are cosmetic until they aren't. The block editor keeps moving into an iframe, which trips up plugins that inject editor styles the old way. And the admin gets a new default theme called Modern, which will expose any plugin that hardcoded its own admin colors over the top of core.

There is also a new AI Client, a central API-key screen, and PHP-only block registration. All opt-in, none of it breaks anything. File those under "interesting later."

Server-side rendering is the thing that breaks

Open the settings page of almost any WooCommerce invoice plugin and you will find DOMPDF, mPDF, or TCPDF doing the work. They take your order, run it through a PHP library, and write a file on your server. It is a reasonable design until the ground moves under it, which is exactly what a major core release does.

Three things go wrong, and 7.0 nudges all of them.

A server-rendered PDF is welded to your PHP runtime. Move the version floor and a library that has not kept pace either spits deprecation warnings or dies outright. It is also welded to your live environment, so the output depends on which fonts the server has, what your theme is doing, and which libraries happen to be loaded when the render fires. Change any of those and the document drifts. And most of these engines were built for a web that predates CSS Grid. Flexbox has sat marked "unsupported" on their issue trackers for the better part of a decade. A new admin theme does not fix that. Nothing in core will.

So the plugins most likely to hand a customer a broken invoice after the upgrade are the ones rendering on the machine that just got upgraded. That is not bad luck. It is the architecture.

Why a cloud renderer shrugs this off

Paperbolt does not render anything on your site. WordPress makes one HTTPS call to the LightningPDF cloud, Chromium renders the document there, and the file comes back. That sounds like a small distinction. It is the whole game.

Your PHP version stops mattering, because the plugin's only job is to send a request. 7.4 or 8.3, the renderer never sees it. Core and theme updates stop mattering too, because the invoice is built from your template and your data on a different machine entirely. A new admin theme changes how WordPress looks in a browser tab. It does not change the bytes of a PDF that was rendered somewhere else.

The script support comes free with the same decision. Hindi, Bengali, Tamil, Hebrew, Arabic, Thai, and the CJK languages render the way they do in Chrome, because it is Chrome's engine, not a PHP font shim. Flexbox, Grid, and real webfonts work for the same reason. WordPress 7.0 neither adds nor removes a single character of that.

Update to 7.0 and the invoice you send tomorrow is byte-for-byte the one you sent yesterday. There is nothing on your server for the upgrade to disturb.

Is Paperbolt compatible with WordPress 7.0?

Yes, and version 1.1.1 says so in the header. The download block uses the standard block-editor APIs with a server-side render callback, so the iframe move does not reach it. The settings screen scopes its styles to its own page and never touches core admin chrome, so the Modern theme has nothing to fight with. And Paperbolt already required PHP 7.4, so the dropped versions were never in play.

If you run a different plugin, upgrade in this order

Check your PHP version before you touch anything else. Sitting on 7.2 or 7.3 means moving to 7.4 or higher first, which most hosts let you do from the control panel in two clicks. Then stage the update with the WordPress Beta Tester plugin instead of betting your live store on it. Once 7.0 is on staging, generate one invoice, one packing slip, and one receipt, and actually open them. Look at the layout, the fonts, and any non-Latin text. If invoices auto-attach to order emails, push a test order through and confirm the attachment arrives and opens.

If anything looks off and your plugin renders on the server, that is your cue. The fix is not another font pack. It is moving the rendering off the box before the next core release makes the same point louder.

Paperbolt is free on WordPress.org, 100 PDFs a month, already tested up to 7.0. Prefer to skip the plugin and call the API yourself? The docs have every endpoint.