Building plugins for WordPress is powerful… but as plugins grow, maintaining clean code can quickly become a nightmare.
After years of working with Laravel, I found myself missing the structure — clean routing, validation, database abstraction — all the things that keep projects sane at scale.
So I built WordForge.
WordForge is a lightweight, MVC-style framework for WordPress plugin development.
It brings:
•	Laravel-style routing and controllers for REST endpoints
•	A clean query builder for database interactions
•	Form request validation and middleware
•	Service providers for organized bootstrapping
•	Zero external dependencies — just native WordPress under the hood
It doesn’t try to “overengineer” WordPress — it gives you just enough structure to keep your plugins maintainable, readable, and scalable.
If you’re building WordPress plugins and want to avoid the usual chaos, check out WordForge.
<a href="https://github.com/codestify/wordforge" target="_blank" rel="noopener nofollow">https://github.com/codestify/wordforge</a>
You might like it

Welcome to PHP Dev, a dedicated space for sharing knowledge about PHP and its ecosystem (only PHP directly related).
Help us find good articles and blogposts and provide links. Upvote or downvote, after reading, it's essential

PHP Dev

WordForge is a lightweight MVC-style framework designed to simplify WordPress plugin development by offering Laravel-style routing, clean query builders, and form request validation, all with no external dependencies. It aims to make plugins more maintainable and scalable, addressing common chaos in plugin code structure.

WordForge - An opinionated MVC structure from Wordpress Plugins development

Pretty good project overall. My suggestions would be to look into making it also work with a couple other similar systems out there.
In particular. If you are going to involve composer requirements, it would be good to make sure it supports setups where wordpress was setup with <a href="https://github.com/roots/wordpress-core-installer" target="_blank" rel="noopener nofollow">composer</a> / <a href="https://wpackagist.org" target="_blank" rel="noopener nofollow">wpackagist</a> support, where the vendor folder might be outside of the individual plugin. A setup like this would let you handle all wordpress management using a more laravel like workflow.
I do love the query builder, reminds me of <a href="https://github.com/corcel/corcel" target="_blank" rel="noopener nofollow">Corcel</a> which is a package that lets you use actual Eloquent with a wordpress database. I’ve used it for projects where I’ve wanted to access a wordpress database from within Laravel. Not really something to integrate with as it is a completely different project, just thought I’d point it out.
Also one package I’ve used (and loved) in Wordpress development in the past has been <a href="https://github.com/timber/timber" target="_blank" rel="noopener nofollow">Timber</a> which lets you use Twig for Wordpress themes. I personally prefer Twig to Blade as Twig is much closer to handlebars which minimizes the differences in php based and javascript based templating, also it fully separates the view layer from the execution layer. I find with Blade (or Wordpress’ preferred phptemplate), it is WAY too easy to add executable code in the view layer, which becomes a bit of a slippery slope for keeping your codebase clean.

Probably better to just use directly Laravel’s packages instead of maintain copies of those files with a different namespace.

Once somebody builds with this a project, let me benchmark speed, I have some guts feeling I want to confirm/refute.

Love it – now the trick is making something like this the new standard. Every plugin …ever, is built on a structure based on that particular developers mood. Would be great to see literally any consistency.