Plugin Framework Integration

A site-specific plugin is an independent package with its own identity and responsibilities. It registers with Plugin Framework so it can reuse shared mechanics without copying them.

The Relationship at a Glance

Framework Services

Component context and namespace-aware autoloading
Lifecycle and option coordination
Organized action and filter registration
Settings, plugin, and extension registries
Guarded shared integrations and update boundaries

Site Plugin Responsibilities

Project identity and package ownership
Content types, fields, and business rules
Administrative and frontend workflows
Project integrations and data handling
Site-specific settings, assets, tests, and documentation

Register the Component

The bootstrap describes the site-specific plugin to the framework, then asks the framework to launch the appropriate shared, administration, and frontend classes.

use SiteMods\Plugin_Framework\Includes\Framework;

$context = Framework::register_plugin(
    array(
        'id'           => CLIENT_SITE_PLUGIN_ID,
        'version'      => CLIENT_SITE_PLUGIN_VERSION,
        'file'         => __FILE__,
        'namespace'    => 'ClientSite\\Plugin',
        'text_domain'  => 'client-site-plugin',
        'option_name'  => 'client_site_plugin_settings',
        'admin_class'  => 'ClientSite\\Plugin\\Admin\\Admin_Main',
        'front_class'  => 'ClientSite\\Plugin\\Front\\Front_Main',
        'shared_class' => 'ClientSite\\Plugin\\Shared\\Shared_Main',
    )
);

Framework::launch_component( $context );

Register Hooks Through the Loader

Component classes still use normal WordPress actions and filters. The Loader gives those registrations one organized path and keeps their component ownership visible.

use SiteMods\Plugin_Framework\Includes\Loader;
use ClientSite\Plugin\Shared\Post_Types;

Loader::add_action(
    CLIENT_SITE_PLUGIN_ID,
    'init',
    Post_Types::$instance,
    'register_post_types'
);

What Happens on a Request

WordPress loads Plugin Framework and the active site plugin.
The site plugin registers its identity, namespace, option, and runtime classes.
The framework resolves registered classes from the correct package directories.
The launcher starts shared behavior and the appropriate administration or frontend surface.
The Loader connects the component's actions and filters to WordPress.
Enabled extensions add only their selected capability groups.

Does the site plugin copy the framework?

No. It is an independent package that consumes the framework's public services. Reusable infrastructure stays in Plugin Framework; project behavior stays in the site plugin.

Where does a new feature belong?

Behavior useful across many sites may belong in framework core or a focused extension. Behavior tied to one website's content, users, operations, or integrations belongs in that site's plugin.

Plugin Framework and every registered child plugin currently use a single-site WordPress contract. Site plugins remain project-managed and do not receive the framework's remote-update identity.

Return to Plugin Framework

Continue to Theme Integration

Development Process