Supported extension points and compatibility rules

A supported POM extension uses WordPress APIs and the helpers, hooks, merge tags, shortcodes, or commands documented in this chapter. A function merely being callable does not make every internal argument or storage structure public.

Choose the extension boundary

Use, in order of preference:

1. a documented POM helper for a POM-specific presentation decision;
2. a WordPress action or filter for normal platform behavior;
3. a shortcode for reusable code-owned output inside supported template content;
4. standard WordPress registration APIs for plugin-owned content types and metadata.

Do not require files from the theme, instantiate undocumented classes, edit generated assets, or write directly to POM settings storage.

Load after dependencies

Register integrations from a normal WordPress hook and guard optional functions:

add_action(
    'init',
    static function (): void {
        if ( ! function_exists( 'pom_get_icon' ) ) {
            return;
        }

        // Register integration behavior.
    }
);

For WooCommerce or another optional product, check both POM's semantic detection helper and the precise third-party class or function you will call.

Own identifiers and fallbacks

Prefix plugin-owned post types, taxonomies, metadata, shortcodes, cache keys, REST routes, and script handles. Never reuse a POM identifier to replace its owner.

Define what happens when POM Theme is inactive or a feature is disabled. A neutral WordPress rendering, an unavailable message, or no output is safer than a fatal error.

Compatibility review

Before release, verify the integration while signed out and signed in, on every relevant multisite blog, with optional dependencies both enabled and disabled. Confirm that uninstalling or deactivating the integration does not delete site-owned content unexpectedly.

Related guides

• Read POM theme settings safely
• Load assets only where they are needed
• Sanitization, escaping, and capability requirements