Using option page values

Pro

Option page values work everywhere field values do. Because they belong to the site rather than to a post, every tool finds them under Site.

In the block editor

Dynamic tags list option pages under the Site group, so you can bind a paragraph in the footer template to the support phone number. In VX Script the path is the page key, then the field key:

@site(site_settings.support_phone)

Previewing that value in the editor requires the page's Capability. Visitors see the published value regardless.

In Bricks

Option page fields appear in the Bricks dynamic data picker under the VX site group. See Bricks dynamic tags.

In PHP

<?php
$settings = \VxFramework\Option_Page::get( 'site_settings' );
if ( $settings ) {
    echo esc_html( $settings->field( 'support_phone' )->string() );
}

The same typed accessors as posts apply. See Reading values in PHP.

Over the REST API

The VX REST module doesn't expose option pages. To publish site-wide values to an app, read them in PHP and add them to a response yourself, or copy them to a post the API does expose.

Technical details for LLMs

• Values: vx-framework/get-option-page-values and vx-framework/set-option-page-values (the page's capability isn't what gates abilities; abilities require manage_options).
• VX Script group site: @site(<page_key>.<field_key>[.<sub_key>]). Site core paths under the same group: name, tagline, url, admin_email, language.
• \VxFramework\get() reads VX configuration, not option page values. Don't use it for values.
• Raw storage: get_option( 'vx_option_values:<page_key>' ). Prefer the typed accessor; the raw blob isn't a public contract.