I still Google things I’ve done a hundred times.
Not obscure things — obvious things. Last month I looked up the exact syntax for `add_action` priority parameters. Again. I’ve been writing WordPress hooks since 2011 and I still occasionally second-guess whether it’s `add_action( ‘hook’, ‘callback’, 10, 2 )` or the other way around.
For a while that felt like something to hide. Like admitting it would reveal some gap in my credentials. But the longer I’ve been doing this, the more I think the opposite is true: the developers I respect most are the ones who are completely comfortable saying “I had to look that up.”
This blog is me getting comfortable with that.
Where I’m coming from
I built my first WordPress site for a client in 2011. Back then the job was mostly: install WordPress, buy a premium theme, figure out the Customizer, add a contact form. It was enough to be useful, and it paid.
Over the years that evolved. I moved from pure freelancing into agency work, then into a web production role, and eventually into what I do now which is leading a content team at a tech publisher, managing CMS operations and web production workflows for a major electronics company. On any given week I’m overseeing Sitecore content ops, coordinating a team of content specialists, managing WordPress multisite setups, and dealing with the kind of edge cases that don’t show up in tutorials.
In parallel, the freelance work never stopped. I’ve been building WordPress sites on the side for over a decade, and what I build has gotten more complex over time.
But here’s the thing I’ve had to be honest with myself about: knowing how to use WordPress is not the same as understanding it deeply. I’ve been effective. I’ve shipped a lot of work. And there are still layers of how this platform actually works that I haven’t fully mapped out yet.
That gap is what this blog is about.
Why now — what changed
Two things happened around the same time that pushed me to start writing.
The first was a decision to build a WordPress plugin properly, not just slap together some functions in a file, but architect it the way a real software project is supposed to be built with PSR-4 autoloading and PHPUnit tests. A GitHub Actions CI pipeline that runs on every push. The kind of structure where, six months from now, you can actually read your own code.
I’d been putting that off for a while because I knew it would mean unlearning some habits. And I was right. It’s been humbling in the best way.
The second thing was picking up Laravel.
I’ve been a PHP developer for years, but almost all of that has lived inside the WordPress ecosystem. Laravel is the same language but a completely different mental model. The first time I looked at a Laravel service provider I genuinely didn’t know what I was looking at. That kind of feeling where being a beginner again at something adjacent to what you already know is uncomfortable and weirdly exciting at the same time.
I started taking notes. Then the notes got longer. At some point I thought: I might as well publish these.
There’s also something I’ve noticed about the developers I follow and learn from. Almost all of them write, or teach, or both. That’s not a coincidence. Explaining something forces you to understand it. I want to understand this stuff better, so I’m going to try explaining it.
What this blog is and isn’t
Just so we’re on the same page, this isn’t a tutorial site. I’m not going to walk you through installing WordPress or explain what a plugin is. There are better places for that, and I’m not the right person to write those posts.
What I will write about is the stuff that comes after the basics which are the decisions, the tradeoffs, the things that break in ways that StackOverflow doesn’t quite cover. Honest write-ups of actual work, including the wrong turns.
The four areas I’ll focus on:
- WordPress: theme development, plugin architecture, Full Site Editing, multisite, the things I’m learning by building real things rather than just reading about them
- Laravel: documenting my experience picking this up as a seasoned WordPress developer, the similarities, the differences, and the moments where my existing knowledge helps or gets in the way
- Dev Notes: shorter posts, quick tips, tools I find useful, workflow things that save time
- Side Projects: I’m building a Schema Markup plugin that I think could actually be a real product. I’ll document that whole process as it happens, including the parts where it doesn’t go to plan
I’m aiming to post roughly once a week. Sustainable over “I’ll post every day” followed by silence.
What I’m working on right now
The plugin architecture work is ongoing. I’ve been building a WordPress plugin from scratch following professional patterns: proper namespace structure, autoloading, unit tests, and writing about each part as I go. That’s the next post.
On the Laravel side I’m working through a structured curriculum and noting the moments where my WordPress background is an asset versus where it’s a liability. There are more of both than I expected.
And the Schema Markup plugin idea is starting to take shape. Schema is one of those things that matters a lot for SEO and technical publishers, and the existing tools leave a lot to be desired. I’ll write about the problem it solves and how I’m thinking about building it in a future post.
The closing
If any of this sounds familiar and if you’re also somewhere in the middle of the WordPress-to-deeper-PHP journey, or you’re a WP developer who’s looked at Laravel and thought “maybe”, you’re probably going to find something useful here.
And if you’re building something similar, or you’ve already been through the Laravel learning curve as a WordPress developer, I’d genuinely love to hear how it went.
That’s it. No newsletter pitch. Just: welcome, and let’s figure this out.