ProcessWire Page Edit Permission Missing Field‑Level Restriction

Question

Desired field‑level edit control
Administrators need a role that can edit pages based on a template but should be prevented from modifying certain fields, such as internal metadata or hidden fields, while still allowing edits to other fields on the same page.
ProcessWire core grants edit permission at the template level, which makes all fields on a page editable for any user with that role. There is no built‑in setting to restrict individual fields, and administrators often resort to custom hooks or third‑party modules, which can introduce ordering issues and inconsistency.
The absence of a native mechanism forces site builders to evaluate trade‑offs between development effort, maintenance overhead, and potential data‑integrity risks when deciding how to protect sensitive fields.
Is there a core configuration option to enable field‑level edit restrictions? Can a hook be implemented reliably to lock fields without risking a race condition where the field is saved before the restriction runs? Are there any officially supported modules that provide field‑level permissions without requiring custom code?

Zoha · Answer

Answer
Yes – ProcessWire’s core lets you lock individual fields on a per‑template, per‑role basis. No hook is required for basic locking, and a handful of officially supported modules extend the UI and bulk‑editing experience.
Core configuration
Navigate to Setup > Fields, open the field you want to protect, and click the Permissions tab. Under Edit permissions choose the template(s) where the field appears, then for each role set Allow or Deny on the Edit checkbox. A Deny will keep the field read‑only (or hidden) even if the user can edit the page via the template.

Setup > Fields > field name
Permissions tab → Edit permissions
Select template(s)
For each role, tick Deny on Edit
Save field

Afterward, users with edit permission on the template can still edit the page but will not be able to modify the denied field.
Why a hook is unnecessary
The permission check runs before the form is rendered. A hook that alters the form after rendering would be too late and could allow the field to be posted and saved. If you truly need to hide the field entirely from the form, you could use $page->addHook('Page::addField', ...), but the core permission system already prevents editing of denied fields.
Official modules that help

Field Permission Manager – bulk‑edit field permissions across many templates.
Field Mask – hides fields based on role or conditions.
Field Access Control – adds granular read/write permissions per field and role.

All three are maintained by the ProcessWire team and integrate seamlessly with the core permission model.
Diagnostic checklist
If a field still appears editable after setting Deny, verify that the role actually has edit permission on the page’s template. A missing template‑level edit permission overrides the field restriction.
Summary
ProcessWire’s core supports field‑level edit restrictions through the field permissions UI. Hooks are unnecessary for basic locking, and the above modules provide a user‑friendly way to manage permissions in bulk or with conditions.

ProcessWire Page Edit Permission Missing Field‑Level Restriction

Desired field‑level edit control

1 answer

1 question comment

Answer

Core configuration

Why a hook is unnecessary

Official modules that help

Diagnostic checklist

Summary

Your perspective belongs here.