Utilizing OOP concepts to develop a custom WordPress theme.

With over ten years of experience building custom WordPress themes and plugins, I’ve seen my fair share of messy codebases. I’ve worked through everything from spaghetti-style procedural PHP that constantly ignores the DRY principle, to files so packed with tangled HTML and CSS that they become a nightmare to maintain. Refactoring this kind of code isn’t always fun, but it’s often necessary to boost performance and make things easier to manage in the long run.

Adding custom functionality to a WordPress theme can be as simple as writing a few procedural functions—like registering new menu locations or defining custom post types. But without a clear structure or strategy, it’s easy for things to get messy fast. What starts as a quick customization can snowball into a pile of duplicated, hard-to-follow code.

Below is a typical example of a procedural approach to adding functionality in a WordPress theme or plugin—something I’ve run into (and rewritten) more times than I can count.

<?php
add_action('init', function() {
	register_nav_menu('menu_location', __('Menu Location', 'menu_location'));
});

add_action('init', function() {
	register_nav_menus([
		'menu_one' => __('Menu One', 'menu_one'),
		'menu_two' => __('Menu Two', 'menu_two')
	]);
});
?>

The function shown above registers a new menu location that appears on the WordPress Menus page. You can also register multiple menu locations at once using an array, which is helpful when your theme requires more than one. If the theme is well-structured, a procedural approach might be perfectly fine. But in my experience, that’s rarely the case.

More often than not, the functions.php file becomes a dumping ground for everything—action hooks, filter hooks, and miscellaneous functions—sometimes stretching well beyond 1,000 lines. When something breaks, digging through that kind of mess is time-consuming and frustrating.

That’s where PHP’s object-oriented programming (OOP) features can make a big difference. By leveraging OOP, you can better organize your code, reduce repetition, and make things far more maintainable. Instead of a scattered mess of standalone functions, you can group related functionality into reusable classes with properties and methods shared across different parts of your theme or plugin.

I won’t dive too deep into the theory behind OOP or class structures, but I’ll walk through a practical example of how you can use classes in WordPress to clean up and modernize your theme—starting with how we register menu locations using an OOP approach.

<?php
class MenuLocationConfig {
	public function __construct() {
		add_action('init', [$this, 'initMenuLocations']);
	}
	
	public function initMenuLocations() {
		$this->registerMenu('Menu One');
		$this->registerMenu('Menu Two');
	}
	
	public function registerMenu($menu_name) {
		$key = preg_replace('/\s+/', '_', $menu_name);
	
		register_nav_menu($key, __($menu_name, $key));
	}
}
new MenuLocationConfig();
?>

By using OOP principles, you can group all the functionality related to a specific WordPress feature into a single class within one PHP file. Take the MenuLocationConfig class, for example—this class handles the registration of new menu locations. The benefit here is that you can dedicate individual classes to core WordPress features like custom post types and widgets, keeping each functionality in its own PHP file. This not only helps keep your code organized but also makes it much easier to maintain.

Embracing the OOP (Object-Oriented Programming) paradigm naturally supports the DRY (Don’t Repeat Yourself) principle. By using classes as blueprints, you can centralize shared functionality and avoid writing the same code over and over. This leads to a more organized, maintainable codebase that’s easier to scale and debug—something every developer can appreciate when working on larger or long-term projects.

Writing code in an OOP style in PHP is definitely a shift from the traditional procedural PHP approach, but once you get the hang of it, WordPress theme and plugin development becomes far more intuitive—and, honestly, more fun. That said, procedural PHP still has its place, and there are times when it might be the better choice depending on the scope of the project. This isn’t a one-size-fits-all solution.

As a fellow software engineer, I’m always interested in how others approach these challenges. If you’ve had experience with structuring WordPress projects using OOP, or have your own thoughts on balancing procedural vs. object-oriented approaches, I’d love to hear your perspective. Feel free to share your insights or drop a comment—I’m all ears! You can also reference the example codebase here to see how OOP concepts are applied in a real-world WordPress theme.