β
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 βΊοΈ