Overview

WPZylos Core is the foundation package for the WPZylos framework. It provides essential interfaces, contracts, and base classes that all other WPZylos packages depend on.

Purpose

The core package solves several critical problems for WordPress plugin development:

1. Plugin Identity - Centralized management of plugin slug, prefix, version, and paths
2. PHP-Scoper Compatibility - Interface-based design that survives namespace rewriting
3. Service Provider Pattern - Modular, testable architecture
4. Consistent Naming - Automatic prefixing for options, hooks, and tables

Key Components

ContextInterface

The ContextInterface is the most important contract in the framework. It defines how a plugin identifies itself and is used by all framework packages:

interface ContextInterface
{
    public function slug(): string;
    public function prefix(): string;
    public function textDomain(): string;
    public function version(): string;
    public function path(string $relative = ''): string;
    public function url(string $relative = ''): string;
    public function hook(string $name): string;
    public function optionKey(string $name): string;
    public function tableName(string $name, string $scope = 'site'): string;
}

PluginContext

The default implementation of ContextInterface that plugins use:

$context = PluginContext::create([
    'file' => __FILE__,
    'slug' => 'my-plugin',
    'prefix' => 'myplugin_',
    'textDomain' => 'my-plugin',
    'version' => '1.0.0',
]);

Application

The plugin kernel that manages the service container and providers:

$app = new Application($context);
$app->register(new MyServiceProvider());
$app->boot();

ServiceProvider

Base class for registering services:

class MyServiceProvider extends ServiceProvider
{
    public function register(ApplicationInterface $app): void
    {
        $this->singleton(MyService::class, fn() => new MyService());
    }
}

Design Philosophy

1. Interfaces over implementations - All cross-package dependencies use interfaces
2. Plugin owns context - Framework never hardcodes plugin identity
3. No global state - Everything flows through the container
4. WordPress-native - Uses WP functions, not replacements