Experimenting with WordPress Part 1 – Minnow Transmuter

If you post something on X about a new WordPress fork – or even a hint of a fork – you’ll likely have your feed explode with feedback. Most of that attention is due to recent unpopular decisions from WordPress leadership, and not a desire to make something that can truly help WordPress. What would it look like to make a fork to actually help WordPress? I’m talking about code, not leadership.

The WordPress codebase is a mess and unlikely to be improved by the community or a company.

The changes needed to make the WordPress codebase a delight to work with are architectural, and proposing architecture changes to the codebase as big as WordPress is unlikely to gain traction inside the WordPress core development. There are too many ideas, too many people involved, and too much at risk. I propose that a single developer should fork WordPress. We need more opinionated forks of WordPress. If only one of these opinionated ideas becomes popular outside of WordPress, then WordPress could adopt system-wide changes that would benefit everyone.

Embedding WordPress as a compatible layer

I’ve been intrigued with the idea of turning WordPress core into a compatibility layer that can be embedded into other applications. Some of that desire comes from the fact that I don’t believe in the GPL license. If you fork WordPress, that fork must be GPL licensed as required by Wordpress’s GPL license. Ultimately I believe in open source without any restrictions. So when I have the option I always use the MIT license. That’s part of the reason why my WordPress contributions tend to be to WP-CLI, an MIT licensed project, and not WordPress core.

The difference between GPL and MIT licenses means everything to me. I have little interest in forking WordPress and then continuing to invest in more GPL code. Instead, I’d rather fork WordPress into something that’s internally cleaned up which could be required as a dependency within other MIT-licensed projects. I mean how cool would it be to start with a fresh PHP project or Laravel, write a few lines of MIT-licensed code, and still be able to use a WordPress plugin like Gravity Forms? That’s the dream.

A hypothetical directory structure for a new MIT-licensed project could look like this:

  • admin/ – New PHP, Vue.JS or whatever code you want
  • bridge/ – Fork of WordPress with modern functions and class bindings (GPL licensed)
  • data/ – Plugins, Themes and Uploads

Writing a script to transmute WordPress code into an organized PHP namespace.

I’ve begun experimenting with different ways of transforming the WordPress codebase into a slimmed-down and modern-looking codebase through an automated script. The output code might not look as nice as the Laravel framework, but it does transform messy WordPress code into a basic PHP namespace and class structures along with some thoughtful decisions around how internal code should be organized. This is all an experiment. I don’t expect anything I share here to look anything like a more mature version.

Meet, the Minnow Transmuter: https://github.com/MinnowOS/minnow-transmuter. With Minnow Transmuter you can do precisely what I described. It works by downloading a copy of WordPress, loops through all anonymous PHP functions and classes, and ports them to Minnow\Misc::anonymous_function_name and Minnow\anonymous_class_name. The real organization comes by configuring the generated mappings.yaml file to route all WordPress functions and classes to your liking. Each time the Minnow Transmuter runs, the WordPress code base is transformed into the newly assigned names with a corresponding bindings.php outputted to maintain WordPress compatibility.

Here are a few ideas I’m playing around with.

WordPressMinnow
add_action()Minnow\Action::add()
add_filter()Minnow\Filter::add()
wp_insert_post()Minnow\Post::insert()
wp_update_post()Minnow\Post::update()
global $post$post = Minnow::get(‘post’)
global $wp$app = Minnow::get(‘app’)
__return_trueMinnow::always_true
__return_falseMinnow::always_false
_()Minnow::always()

Refining a conceptual internal rewrite of WordPress by building a Vue.js administrator replacement.

Organizing code in a vacuum is really difficult. It’s best to have a real-world project. What better way to create something using the newly created classes and functions than by actually building an administrator panel from scratch? I’ve always thought a wp-admin replacement should be done using something like Vuetify. So much so that a few years ago I created a concept WordPress plugin called Vuetifused. I didn’t take the concept very far. I just mocked a few admin screens very quickly using Vue.JS and Vuetify.

I suspect that as I build out a new admin panel I’ll likely be tweaking the mappings of the classes and functions until I land on something that I’m happy with. I also think that the current wp-admin is so bloated that the barrier to make something better is quite low. Something an individual developer should be able to accomplish.

Minnow Transmuter lays the groundwork for a potential WordPress fork.

While I’m not making any commitments to make my own fork, you are welcome to follow along with my progress in experimenting with WordPress code: https://minn.xyz. My goal right now is simply to inspire other folks in the WordPress community to dig into the WordPress code and try out their own wild ideas. If you’re not sure where to begin then fork Minnow Transmuter and make it unique for your ideas.

If anyone would like to directly support me in pursuing these experimental WordPress ideas, feel free to contribute to my open source work on Github: https://github.com/sponsors/austinginder.