Native WordPress Abilities
Listdom registers native WordPress abilities on WordPress 6.9 or newer. Older supported WordPress versions continue running Listdom without these registrations. Abilities complement, rather than rename or replace, Listdom’s listdom/v1 REST API. Listdom does not bundle an MCP server as part of this integration.
Authentication and discovery
Section titled “Authentication and discovery”Discover the registered listdom category and each ability’s current input/output schema before building an integration. The standard WordPress Abilities REST transport requires WordPress authentication, including for reads whose own permission callback permits public access. Use an authenticated session or an application password. PHP integrations must use WP_Ability::execute() so schema and permission checks run.
Native abilities do not require YBee, a Webilia connection, or Webilia Credits. An optional consumer does not grant permissions. Active add-on, licensing, feature, and per-resource permission gates still apply.
Listing discovery and management
Section titled “Listing discovery and management”| Ability | Purpose |
|---|---|
listdom/get-search-schema | Discover published search modules and supported filter parameter names. |
listdom/search-listings | Search visible listings using advertised filters and pagination. |
listdom/get-listing | Read a visible published listing. |
listdom/list-taxonomies, listdom/list-terms | Discover public listing taxonomies and terms. |
listdom/contact-listing | Send a contact notification as an authorized signed-in user, with repeat-request limits. |
listdom/create-listing, listdom/update-listing | Create listings or update declared fields with the actor’s listing permissions. |
listdom/trash-listing | Move an authorized listing to trash. |
listdom/get-image | Read image information when the actor may edit that attachment. |
Public listing reads follow AI Visibility’s public-feed and field-visibility settings. Only eligible published, visible, password-free listings are returned. Administrative diagnostics use a separate permission boundary and must not be exposed as public reads.
Read search parameter names from get-search-schema; array filter names retain their advertised [] suffix and accept array values. Reuse the returned random-order seed on later pages. Visibility-filtered searches inspect a bounded candidate set; if a page cannot be determined within 2,000 candidates, listdom_search_limit_exceeded returns no partial results. Narrow the search instead of treating it as an empty directory.
Listing updates are sparse: only supplied supported fields change. Unrelated gallery, custom attribute, add-on, and display data is preserved. Use the normal listing form for fields outside the contract. Locked listings cannot be edited through abilities, and ordinary publishing, coordinate validation, and per-listing permissions still apply.
Active Booking and Reviews integrations can register their own abilities. Discover their schemas rather than assuming installation alone enables every action. A booking response can require payment: follow its returned checkout information instead of presenting booking creation as paid confirmation. Cancellation and review submission retain their normal authorization, status, and validation rules.
Scoped settings reads and writes
Section titled “Scoped settings reads and writes”Use listdom/list-settings to discover supported domains and field policies, then listdom/get-settings to read the required keys. Core domains cover general settings, Customizer, detail pages, authentication, payments, socials, styles, AI, and API settings. Active owning add-ons contribute declared domains. Credentials are represented by configured/presence information, not exposed secrets; arbitrary code and raw configuration trees are not writable.
For a scoped listdom/update-settings call:
- Discover the exact domain and allowed fields.
- Read that domain’s values and fresh
expectedRevision. - Prepare only the intended allowlisted changes, including dependent parent/child settings when needed.
- Use
listdom/preview-settings-updateto validate without saving, obtain informed confirmation, and execute the exact approved input. - Use
listdom/verify-settings-updateto compare the requested values with fresh effective settings.
One read is limited to 20 keys and bounded output. A wildcard discovery revision cannot authorize an exact-domain write. Stale revisions require a fresh read and review. A failed save and an uncertain save are different results: never automatically retry an uncertain mutation or assume rollback occurred. Existing integrations omitting domain retain the original settings contract.
Read-only administrative diagnostics
Section titled “Read-only administrative diagnostics”The original setup abilities remain available: listdom/audit-directory-setup returns actionable setup findings, and listdom/get-dashboard-status inspects the assigned dashboard page, publication/shortcode readiness, form modules, and restrictions. Neither creates or assigns pages.
| Ability | Evidence it inspects |
|---|---|
listdom/get-search-display-configuration | Saved view or page references, skin/style, images, columns, and templates. |
listdom/inspect-listing-media | Authorized featured/gallery attachments, metadata, sizes, and local availability. |
listdom/diagnose-listing-images | Related media and saved display findings. |
listdom/diagnose-listing-visibility | Public state, query membership, and supported deterministic access rules. |
listdom/get-frontend-submission-diagnostics | Saved dashboard readiness, restrictions, guest settings, and upload limits. |
These calls require manage_options and edit access to referenced resources. For view-aware calls, supply either view_id or page_id, not both; use a returned reference when the page contains multiple saved layouts. Inspect returned limitations and pagination: bounded or incomplete evidence is not proof of absence. These reads do not render the page, make paid AI/geocoding calls, repair files, or submit forms. They cannot prove how a visitor’s browser looks or that a checkout succeeds.
Explicitly approved repairs
Section titled “Explicitly approved repairs”Display repair is limited to supported built-in Pro Grid and List views. Use listdom/get-search-display-repair-state, then the preview/update/verify search-display abilities with the fresh revision. Supported patches concern display_image, image_method, and image_fit; they do not rewrite filters, CSS, skins, or custom templates. A saved-view change affects every page using that view.
Thumbnail repair uses listdom/preview-listing-thumbnail-repair, followed by listdom/regenerate-listing-thumbnails only after approval. It creates missing registered derivatives for current featured/gallery attachments, not replacements for originals or a full-library regeneration. A request is limited to 20 attachments and five sizes; local originals must be readable and within 25 MiB and 40 megapixels. Offloaded or unavailable originals are blocked rather than reported as repaired.
WP-Cron must run for queued work. Use listdom/get-thumbnail-repair-status to inspect progress and independent file checks; listdom/cancel-thumbnail-repair stops pending work but keeps already completed files. Cancellation is itself a mutation. Do not automatically retry uncertain jobs. Configuration readback and local file verification do not replace checking the rendered directory.
For existing REST routes and frontend hooks, see API and frontend events.