Choose which browse layouts this install offers

PATCH

/admin/system/browse-views

• Local development behind nginx (port 8088 by default)

Replaces the enabled set. Requires the system.config.write capability. The change takes effect on the next request without a restart, and is recorded as an admin.system.browse_views_updated audit event.

AT LEAST ONE LAYOUT MUST STAY ENABLED. An empty array is refused with a 400 and nothing is persisted — the same shape as the last-admin invariant, and for the same reason: an install with no enabled layout has an unreachable browse page and no recovery path short of a database shell. Unknown layout names are refused too, rather than filtered out, so a typo cannot quietly save a smaller set than the operator chose.

Disabling a layout somebody is already using is safe. Every rung that can name a mode — this device’s stored choice, the account default, the coarse-pointer default — is filtered through the enabled set at resolve time, so those users land on an enabled layout instead of an empty page.

Authorizations

• cookieAuth
• bearerAuth

Request Body ^required

object

enabled

required

The browse layouts this install offers, in the switcher’s canonical order. The server reorders whatever it is sent into that order and drops duplicates, so layout order stays a frontend decision and only availability is the operator’s.

MUST NOT BE EMPTY. A write enabling nothing is refused with a 400 and nothing is persisted — an install offering no layout has an unreachable browse page, and the recovery path would be a database shell.

An install that has never configured this reads back all five. That is the shipped default expressed as the absence of a stored value, not as a seeded row.

Array<string>

>= 1 items

Allowed values: grid masonry thumbnail list feed

Example

[
  "grid",
  "list",
  "feed"
]

Responses

200

The updated enabled layouts, in canonical order

object

enabled

required

The browse layouts this install offers, in the switcher’s canonical order. The server reorders whatever it is sent into that order and drops duplicates, so layout order stays a frontend decision and only availability is the operator’s.

MUST NOT BE EMPTY. A write enabling nothing is refused with a 400 and nothing is persisted — an install offering no layout has an unreachable browse page, and the recovery path would be a database shell.

An install that has never configured this reads back all five. That is the shipped default expressed as the absence of a stored value, not as a seeded row.

Array<string>

>= 1 items

Allowed values: grid masonry thumbnail list feed

Example

[
  "grid",
  "list",
  "feed"
]

400

Malformed request

object

error

required

Human-readable error summary

string

Example

the request could not be completed

401

Authentication required, missing, or invalid

object

error

required

Human-readable error summary

string

Example

the request could not be completed

Example

{
  "error": "authentication required: sign in and retry with a valid session or API token"
}

403

Authenticated but missing required capabilities

object

error

required

Human-readable error summary

string

Example

the request could not be completed