OceanWP MCP: curated Customizer writes, per-page overrides and Ocean Extra

Which ocean_ post meta a single page can actually override

Owners looking for an OceanWP MCP that can restyle one landing page usually expect the whole OceanWP metabox to be reachable. It is not. oceanwp-set-page-overrides accepts a short list of keys the theme reads at render time: ocean_post_layout (right sidebar, left sidebar, both sidebars, full width or full screen), ocean_both_sidebars_style for the column order when both sidebars show, four breadcrumb colours, and the post-format media fields for video, quote and link posts. Everything else in the metabox, such as hiding the title bar on one page, is outside the typed surface.

Two behaviours make this safe to hand over. Every value is checked against that allowlist before anything is saved, so one bad colour or an unknown key means the post keeps all of its existing meta. And null deletes the key with delete_post_meta, which is how a page goes back to inheriting the global Customizer value. The ability refuses posts that are trashed, auto-drafts or revisions, so point it at the published page id.

Mounting a library header, top bar, footer or 404 from Ocean Extra

oceanwp-apply-library-template knows four slots and the theme mod behind each: header writes ocean_header_template, topbar writes ocean_top_bar_template, footer_widgets writes ocean_footer_widgets_template, and custom_404 writes ocean_error_page_template. The template has to be an oceanwp_library post that is published; a draft is refused with its current status named, so publish it in Ocean Extra's library first.

The header slot has the extra condition the page above mentions, but the other three behave differently: the top bar and footer templates still depend on the top bar and footer widgets being displayed at all, which are separate allowlisted settings (ocean_top_bar and ocean_footer_widgets). When a mounted template does not render, read those display switches with oceanwp-get-settings before assuming the template is wrong.

Why oceanwp-list-modules can still say false right after an enable

Ocean Extra's module switches live in the oceanwp_modules option, and oceanwp-enable-module writes the slug into it. The enabled flag that oceanwp-list-modules reports is not read from that option. It checks whether the module's PHP class is loaded in the current request, and Ocean Extra only loads a module's bootstrap when the page is built. So a list call in the same request as the enable can report false even though the write succeeded. Ask the agent to list modules again on a fresh call, or load the front end, before treating it as a failure.

Module toggles are serialised under their own lock, separate from the theme mods lock that Customizer, header, typography and WooCommerce writes share. Two agents enabling Sticky Header and changing the header height at the same moment cannot overwrite each other's row.

OceanWP's WooCommerce switches and the checkout you should test after them

oceanwp-set-woo-features covers the shop toggles owners change most: the off-canvas filter sidebar, distraction-free cart and checkout, quick view, the floating add-to-cart bar, the hover image swap, AJAX add to cart, the menu cart style and the mobile mini cart. It returns oceanwp_requires_woocommerce when the store plugin is inactive. Distraction-free checkout strips the header and footer from the checkout page, so after switching it on, place a test order on staging with each payment method you offer and confirm trust badges or notices your theme hooks added are still visible.

What an OceanWP agent may do under each safety profile

None of the module's abilities is classed destructive, so Production Safe permits ordinary writes for a user with manage_options, subject to the enabled abilities and any additional approval rules, and on Read Only the agent can still list panels, modules, library items and hooks and read every allowlisted setting and override. That makes a Read Only audit a reasonable first connection on a live store. Every write is recorded so it can be put back from the change ledger, as the limits above describe.

Hooks are the exception. oceanwp-list-hooks names filters such as ocean_display_page_header or ocean_display_footer_widgets, but attaching one needs execute-php, which is a critical ability: it runs only on Developer Full Access, only with confirm, and a snippet is not reversed by the ledger the way a theme mod write is. Prefer a page override or a Customizer switch when one exists. The OceanWP reference lists every parameter.

• "Read only: which pages override ocean_post_layout, and to what?"
• "Mount our published 'Black Friday bar' library post as the top bar and confirm ocean_top_bar is switched on."
• "Turn on quick view and AJAX add to cart, then tell me what changed and what was already set."