If your page was built with Elementor, Divi, Beaver Builder, or Avada, and you asked an agent to change a paragraph on it, here is what happened before version 1.7.4. The agent called update page. The plugin wrote the new text into post_content. WordPress returned success. The agent told you it was done. You loaded the page and it was word for word what it had been.
Nothing was broken and nothing was lost. The write really did happen. It just happened somewhere nobody looks.
Where the content actually lives
A page builder does not use post_content as its source of truth. Elementor keeps its layout in a post meta field called _elementor_data and renders the page from that. Divi flags a page with et_pb_use_builder and works from its own shortcode structure. Beaver Builder uses _fl_builder_data. Avada uses fusion_builder_status. On a page owned by one of these, post_content is a leftover: sometimes a stale copy, sometimes a stub, sometimes empty. The front end never reads it.
So a write to post_content on such a page is a real write to a field with no readers. Every layer reported the truth about its own step. WordPress was asked to save content and it saved content. The plugin was told the save succeeded and it recorded a success. The agent read a success and reported one. The only thing that was false was the conclusion the whole chain added up to, which was that your page had changed.
The same shape as the 1.7.3 bug
We shipped a hotfix a few days ago for a failure with exactly this structure. On sites with a persistent object cache, turning off read-only mode or the high-risk WooCommerce lock could fail to take effect while the activity log recorded the change as done. That one is written up in a switch that would not turn off, and the sentence that mattered there applies here without changing a word: the entry described the request rather than the result.
Two different bugs, one shared failure mode. The system did something, then reported on what it had been asked to do instead of on what came of it. That is worse than an error, because an error tells you to go and look. A success tells you to stop looking, and you find out days later when somebody mentions the page still says the old price.
An audit log you can trust is not much use if the rows in it are describing intentions.
What it does now
Five abilities check for builder ownership before they write: update post, update page, update content item, replace in post, and restore revision. If the target belongs to one of the four builders, the call is refused with a 409 and the error names the builder that owns the page. Not a generic permission failure, not a silent success. A refusal that tells you Elementor owns this page, which is the sentence that lets you or your agent do something useful next.
Replace sitewide, which is new in this release, takes the same information and does the sensible thing with it. Rather than refusing the whole run because one post in a batch of forty belongs to a builder, it skips that post and counts it under skipped_builder_owned. You get the count in the result, so a sweep that touched 38 of 40 posts tells you it touched 38, and why the other two were left.
This is the same principle behind read-only mode and the high-risk lock: a governed system is allowed to say no, and it owes you a reason when it does.
What this is not
It is not Elementor, Divi, or Beaver Builder support. The plugin gained no ability to read or edit a builder’s layout. It cannot open _elementor_data and change a heading, and it is not going to pretend it can. The guard’s entire job is to stop a write that would have done nothing. It converts a false success into an honest refusal, which is a smaller claim than it might sound like and a real improvement over what was there before.
Avada is the one exception, and only partly. It has two abilities of its own in 1.7.4, one that reads the raw Fusion Builder markup and one that replaces literal text while refusing anything that would touch the shortcode tree. That is text replacement on the margins of a structure, not layout editing, and it exists because Fusion Builder’s markup is shortcode based and inspectable in a way the others are not.
OptimizePress is not covered. It is a real page builder with real users and the guard does not detect it, so a write to an OptimizePress page still behaves the way all four of the others did before this release. The reason is unglamorous: OptimizePress is not distributed on the wordpress.org SVN repository, so there was no public source to read to confirm which meta key actually marks a page as builder owned. Guessing at that marker would mean either failing to catch pages that need catching or refusing writes on pages that were fine. Neither is acceptable in a guard whose only job is to be right about ownership. It is carried to 1.7.5, and until then it is a gap we know about rather than one you have to discover.
Whether you need this
If no page builder runs on your site, this changes nothing for you. If one of the four does, and you have ever pointed an agent at content, it is worth taking the update just to find out whether any of the edits you thought landed actually did.
Everything else in 1.7.4 is in the release post. The full history is on the changelog, and the controls that decide what an agent can reach in the first place are on security and in safety controls.