4WP Core

Lightweight PSR-11 compatible dependency injection container and modular architecture for WordPress plugins.

Overview

4WP Core provides a minimal infrastructure for building modular WordPress plugins with dependency injection, following the pattern inspired by inpsyde/modularity. It enables plugins to work autonomously while optionally leveraging shared core services.

Features

• PSR-11 Compatible Container: Lightweight dependency injection container
• Modular Architecture: Service modules via ServiceModuleInterface
• Plugin Bootstrap: Clean initialization and module management
• Core Services: Logger, SettingsManager, HooksManager, ErrorHandler
• Autonomous Plugins: Plugins can work independently with fallback services
• PSR-4 Autoloading: Composer-based autoloading support

Requirements

• PHP 7.4+
• WordPress 5.0+
• Composer (for development)

Installation

As a WordPress Plugin

1. Place the 4wp-core folder in your wp-content/plugins/ directory
2. Activate the plugin through the WordPress admin panel

Via Composer (for development)

composer require forwp/core

Quick Start

Using Core in Your Plugin

<?php
// bootstrap.php

// Prevent direct access
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

// Check if core is available
if ( class_exists( '\ForWP\Core\PluginBootstrap' ) ) {
    $bootstrap = new \ForWP\Core\PluginBootstrap();

    // Add your modules
    $bootstrap->addModule( new \MyPlugin\Modules\MyModule() );

    // Boot the plugin
    $container = $bootstrap->boot();

    // Use services from container
    $logger = $container->get( \ForWP\Core\Services\Logger::class );
    $logger->info( 'Plugin initialized' );
} else {
    // Fallback: use autonomous services
    // Your plugin should have its own service implementations
}

Creating a Module

<?php
namespace MyPlugin\Modules;

use ForWP\Core\ServiceModuleInterface;
use ForWP\Core\Services\Logger;
use Psr\Container\ContainerInterface;

class MyModule implements ServiceModuleInterface {

    public function id(): string {
        return 'my-plugin-module';
    }

    public function register( ContainerInterface $container ): void {
        // Register services
        $container->set( 'my-service', function( $c ) {
            return new MyService( $c->get( Logger::class ) );
        } );
    }

    public function init( ContainerInterface $container ): void {
        // Initialize module
        $logger = $container->get( Logger::class );
        $logger->info( 'MyModule initialized' );
    }
}

Core Services

Logger

PSR-3 compatible logger that writes to WordPress debug.log:

$logger = $container->get( \ForWP\Core\Services\Logger::class );
$logger->info( 'Information message' );
$logger->error( 'Error message', [ 'context' => 'value' ] );

SettingsManager

Manages WordPress options with prefix support:

$settings = $container->get( \ForWP\Core\Services\SettingsManager::class );
$settings->set( 'my_option', 'value' );
$value = $settings->get( 'my_option', 'default' );

HooksManager

Centralized WordPress hooks management:

$hooks = $container->get( \ForWP\Core\Services\HooksManager::class );
$hooks->addAction( 'init', [ $this, 'onInit' ] );
$hooks->addFilter( 'the_content', [ $this, 'filterContent' ] );

ErrorHandler

Catches and logs PHP errors and exceptions:

$errorHandler = $container->get( \ForWP\Core\Services\ErrorHandler::class );
$errorHandler->register();

Architecture

Container

The Container class implements PSR-11 ContainerInterface and provides:

• Service registration via factories or instances
• Singleton caching of resolved services
• Exception handling for missing services

PluginBootstrap

The PluginBootstrap class manages:

• Module registration
• Service container initialization
• Module initialization lifecycle

ServiceModuleInterface

Modules implement this interface to:

• Register services with the container
• Initialize module-specific functionality
• Provide a unique identifier

Roadmap

Phase 1 ✅ (Current)

• Container (lightweight DI)
• ServiceModuleInterface
• PluginBootstrap
• Basic services: Logger, SettingsManager, HooksManager, ErrorHandler
• PSR-4 autoloading

Phase 2 (Planned)

• Module structure standardization
• PSR-3 LoggerInterface compliance
• Unit tests for services
• Optional core integration

Phase 3 (Planned)

• Additional services: APIClient, Cache, EventDispatcher, FeatureFlags, Scheduler
• Service reuse across plugins

Phase 4 (Planned)

• AI-ready structure
• Documentation standards
• Automated testing and analysis

License

GPL-2.0-or-later

Credits

Inspired by inpsyde/modularity