WP Kernel

Why WP Kernel? ​

WordPress already gives us powerful primitives-blocks, Interactivity, script modules, and a reliable REST API. What teams still lack is a shared frame for turning those primitives into products without re-solving the same architecture on every build. WP Kernel steps in as that frame. It keeps JavaScript in the driver's seat while asking PHP to focus on capabilities and transport, so you deliver features faster without forking away from Core.

Built for people shipping features ​

Developers get consistent patterns for data fetching, mutation, and error handling. Product teams see shorter feedback loops because the guardrails prevent accidental tight coupling. Business stakeholders gain confidence that every feature emits canonical events, making analytics, integrations, and audits first-class rather than afterthoughts.

The golden path ​

A typical feature follows four beats. Start by defining a Resource so the contract between client and server is explicit. Wrap writes in an Action that manages permissions, retries, events, and cache invalidation. Bind data into blocks or React components using the generated hooks, then extend behaviour through the Interactivity API. Because every team walks the same path, documentation stays in sync with the actual code.

A guided example ​

To make the flow tangible, consider the smallest slice of functionality: creating and listing “things.”

// 1. Define a resource
export const thing = defineResource<Thing>({
	name: 'thing',
	routes: {
		list: { path: '/wpk/v1/things', method: 'GET' },
		create: { path: '/wpk/v1/things', method: 'POST' },
	},
	schema: import('../../contracts/thing.schema.json'),
});

That declaration generates a typed client, cache helpers, and store selectors. An Action then centralises the write path and emits canonical events:

export const CreateThing = defineAction({
	name: 'Thing.Create',
	handler: async (ctx, { data }) => {
		const created = await thing.create(data);
		ctx.emit(thing.events.created, { id: created.id });
		ctx.invalidate([thing.key('list')]);
		return created;
	},
});

Finally, your UI calls the Action. No component reaches into transport APIs directly, which keeps retries and analytics consistent across the application.

import { CreateThing } from '@/actions/Thing/Create';

const handleSubmit = async () => {
	await CreateThing({ data: formData });
};

When React enters the picture, mount the runtime with KernelUIProvider so hooks can subscribe to the kernel event bus without legacy globals.

import { KernelUIProvider } from '@wpkernel/ui';

createRoot(node).render(
	<KernelUIProvider runtime={kernel.getUIRuntime()}>
		<App />
	</KernelUIProvider>
);

What ships in the repository ​

The monorepo includes the core @wpkernel/core package for resources, Actions, events, and jobs; @wpkernel/ui for DataViews controllers, forms, and bindings; @wpkernel/e2e-utils for Playwright helpers; and a showcase application that exercises the full stack. Tooling for linting, testing, and CI/CD is already configured so new contributors can focus on product work from day one.

Ready to start? ​

Head to the Getting Started guide for installation and the narrated quick start. If you prefer to skim before coding, the Core Concepts section explains how resources, Actions, events, bindings, and jobs work together. When you want to explore the wider project documentation, the Repository Handbook points directly to DEVELOPMENT.md, BRANCHING_STRATEGY.md, and other living references.