How To Write an MVC Wordpress Plugin

Sticking to MVC Makes Your Plugin Code Easy To Upgrade and Maintain

Wordpress plugins don't have to follow specific structure. That's why everyone writes them in their own style. Plenty of the existing plugins are a mess of files named without following any conventions, full of procedure code, mixed HTML with PHP, and just dropped into a single folder (I'm guilty for the last one too). This works for small plugins but once you start adding more complex functionality it quickly turns into maintenance nightmare.

MVC (Model-View-Controller) is a good solution to this. Maybe not the best, but it's probably the most popular and good enough. So from my latest plugins like Eventy PRO for example I am starting to follow the MVC approach I am going to share with you.

I am not saying that my approach is the best or the only possible one. There are several MVC frameworks for Wordpress that handle things in slightly different way. But I think what I share is easy and well structured, and will let you write good plugins that are easy to maintain.

Dissection

Let's see what each of these calls does and how the actual work in the plugin can be done.

The helpers contain basic helper function like one that makes friendly links, another one that outputs a date drop-down selector, and so on. These are created as classes with static models so we can invoke them just like procedure functions, without creating an object. Why use objects at all then? Because we want to avoid possible name collisions with other plugins. So for example a call to display date drop-down would look something like this:

MyPluginHTMLHelper::date_dropdown();

It's few letters longer than calling a short procedure function but you can be sure there will be no naming conflict. Alternative to this would be using PHP namespaces.

Then the models work like models in any web application. They generally abstract each of the database tables that your plugin uses. I like to make one exception with the basic/main model here. It is a file named after the plugin name, and contains all the initialization functions. So for example for MyPlugin, your class would be called MyPlugin in models/myplugin.php and would look like this:

class MyPlugin
{
	// runs the DB table queries
   static function install()
   {
   	// ...
   }

   // creates the admin menu
   static function menu()
   {
		// ...
   }

   // CSS and JS
	static function scripts()
	{
		// here are the wp_enqueue_script, wp_enqueue_style etc calls
	}

	// initialization
	static function init()
	{
		// load_plugin_textdomain, creating constants (for table names for example)
	}

	// manage general options
	static function options()
	{
		// ...
	}

	// registering widgets
	static function register_widgets()
	{
		// register_widget('MyPluginWidget') etc
	}
}
		

Of course you may prefer to keep this file outside of models if you wish.

Then in controllers I put specific classes for different logical operations. You are entirely free to follow your own ideas here. You can even load all controller classes in a single file.

The menus (called by add_menu_page, add_submenu_page etc) will call different controller functions. Then these controller functions require models only when they need them, and include the appropriate views. This part should be pretty straightforward for everyone who has worked with the MVC concept outside of Wordpress.

To get a better idea you can check the code of the free Eventy plugin. It doesn't follow the given structure exactly but is pretty close (I'll try to get closer with the next update).