Can’t Update Larger Posts.

When I try to edit a save a larger post, I get an “updating failed” message. This only occurs when the plugin is active. Following is the error message, and some debugging information from Copilot with a possible fix, saying:

“Your post is large (your earlier request showed Content-Length: 80781), and the plugin’s HTML parser is extremely memory-inefficient.”

{
“code”: “internal_server_error”,
“message”: “

There has been a critical error on this website.<\/p>

Learn more about troubleshooting WordPress.<\/a><\/p>”,
“data”: {
“status”: 500,
“error”: {
“type”: 1,
“message”: “Allowed memory size of 134217728 bytes exhausted (tried to allocate 2097160 bytes)”,
“file”: “\/home\/vb_dev1\/apps\/vb_dev1\/wp-content\/plugins\/seo-automated-link-building\/vendor\/friedolinfoerder\/html-changer\/src\/HtmlChanger.php”,
“line”: 196
}
},
“additional_errors”: []
}

Alright — now we can finally open the exact file, look at line 196, and apply the correct fix.
And thanks to your tab context, I know you’re currently viewing:

Edit Post — WordPress admin
https://dev1.vbriefings.org/wp-admin/post.php?post=20081&action=edit

So I’ll keep the explanation tightly focused on what’s actually breaking your REST API save. ✅ The fatal error is inside this file

wp-content/plugins/seo-automated-link-building/
    vendor/friedolinfoerder/html-changer/src/HtmlChanger.php

At line 196, the plugin is trying to load your entire post content into a DOM parser.
Your post is large, and the parser is memory‑inefficient, so PHP crashes with:

Allowed memory size exhausted

This is exactly why Gutenberg shows “Updating failed.” ⭐ Step 1 — Open the file

Open:

wp-content/plugins/seo-automated-link-building/vendor/friedolinfoerder/html-changer/src/HtmlChanger.php

Scroll to line 196.

You will see something very close to one of these patterns: Pattern A — DOMDocument loadHTML

$dom = new DOMDocument();
$dom->loadHTML($html);

Pattern B — HtmlChanger load

$this->dom->loadHTML($content);

Pattern C — preg_replace_callback with DOM parsing inside

preg_replace_callback(..., function($matches) {
    $dom = new DOMDocument();
    $dom->loadHTML($matches[0]);
});

All of these will explode memory on large posts. ⭐ Step 2 — Apply the safe fix (prevents memory exhaustion)

Replace the DOM load call with a memory‑safe version. ✔ Fix Version (drop invalid markup, suppress warnings, reduce memory load)

libxml_use_internal_errors(true);

$dom = new DOMDocument();

// Add UTF‑8 header to reduce memory spikes
$html = '<?xml encoding="utf-8" ?>' . $html;

// Load HTML in a memory‑safe way
$dom->loadHTML(
    $html,
    LIBXML_HTML_NOIMPLIED | LIBXML_HTML_NODEFDTD | LIBXML_COMPACT | LIBXML_NOBLANKS
);

libxml_clear_errors();

Why this works

• libxml_use_internal_errors(true) prevents libxml from trying to “fix” malformed HTML — which is what causes the memory explosion.
• LIBXML_COMPACT reduces memory usage by ~30%.
• LIBXML_NOBLANKS removes whitespace nodes (huge memory saver).
• Adding the XML header prevents encoding‑related memory spikes.
• This keeps the plugin functional without crashing REST API saves.

⭐ Step 3 — Add a guard to skip huge posts (optional but recommended)

Right above the DOM load, add:

if (strlen($html) > 50000) {
    // Skip DOM parsing for large posts to prevent memory exhaustion
    return $html;
}

Your post is ~80 KB — this guard prevents the plugin from trying to parse it at all.

This is the safest long‑term fix. ⭐ Step 4 — Clear caches

Because you’re using Cloudflare Super Page Cache:

1. Clear Cloudflare cache
2. Clear WP Super Page Cache
3. Reload the editor
4. Save again

🎯 If you want, I can show you the exact patch for your exact file

Just paste lines 180–220 of:

HtmlChanger.php

I’ll rewrite the exact block with:

• the safe DOM loader
• the large‑post guard
• the correct libxml flags
• a drop‑in replacement that won’t break the plugin

You’re extremely close — one small patch and your editor will stop throwing “Updating failed” forever.