So PHPNomad can run as an MVC framework now. That’s neat.

I needed a way to make Siren run outside of WordPress. After careful consideration, I decided the best route to take was to set up the last couple of packages needed to just make PHPNomad capable of running as its own MVC framework. I spent a weekend creating the strategies that WordPress handles for Siren using various Symfony packages and other dependencies. After that, I structured it so that the app runs PHPNomad, registers the routes embedded in the application properly, and allows you to create views specific to the app if-needed.

Then promptly after proving the concept, I set it aside and went back to working on the million other things I have going on right now (the first few months of launching Novatorius has been a lot, y’all.)

Fast-forward to today, one of my devs that’s helping me with a client’s WordPress theme mentioned that he was using a little local setup to render Twig files without depending on WordPress. Our internal theme framework uses PHPNomad and Twig for rendering, so it’s easy-enough to transfer the twig architecture into WordPress as we go.

But as he was talking about it, I realized that I had already solved that problem with my MVC framework for Siren, I just needed to extract the last few bits to create a template that can be used in any context, not just Siren.

Fast forward a couple of hours, and bam, the initial version of PHPNomad’s MVC framework is ready to go!

It’s not documented, the packages still use git instead of composer, and it’s still really early in the process, but I’m really excited about it because I’ve been wanting to run PHPNomad’s documentation as a PHPNomad application for a while now, and I think this is the last piece I needed to be able to do that.

Some Real-World Benefits

What I love about this, is that it’s already starting to show how powerful the nomadic approach can be. Our first live use-case of the MVC framework was not to build a web app, but to help development for a WordPress theme. That’s wild when you think about it.

Imagine you’re building a WordPress plugin. Traditionally, you’d need a full WordPress installation, a properly configured theme, and all the associated overhead just to start development. Since we use the nomadic approach, we can:

• Develop and test your core functionality independently
• Write and debug your code in a clean, isolated environment
• Create strategies that the WordPress integration can implement later-on.

So now, if we start our development in the MVC framework, we can create controllers that use strategies for rendering and everything else, and simply set them up to return dummy values in the MVC app. The theme can then compile the what it needs from the app, and include strategy implementations specific to WordPress, and voila! it all works.

This is a first major step toward making the front-end just as nomadic as the back-end. Really exciting stuff!

Conclusion

I’ve said this before, and I’ll say it again – once I got comfortable with PHPNomad, I just want to use it everywhere. There’s something so great about never switching codebases. No matter what you write, it’s always using the same patterns established by PHPNomad.

From here, I’m really excited to think through how to set up a markdown-friendly rendering engine so I can set up some kind of Docusaurus-like documentation setup that runs using this framework. Right now I only have a PHPEngine and a Twig Engine, but I’m sure it would be simple-enough to set up a markdown engine, and handle automated routing. Right now the MVC framework uses a config file for routes, but that can be yanked out and custom logic can be used instead. For another day, perhaps.