README

Shared LoadableInterface + AbstractPlugin bootstrap pattern for Silver Assist WordPress plugins. Generalizes the singleton-plus-priority-ordered- component-loader pattern that contact-form-to-api already implements by hand, and that SILVERASSIST_STANDARDS.md documents as the target for every plugin — so a concrete plugin only has to write get_components(), not re-implement instance()/init()/the loading loop per repo.

Install

composer require silverassist/wp-plugin-kernel

(Runtime dependency, not --dev — this ships classes your plugin's bootstrap actually calls.)

Usage

<?php
namespace SilverAssist\YourPlugin\Core;

use SilverAssist\PluginKernel\AbstractPlugin;
use SilverAssist\YourPlugin\Admin\SettingsPage;
use SilverAssist\YourPlugin\Service\SomeService;

final class Plugin extends AbstractPlugin {
    protected function get_components(): array {
        return [
            SomeService::class,
            SettingsPage::class,
        ];
    }

    protected function init_hooks(): void {
        // Anything that isn't itself a LoadableInterface component —
        // e.g. wp-github-updater initialization.
    }
}

<?php
// your-plugin.php — main plugin file.
add_action( 'plugins_loaded', static function () {
    \SilverAssist\YourPlugin\Core\Plugin::instance()->init();
} );

Each component listed in get_components() implements SilverAssist\PluginKernel\Interfaces\LoadableInterface directly (for a plain component) or extends AbstractPlugin itself (if it needs its own sub-components — uncommon, but the singleton-per-subclass design supports it).

Testing

SilverAssist\PluginKernel\Testing\TestCase is a thin WP_UnitTestCase base — see its own class docblock for the two non-obvious rules every subclass needs (the deprecated $this->factory trap, and why CREATE TABLE must go in wpSetUpBeforeClass()).

What's deliberately NOT here

Coding style / PHPCS / PHPStan — see silverassist/wp-coding-standards.
An Activator base class — activation/deactivation logic (creating tables, setting default options) is genuinely plugin-specific enough that a shared base class would have little real behavior to share. Revisit only if a real migration reveals actual duplicated logic worth extracting.

silverassist / wp-plugin-kernel

Maintainers

Package info

Statistics

Security

README

Install

Usage

Testing

What's deliberately NOT here

See also