System Architecture

High-Level Overview

This project is architected as a modular extension layer for WordPress Core. Rather than modifying the core files, it leverages the WordPress Event-Driven Architecture (Hooks system) to inject custom business logic, extend data structures, and provide a modern API interface for headless or decoupled frontends.

The system is divided into three primary layers:

1. Integration Layer: Interacts directly with WordPress globals and hooks.
2. Service Layer: Contains the core business logic independent of the WordPress environment.
3. Data Layer: Manages Custom Post Types (CPTs) and specialized metadata schemas.

Core Components

1. Hook-Based Interface

The system interfaces with WordPress primarily through actions and filters. This ensures that the project remains compatible with core updates while allowing deep customization of the request lifecycle.

• Public Actions: Trigger custom logic during post saves, user registrations, or administrative events.
• Public Filters: Allow users to modify data before it is persisted to the database or rendered to the UI.

2. REST API Controllers

To facilitate modern frontend integrations (like the MVP mentioned in our history), the architecture includes a custom REST API namespace. These endpoints wrap WordPress native functions into structured JSON responses.

Endpoint Example: GET /wp-json/udit-akhourii/v1/resource

| Parameter | Type | Description | | :--- | :--- | :--- | | id | int | The unique identifier for the resource. | | context | string | Either view or edit. Defaults to view. |

Usage Example:

// Interacting with the custom API via PHP internal request
$request = new WP_REST_Request('GET', '/udit-akhourii/v1/resource');
$request->set_param('id', 123);
$response = rest_do_request($request);
$data = rest_get_server()->response_to_data($response, true);

3. Service Providers (Internal)

While most interactions happen through hooks, the logic is encapsulated within Service Providers. These are internal components that handle tasks like third-party API integrations or complex calculations. Users interact with these indirectly by calling the public wrapper functions provided in the project's bootstrap file.

Data Schema & Persistence

The architecture utilizes WordPress's native table structure but extends it using:

• Custom Post Types (CPT): Used to define new content entities (e.g., ua_contribution).
• Meta Registration: All custom fields are registered via register_meta to ensure they are visible to the REST API and protected by internal permission checks.

Schema Interaction

To retrieve or update data within this architecture, use the standard WordPress CRUD wrappers to ensure all registered hooks are fired:

// Recommended way to interface with project data
$contribution_id = wp_insert_post([
    'post_type'   => 'ua_contribution',
    'post_status' => 'publish',
    'meta_input'  => [
        '_ua_version' => '1.0.0',
    ],
]);

Integration Lifecycle

1. Initialization: The project registers its services on the plugins_loaded or init hook.
2. Routing: Incoming requests are intercepted by the WordPress Rewrite API and routed to either the standard template loader or the Custom REST Controllers.
3. Execution: Logic is processed in the Service Layer.
4. Response: Data is returned via standard WordPress filters, allowing other 3rd party plugins to remain compatible with this project's output.