Welcome to the NZRT Wiki Podcast. Today we’re looking at 🔧 Plugin Development.

So let’s start with the big picture. WordPress plugins are how you extend what WordPress can do without ever touching the core files. That’s an important distinction — you’re not hacking into WordPress itself, you’re adding on top of it. And the way WordPress knows something is a plugin is surprisingly simple: it just needs to be a PHP file with a special comment block at the top.

That comment block is called the plugin header, and it’s basically the plugin’s ID card. Picture a block of text near the top of a PHP file. It contains a few labelled fields — things like Plugin Name, which is just what you want to call it, a Description explaining what it does, a Version number like one point zero point zero, the Author’s name, and a License — in this case GPL version two or later. WordPress reads that block and goes “yep, that’s a plugin, I know what to do with this.” Without it, WordPress won’t recognise the file as a plugin at all. So that header is non-negotiable.

Now, once your plugin is recognised, how do you actually make it do things? That’s where hooks come in, and there are two types you need to know about.

The first type is called Actions. An action lets you run your own code at a specific moment in the WordPress lifecycle. You register an action by calling the add action function. You give it two things: the name of the hook — which represents a moment in time, like when the site footer loads — and the name of your own function that you want to run at that moment. So if you want something to happen right as WordPress is wrapping up the bottom of the page, you’d hook into the footer event and point it at your function.

The second type is called Filters. Filters are similar, but instead of just running code, you’re intercepting data and modifying it before WordPress uses it. You use the add filter function in the same way — give it the name of a hook and your function name. A good example from the documentation is filtering the title of a post. You can grab that title as it’s being processed and change it before it ever appears on the screen.

Speaking of hooks, there are a handful of common ones worth keeping in mind. The init hook fires once WordPress has fully initialised — it’s a good general-purpose starting point for a lot of plugin logic. The wp enqueue scripts hook is where you’re supposed to register and load your CSS stylesheets and JavaScript files. The wp footer hook runs when the footer of the site is being output. The rest api init hook is where you’d set up any custom REST API endpoints, and save post fires whenever a post gets saved — which is handy if you need to trigger something in response to content being created or updated.

And just to bring this into the NZRT context — if you’ve worked with the NZRT stack, you’ll know that we have a custom plugin called WP-Script, which uses exactly this kind of plugin architecture to connect WordPress to the Dolibarr REST API. That integration relies on these same hook patterns to run at the right moments and pass data between the two systems. Beyond that, the WordPress setup here also uses plugins like SmartSlider3 for media, JC Importer for bringing in content, and others that extend navigation and core features — all built on the same foundation you’ve just heard about.

If you want to dig deeper, the related areas to explore are Hooks and Filters in more detail, the WP-Script Core documentation, and the broader Plugins Overview in the wiki.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.