​

Hey everyone,

I'm setting up a fresh WordPress site with the Twenty Twenty-Five theme and I'm stuck on publishing a page. Hoping someone here has run into this before and can point me in the right direction.

The setup:

Fresh WordPress install, Twenty Twenty-Five theme

Creating a new page, selecting a pattern (following the official tutorial)

Clicking "Publish" gives me:

Publishing failed. Could not update post in the database.

Are you ready to publish? Double-check your settings before publishing.

In the browser console (F12 → Network), the actual culprit is an HTTP 500 Internal Server Error.

Affected URL (anonymized): https://my-site.com/wp-admin/post.php?post=XXX&action=edit

What I've already tried / ruled out:

Permalinks reset (Settings → Permalinks → "Post name" → save). No change.

All plugins disabled temporarily. Error persists – so it's not a plugin conflict.

Site Health: No critical issues, only 5 "recommended improvements" (inactive plugins/themes, missing opcode cache, no page cache detected, server response time OK). The REST API is not flagged as broken there.

It's a brand-new, empty page using a default pattern – no legacy content, nothing exotic.

My suspicion:

Since everything on the WordPress side looks clean, I'm leaning toward a server-side issue. The 500 hits exactly when the editor tries to write the page to the database via the REST API (/wp-json/...).

Questions for the hive mind:

Has anyone seen this behavior with Twenty Twenty-Five (or Block Editor + patterns in general)? What was the root cause?

Which server-side settings should I check first? I'm thinking:

PHP error log / debug.log

Firewall / ModSecurity / WAF blocking POST requests to /wp-json/

Cloudflare (if in front) – Bot Fight Mode / security rules

WP_MEMORY_LIMIT / max_execution_time

Database charset (collation) – utf8mb4 vs. utf8

Is there a way to export the Site Health report (e.g. as a file) to hand off to the host/admin? I've only found the dashboard view so far.

Any known workaround to publish the page in the meantime (e.g. Classic Editor as a stopgap)? I know that's just a band-aid, not a fix.

I've already reached out to the backend/server admin to check logs and the firewall. But if anyone here has hit this exact error, I'd love to hear what solved it.

Thanks in advance!

UPDATE: Blank page also fails with 500 – so it's not the pattern

Hey everyone, thanks for the quick replies – all three were genuinely helpful. Quick update since a few people asked for follow-up:

What I tested based on your suggestions:

Blank-page test (u/CombinationParty7358 – the first reply): Tried publishing a completely empty page, no pattern, no content. Same 500 error. So it's not weird Unicode characters in the pattern – it's something more fundamental in the write path. Good call, that narrowed it down a lot.

debug.log before ModSecurity (u/Jealous-Machine-5192 Took your advice and prioritized the PHP log over the ModSec rabbit hole. I've asked the server admin to pull wp-content/debug.log and the PHP error log around the timestamp of the failed publish. Will update once I have the output.

DB charset (u/ – answer b): This is now my top suspect given the blank-page result. Asked the admin to verify:

define('DB_CHARSET', 'utf8mb4'); in wp-config.php

tables actually on utf8mb4_general_ci / utf8mb4_unicode_ci (not just utf8)

Will report back if that's the culprit – your "exact same thing last month" story is very much on my mind.

Site Health export: Found it – Tools → Site Health → Info gives the raw dump to copy. No export button, as you said. Thanks for the pointer.

Classic Editor workaround: Keeping it in my back pocket. If we need the page live short-term, I'll activate it as a stopgap – but I'd rather fix the real cause first.

Current status: Waiting on the server admin's log output. The blank-page result makes me lean even more toward a server-side write/permission/DB issue rather than anything content-related. Will post the final solution here once we've nailed it – so the next person with this error has a reference.

Thanks again, this sub is great.

Update:title: [Update] My "500 on every publish" wasn't a DB-schema issue after all — it was a MySQL tmpdir problem on the server

A while back I posted here asking whether a DB-level fix (SQL) for a 500-on-every-publish error was legitimate, or whether I'd just be masking a deeper issue. Got some great input — here's the follow-up, because the answer turned out to be neither of the things I expected.

Original problem:

Fresh WP install, Twenty Twenty-Five theme

New page + pattern → "Publishing failed. Could not update post in the database."

Console: HTTP 500 on the REST API call

A completely blank page also failed ← the key data point

Permalinks reset, all plugins disabled → no change

The DB suspects (from this thread and others):

wp_posts.ID missing AUTO_INCREMENT

Charset mismatch (utf8 vs utf8mb4)

What it actually was: The server admin found this in the MySQL error log:

text Can't create/write to file '/var/tmp/mysql.QTwenq/MLut5EBo' (OS errno 2 - No such file or directory) MySQL couldn't create a temp file for the UPDATE query because the tmpdir path was missing / not writable. That's why every write failed — including a blank page. Neither AUTO_INCREMENT nor charset had anything to do with it.

The frustrating part: after the first tmpdir fix, the error became intermittent — sometimes publishing worked, sometimes it didn't. Still chasing that down (checking tmpdir persistence, cleanup processes, and PHP resources like memory_limit / max_execution_time).

The "-2" URLs (/345-2/, /123-2/) and the leftover drafts? Normal WordPress behavior — they actually prove writes were partially succeeding. The DB was never fully blocked, just flaky.

My takeaway for anyone hitting "500 on every write":

Check the server logs first (MySQL error log, PHP error log) — before touching DB schema or plugins. The tmpdir error was sitting there the whole time; I just didn't have access.

A DB-schema "fix" would have masked the real problem here, not solved it. So my original question was the right one to ask — but the answer was "neither: it's infrastructure."

If it's intermittent, think resource/timing issue (disk space, permissions, timeouts), not a structural defect.

Will post a final update once the intermittent failures are fully gone. Thanks again to everyone who pushed me toward the logs instead of guessing.

Greetings ☺️