Rules
Blocking vs Warning
How Blocking and Warning severity work in ContentLatch—when publishing is prevented, when drafts still save, and how each appears in audits.
Severity controls the outcome
When a ContentLatch rule fails, severity decides what happens next.
Blocking
BlockingContentLatch · Blocking
A blocking finding prevents publication and prevents updates to already published or private content on the supported save paths until the issue is resolved.
Warning
WarningContentLatch · Warning
A warning surfaces the finding in the editor but does not block the save. Publication is allowed.
Blocking in practice
Use Blocking when non-compliant content must not go live.
- Applies to publish and private update flows in V1
- Drafts, autosaves, and revisions are not blocked
- In the block editor, Core Blocking surfaces through the editor/REST presentation with the label ContentLatch · Blocking plus the field finding
- Classic Core Blocking fails closed before persistence—it interrupts the save rather than showing an inline Classic Blocking notice
- ACF Blocking can use ACF’s inline validation (including Repeater row context)
Editors can keep working on drafts even when Blocking rules would fail on publish.
Warning in practice
Use Warning when the team should notice an issue without stopping publication.
- The editor shows ContentLatch · Warning and the related field message
- Saving and publishing remain possible
- Warnings are not merely cosmetic—they appear on validation surfaces and in audits as content that needs review
Workflow difference
| Severity | Intended workflow |
|---|---|
| Blocking | Must resolve before the relevant publish/update can proceed |
| Warning | Should review, but publication is allowed |
Audit evaluates active rules against published and private content. Blocking failures surface as content that needs attention; warnings surface as content that needs review. Audit reports findings—it does not modify content.