​

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 ☺️

Good morning dear Friends h

What Plugin do you use to feed some of the twitter (x) threads on your WordPress site. I love to hear from you again.

Greetings ☺️

How to replace the Hero image in Twenty Twenty-Four (TT4) – and the Cover Block bug that blocks it

Hi everyone,

I'm working on a new project using the default Twenty Twenty-Four (TT4) theme and I'm trying to replace the Hero image on the front page with one of my own images from the Media Library.

However, I've run into a problem that I can't seem to solve on my own.

What I tried:

I uploaded several images to the Media Library.

I opened the Site Editor (Design → Editor) and selected the Home template.

I clicked on the Cover block (Hero area) to select it.

I tried to replace the image via the block toolbar – but instead of the expected "Replace" option, I only see "add-media".

When I click on the Media Library, nothing happens at all – it doesn't open. I also checked the three-dot menu in the block toolbar, but it only shows the standard options (copy, cut, duplicate, add before, add after, copy styles, paste styles, group, lock, rename) – no image-specific settings.

What I found out so far:

After some research, I came across a known bug in the Cover block of Twenty Twenty-Four. When the Cover block is set to use the Featured Image, critical settings – such as image resolution or "fixed background" – are hidden, and the block sometimes behaves as if no image were loaded at all. The official workaround is to:

Add a new Cover block.

Insert a temporary image (not the featured image).

Adjust the settings (e.g. resolution to "Full Size").

Save the block/template.

Then use "Replace" → "Use Featured Image".

My problem now:

I can't even get to step 2, because the Media Library doesn't open in the Site Editor when I click it. I suspect a plugin conflict (possibly LiteSpeed Cache or a security plugin blocking the JavaScript).

My questions:

Has anyone else experienced this with TT4 – the Media Library not opening in the Site Editor?

Is there another reliable way to insert a temporary image into a Cover block (e.g. drag & drop) without using the Media Library?

Which plugins are known to cause this kind of conflict in the block editor?

I'd really appreciate any hints. I'm very close to solving this, but I feel like I'm missing one final step.

Thanks a lot in advance!