Swilen (wp)

Swilen (wp) is an experimental re-architecture of WordPress built for the modern web. use Swilen framework behind the hood. for persistant workers and async operations.

It’s not just a rewrite. It’s an attempt to answer a simple question:

What would WordPress look like if it were designed today?

Swilen combines an async, event-driven backend with a modern, reactive admin UI, while still respecting the massive ecosystem that made WordPress what it is.

The goal is not to replace WordPress.

It’s to evolve it — without forcing anyone to start from zero.

Vision

WordPress powers a huge portion of the internet, used by millions of websites. But its architecture comes from a different era — synchronous PHP, full page reloads, tightly coupled rendering.

Swilen explores a different path:

• Async runtime
• Event-driven core
• Headless-first architecture
• Reactive admin (SPA-like experience)
• Progressive compatibility with existing plugins

This is not about breaking the past.

It’s about building a future that can still understand it.

Core Principles

1. Headless First

Swilen behaves as a headless CMS by default.

Request → API → Content Service → JSON

Themes are optional and only loaded when needed for compatibility.

This allows:

• modern frontends (Vue, React, etc.)
• API-first workflows
• decoupled architectures

Swilen also supports advanced communication layers such as:

• gRPC for high-performance internal services
• MCP (Modular Communication Protocol) for flexible, event-driven integrations

These enable efficient service-to-service communication and open the door to distributed architectures.

For ultra-efficient runtime communication and high-performance workloads, you can also explore my open-source CMS: vayload.dev

2. Async Runtime

Swilen runs on an async server runtime (e.g. Swoole), enabling:

• persistent workers (no cold boot per request)
• connection pooling
• async I/O
• significantly faster execution

This changes everything about how WordPress logic can scale.

3. Event-Driven Core

Instead of procedural hooks everywhere, Swilen embraces events.

Event::listen(PostPublished::class, function ($post) {
    SearchIndexer::index($post);
});

This makes the system:

• more predictable
• easier to reason about
• easier to extend

4. Legacy Compatibility Layer

Swilen does not ignore the WordPress ecosystem.

It provides a compatibility layer that supports:

• add_action
• add_filter
• global APIs
• common WordPress patterns

This allows many existing plugins to run without modification, especially on the frontend.

However, compatibility is progressive, not absolute.

Not everything from the past needs to be perfectly preserved.

5. Modern Plugin API

New plugins are built using a modern architecture:

• events
• services
• dependency injection

class SeoPlugin implements Plugin
{
    public function boot(Application $app, EventDispatcher $dispatcher)
    {
        $dispatcher->subscribe(PostPublished::class, function ($post) {
            Sitemap::update($post);
        });
    }
}

This creates a cleaner and more maintainable ecosystem moving forward.

Admin Philosophy

The admin panel is not a direct clone of WordPress.

It is:

• reactive
• component-driven
• designed for speed and clarity

The core UI is fully controlled by Swilen.

Plugins do not render entire interfaces — they extend them.

The system defines the structure. Plugins enhance it.

Extension Model (Admin)

Instead of uncontrolled HTML output, Swilen introduces structured extension points:

editor.sidebar
editor.toolbar
posts.table.columns
header.actions

Example:

registerExtension({
	slot: 'editor.sidebar',
	component: SeoPanel,
});

This keeps the UI:

• predictable
• fast
• maintainable

Compatibility Strategy

Swilen approaches compatibility in layers:

1. Native (Modern)

Plugins built with the new API (events + components)

2. Extension-Based

Plugins that extend UI via defined slots (columns, panels, buttons)

3. Legacy (Partial)

Plugins that output HTML are captured, parsed, and rendered as blocks

4. Isolated (Fallback)

Large plugins (e.g. eCommerce dashboards) may run in isolated environments

Compatibility is not all-or-nothing. It is intentional.

Architecture Overview

HTTP Server (Async Runtime)
        │
        ▼
Swilen Core
        │
 ┌───────────────┬───────────────┐
 │ Modern Plugin │ Legacy Plugin │
 │ API (Events)  │ API (Hooks)   │
 └───────────────┴───────────────┘
        │
        ▼
Content / Users / Media Services
        │
        ▼
Admin UI (Vue - Reactive)

Roadmap

Swilen is being built in phases:

Phase 1 — Core Admin

• Custom admin UI (Vue)
• Posts, editor, basic data
• No plugin interference

Phase 2 — Frontend Compatibility

• Plugins work on frontend (themes, hooks)
• Admin remains controlled

Phase 3 — Extension System

• Introduce structured UI extension points
• Component-based plugins

Phase 4 — Basic Legacy Support

• Capture HTML output from plugins
• Render as blocks

Phase 5 — Transformer Engine

• Convert legacy HTML → structured components
• Introduce caching and matchers

Phase 6 — Plugin Classification

• Extensions vs legacy vs full applications

Phase 7 — Performance Layer

• caching (by plugin/version/route)
• lazy loading
• partial hydration

Goals

• Improve performance and scalability
• Enable async workloads
• Provide a modern developer experience
• Preserve the value of the WordPress ecosystem
• Create a system that can evolve over time

Status

Swilen is experimental.

It is a space to explore ideas, challenge assumptions, and build something better.

Expect changes. Expect iteration. Expect things to break — and improve.

Philosophy

Swilen is built on a simple belief:

WordPress doesn’t need to be replaced. It needs to be rethought and re-architected for a faster, more scalable, and modern web. The web is an incredible place — let’s make it even better.

License

MIT