# View Configuration Reference (Block Editor Handbook) > [!question] Lingering Questions > - How do URL state (search, page) and saved user preferences interact once both can influence the same view? > - Does the editor report anywhere when it silently drops an unregistered Quick Edit field, or is that failure mode invisible? > - What's the actual precedence order when Core defaults, layout overrides, sidebar presets, and user changes all touch the same property? > [!tip] Article Ideas > - "Locked isn't protected" — a short piece on why `isLocked` (a DataViews UI constraint) keeps getting read as a security control, using this reference as the primary case. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Server Defaults and Active Navigation State Need Separate Owners|Server defaults and navigation state need separate owners]] — this note's own permanent candidate > [!info] Vocabulary > - **View configuration** — server-provided settings (`default_view`, `default_layouts`, `view_list`, `form`) that seed a DataViews-powered admin screen for one entity. > - **Locked filter** — a view filter with `isLocked: true` that a user can't remove through the interface; a UI constraint, not an authorization control. > - **Member identity** — the stable `slug` (view_list) or `id` (form fields) a patch uses to merge into an existing array without duplicating entries. ## Metadata - Source: [[3. Resources/Readwise/Articles/View Configuration Reference – Block Editor Handbook Developer.WordPress.org]] - Category: Articles (WordPress Developer Resources reference page) ## Author's thesis (Adler Q1+Q2) WordPress Developer Resources documents the server-side configuration contract that DataViews-powered admin screens (Pages, Templates, Template Parts, Patterns) consume for a given entity. In detail: an entity's `kind`+`name` selects a lowercased dynamic filter (`get_entity_view_config_{kind}_{name}`); the result exposes through `/wp/v2/view-config`; and the schema separates the initial view, available layouts, sidebar presets, and the Quick Edit form into four distinct top-level keys. ## Key arguments (≤3) 1. Configuration is entity-scoped, not global — every property belongs to one `kind`/`name` pair, reached through a dynamically named filter. 2. Two state categories stay outside server configuration entirely: `search` and `page` are owned by the URL/editor, not the server filter. 3. Form fields render only when already registered for the entity — configuration can select and order fields, but it can't create them; unregistered entries are dropped silently. ## Claim atoms ### URL state stays outside server configuration > [!quote] ID:rw_01kz6m7ak0t181zejr1m19jndx_h1 > There are two properties from the DataViews API that cannot be configured via the server filter: search and page. Located in the DataViews view-object note immediately before the `default_view` property table. Matters because it draws a hard line between server-provided defaults and the active navigation state the editor and URL jointly own. **Tags**: #xref ### Locked filters constrain view customization, not access > [!quote] ID:rw_01kz6m7ak0t181zejr1m19jndx_h2 > A filter with isLocked set cannot be removed by the user. Located in the `default_view.filters` property. This is an interaction constraint only — the reference never calls it an authorization control, and reading it that way is the most likely misuse. **Tags**: #xref #articleseed ### Registered fields determine rendered form entries > [!quote] ID:rw_01kz6m7ak0t181zejr1m19jndx_h3 > Only registered fields are rendered: a form entry whose field is not registered for the entity is dropped by the editor. Located immediately before the final Quick Edit form example. The clearest compatibility prerequisite in the whole reference, and the first thing to check when a configured field silently disappears. **Tags**: #xref #articleseed ## Permanent candidates - **Server defaults and active navigation state need separate owners** (from H1) — generalizes past DataViews to any client/server config split. Promoted below. - **Stable identities make configuration patches mergeable** (from H2, the `slug`/`id` merge-key pattern) — generalizes to any system where independently-authored patches must combine without collision. Promoted below. ## Processing checklist - [x] Three Literature atoms have claim headers, exact captured quotes, context. - [x] Two Permanent candidates identified and promoted. - [x] Only source-supplied links retained. - [ ] Runtime verification against a pinned WordPress build remains outstanding (source-read evidence only). ## Links - [[3. Resources/MOCs/Open Source Governance MOC]] — a documented server contract for a shared admin surface is a compatibility-governance artifact, not just an API reference