Plugin Framework is the reusable runtime foundation for SiteMods WordPress plugins and extensions. It supplies shared mechanics without deciding the business rules of a final website.
What the Framework Owns
- Component registration, context, namespace-aware autoloading, and request-surface launching.
- Lifecycle coordination and one organized Loader for WordPress actions and filters.
- Settings infrastructure, plugin and extension registries, and shared helpers.
- Guarded integration services and loading for enabled framework extensions.
- A WordPress-native client for authorized, manually reviewed framework updates.
Keep Core Focused
Cleanup, branding, security choices, editor controls, account access, email behavior, content formatting, taxonomy ordering, special characters, and WooCommerce controls are not permanent framework opinions. They live in focused extensions so a website can select the capabilities it needs and leave the rest inactive.
A Consistent Project Structure
Site-specific plugins use clear administrative, frontend, shared, lifecycle, settings, and asset boundaries. This makes ownership easier to understand and keeps project behavior separate from reusable framework services.
Site-Specific Plugin
An independent child package that registers with the framework and owns the content types, integrations, workflows, settings, and other behavior unique to its website.
How extension activation works
Extension metadata is available to the administration workflow, but normal requests load only the identifiers saved as enabled. A disabled extension registers no settings tab, runtime hooks, assets, or output. Its saved settings remain available if it is enabled again. Review all current extensions.
From Framework to Site Plugin
A site plugin describes its identity and runtime classes once, then launches through the framework instead of copying shared infrastructure into every project.
A Registration Example
The following abbreviated example shows how a site-specific plugin registers with the framework:
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 );The framework remains responsible for shared loading and coordination. The final plugin can evolve around its website without turning project rules into framework defaults. Plugin Framework and its registered child plugins currently support single-site WordPress installations.