SCIWP

An MVC framework for building WordPress plugins: a router, an ORM, services and service providers, an asset manager, autoloading and dependency injection. The full documentation lives on its own site, sciwp.com, and this page is only about what it is and why it exists.

WordPress has no application layer

WordPress knows about posts, pages and hooks. What it does not have is anywhere to put an application. There is no router, no models, no services, no separation between what your plugin does and how it draws it, so anything beyond a small plugin ends up as a pile of functions listening to actions, with the queries written by hand next to the markup.

That works until the plugin has to be a real product. Then you find yourself writing the same scaffolding every time: a way of answering a URL, a way of talking to a table without repeating SQL everywhere, a place to keep logic that is neither a view nor a database row. I had already written that scaffolding twice by hand, once for a learning platform and once for a key management plugin. SCIWP is it written once, on purpose.

It stands beside WordPress, not on top of it

The framework provides the separation between models, controllers and views without replacing WordPress or asking a plugin to stop being a WordPress plugin. Hooks still work, the standards still apply, and a plugin using it is still installed and updated like any other.

That is the whole constraint, and it is what makes this different from putting Laravel behind WordPress. The framework has to be a guest: it cannot own the request, cannot own the database connection, and cannot assume it is the only thing running.

Two ways in

It can be bundled inside your own plugin with a few lines, with the namespacing resolved on activation so that other plugins can extend yours through the same framework. Or it can be installed standalone, as a plugin of its own that others sit on, with updates coming straight from GitHub.

The two are not the same trade. Bundled, your plugin carries its own copy and depends on nobody. Standalone, several plugins share one framework and are updated together, which is better until two of them want different versions.

Where it comes from

It is not a port of one framework. I went through several before writing it and took what fitted a plugin: routes that read like Laravel's, the service provider idea, the parts of ZF3 and Symfony that survive when you cannot own the entry point.