Hello JoomShaper Support Team,

We need urgent technical assistance regarding a critical issue introduced after updating to SP Page Builder 6.2.3, which is now blocking page saves across multiple sites.

This is not an isolated case and appears to affect any site updated to 6.2.3 running under ModSecurity.

After updating to SP Page Builder 6.2.3, we began experiencing a critical and reproducible failure when saving pages in the Joomla administrator. The issue affects multiple independent websites hosted on different domains, all running standard Apache + ModSecurity configurations.

The problem does not appear to be related to server misconfiguration, PHP limits, or corrupted installation. Instead, evidence from Apache and ModSecurity logs indicates that the save request payload generated by SP Page Builder exceeds PCRE limits, triggering security interception during the save process. This results in a 404 response instead of a successful page save.

The issue is fully reproducible: pages save normally while empty, but fail immediately once any SP Page Builder component is added. This strongly suggests a structural change in how JSON payloads are being generated or transmitted in version 6.2.3.

⸻

Environment

Development site: dev5.keystroke.ca Project: Balancing Whispers Joomla: 4.x Template framework: Helix Ultimate 2.2.4 Template: Atum 1.0 SP Page Builder: 6.2.3 Server: Apache + ModSecurity (Imunify360)

⸻

Problem Summary

After updating to SP Page Builder 6.2.3, we started receiving the following error when saving pages:

“Request failed with status code 404”

Key symptoms: • Saving existing pages fails with a 404 error • Newly created pages save only while empty • As soon as any component is added, saving fails • The issue is consistent and fully reproducible

⸻

Timeline / Reproduction

The issue first appeared on:

Page ID 11 – “Our Facilities” https://dev5.keystroke.ca/our-facilities

(No custom components used.)

Shortly after, all pages on the site failed to save.

We updated another site (handheldcontact.com), and the same issue appeared immediately, confirming the problem is not site-specific.

After applying ModSecurity rule exceptions at the WHM level: • Homepage (Page ID 10) can now save • All other existing pages still fail • New pages fail as soon as any component is added

This confirms the workaround is partial and unstable.

⸻

Server Log Evidence

Apache error logs show ModSecurity blocking the save request due to PCRE limits:

ModSecurity: Execution error - PCRE limits exceeded (-47) [file “/etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/013_i360_generic.conf”] [uri “/administrator/index.php”] Action: Intercepted (phase 2) Producer: ModSecurity for Apache / OWASP CRS 3.0.2

This indicates SP Page Builder is sending large JSON payloads during save operations that trigger ModSecurity false positives.

⸻

What We Already Tried (No Success) • Increased post_max_size and upload limits • Cleared Joomla cache and browser cache • Enabled and disabled URL rewriting • Confirmed the issue is browser-independent • Fully uninstalled and reinstalled SP Page Builder • Rolled back to a previous SPPB version • Installed SPPB on a separate domain (same issue occurred)

We also reviewed known forum threads:

30117 – Uninstall/reinstall workaround 42627 – “Request too large displaying 404 instead of 413”

Despite reinstalling and rolling back, the issue persists.

⸻

Business Impact • All our company websites use SP Page Builder • Most of our clients’ websites use SP Page Builder • The issue appears immediately after updating to 6.2.3 • It is not realistically solvable on standard hosting environments

This creates serious operational risk.

⸻

What We Need

We urgently need: • Confirmation whether this is a known issue in 6.2.3 • A permanent fix or official mitigation • Technical guidance on preventing large JSON save requests from triggering ModSecurity • A response from the support or development team

Supporting evidence: https://www.dropbox.com/….

Given the severity and scale of this issue, we would appreciate a prompt and direct response.

Kind regards, Carlos