Choose WordPress editor controls by separating shared content, local content and protected layout. Use a synced pattern only when changes should reach its other uses. Decide which editors may alter structure, and demonstrate the resulting experience with their actual roles before handing the site over. Reuse and locking solve different editorial problems.
A common requirement is easy to state: staff should update words and photographs without accidentally changing a page’s structure. Another is more demanding: a contact section should remain consistent across the site while an individual page keeps its own introductory copy. Write these as separate acceptance requirements before choosing editor controls.
The examples here come from WordPress’s synced-pattern and block-locking documentation. They describe core mechanisms, not proof that a particular theme, plugin combination or user role is configured correctly. The original exercise below is a proposed test in a separate copy, not a claim of a completed Spout handover.
Which content should remain shared across pages?
Start by listing repeated sections and asking who owns their wording. A contact instruction, standard notice or business-hours section may need a common source. A project summary or event-specific introduction may look similar but require independent editing. Visual resemblance alone is not a reason to synchronise the content.
WordPress’s synced-pattern guide explains the consequence. Editing a synced pattern changes it wherever it is used. Ask the content owner to identify which other pages should change before editing a shared section. If the expected propagation is unclear, stop and inspect its uses in the test copy.
Detaching a synced pattern allows local editing without changing the saved pattern. That makes detachment a deliberate ownership decision: the page takes responsibility for its independent copy. Record why that independence is needed, particularly if the detached section contains instructions that will later need updating.
WordPress 6.3 renamed Reusable Blocks to Patterns. Use the terminology appropriate to the installed version when writing handover notes. An editor following an older guide may search for a name that no longer appears in the interface; explain the relationship rather than inventing a second content system.
The pattern creation workflow includes enabling the Synced option. Have the editor show the selected option and the result on sample pages. Saving a reusable-looking arrangement is not, by itself, evidence that its content will update across every instance. Review the chosen reuse behaviour alongside the business requirement.
How do layout locks differ from content ownership?
A section can be shared without its structure being protected. Conversely, a locally editable section may have a protected layout. Treat the questions separately: who owns this text, and what structural changes should the editor be able to make? Write both answers in the handover worksheet.
The Block Locking API documentation describes the controls. The block-locking interface can prevent moving or removing blocks. That is useful when a specific action should be unavailable, but the visible presence of a lock does not explain every permission around the content.
Editors can unlock default locks applied by theme authors. Ask the developer to explain the proposed role configuration instead of describing an ordinary layout lock as a security boundary. The site still needs appropriate account permissions and an agreed route for approved structural changes.
Content-only editing hides design tools while preserving content editing. Content-only containers prevent inserting additional child blocks. This may suit an editorial role that needs to replace an image and revise a paragraph inside an established section. Demonstrate those exact tasks, because a general promise of an “easy editor” is too vague to assess.
Developers can filter the permissions for locking blocks. Keep that custom configuration in the technical handover where it can be reviewed and maintained. Do not imply that a capability described in the handbook has automatically been installed on the site merely because the underlying API exists.
| Editorial requirement | Mechanism to investigate | Proposed acceptance observation |
|---|---|---|
| Standard wording changes across pages | Synced pattern | Sample instances display the revised wording |
| One page needs independent wording | Detachment where allowed | Other instances remain unchanged |
| Editor must keep a block in position | Movement lock | Moving that block is unavailable for the tested role |
| Staff should change content inside a fixed composition | Content-only editing | Intended text and media remain editable |
| Only a designated role changes locks | Permission configuration | Ordinary and authorised roles behave as specified |
Use the table to request evidence, not to label a site secure or ready. The suitable mechanism depends on the installed version, theme and editorial workflow. A configuration that prevents an expected task is also a handover defect, even if it preserves the visual layout.
What should an editor do when a pattern needs an exception?
First decide whether the change belongs everywhere. If a standard contact instruction is wrong, a local workaround may conceal the problem while leaving other pages inaccurate. If a particular service needs different wording, forcing that change into the shared source may damage otherwise correct pages. Resolve the editorial scope before editing.
A locked synced pattern may not offer the detach option. Include the appropriate escalation route in the handover instead of telling staff to work around controls they do not understand. Name the role that can review the exception and the evidence they need, such as the page and the intended difference.
Keep structural requests distinguishable from content corrections. Replacing an image with another approved photograph may be routine editorial work. Introducing another column changes the composition and deserves a different review. The purpose of curation is to make those responsibilities legible while leaving normal publishing tasks usable.
Original two-page editor acceptance exercise
Prepare fictional pages called Workshop and Consultation in a separate test copy. Add a proposed shared contact section to both, and independent introductory content to each. Record the intended ownership of every section before configuring the controls. Use non-sensitive sample wording and approved sample media.
Ask the designated editor to change the shared contact instruction. Save the change and inspect both pages. Record which sections changed and whether that matches the intended scope. A screenshot of the editor alone is insufficient: the acceptance question concerns the displayed result on each destination.
Next, propose a local exception for Workshop. Ask the editor to follow the documented route for that exception. Observe whether detachment is available under the chosen controls and what happens to Consultation afterwards. If the route needs another role, record that dependency clearly rather than silently switching to an administrator account.
Finally, ask the ordinary editor to revise the introductory text, replace its sample photograph and attempt the structural action intended to be restricted. Record allowed and unavailable actions separately. Review the result with the content owner and developer, leaving any mismatch unresolved until the configuration or requirement is corrected.
For the wider project, see WordPress services and website development. Get started with the sections editors need to change and the shared content they must maintain.
By Spout Team. AI-assisted drafting by Codex using the linked WordPress documentation. No installed configuration, security certification or completed customer test is claimed.