Welcome to the NZRT Wiki Podcast. Today we’re looking at Hooks & Filters.

If you’ve spent any time working with WordPress, you’ve probably heard the word “hooks” thrown around. But what exactly are they, and why do they matter? Let’s break it down in a way that actually makes sense.

At its core, WordPress hooks are a system that lets you — as a plugin or theme developer — step into WordPress at specific moments and either do something extra, or change something that’s already happening. The key idea is that you never have to touch the WordPress core files themselves. Instead, WordPress gives you these designated spots where you can attach your own code, and it handles the rest.

There are two types of hooks you need to know about: actions and filters. They sound similar but they do different things.

Let’s start with actions. An action hook is about doing something at a specific event. Think of it like an alarm going off — when WordPress reaches a certain point in its process, it fires that alarm, and any code you’ve attached to it wakes up and runs.

Here’s a simple example to picture. Say you want to add some custom text to the footer of every page on your site. You’d tell WordPress: “Hey, when you get to the footer moment, run my function.” The code example in the docs shows exactly that — you register a function called something like “my custom footer,” attach it to the footer event, and whenever WordPress builds that part of the page, it calls your function and outputs a paragraph of custom footer text. You didn’t touch a single core file. WordPress just calls your code at the right moment.

Now let’s talk about filters. Filters are a little different. Instead of just doing something, they’re about modifying data before it gets used or displayed. WordPress passes a piece of content to your function, you change it, and you hand it back.

Picture the post content on a blog. WordPress grabs your post text from the database, and before it shows it on screen, it runs it through a series of filters. The example in the docs shows a filter hooked into the content pipeline — your function receives the raw content, wraps it inside a div element, and returns that wrapped version. WordPress then uses that modified version for display. You’ve changed the output without ever touching how WordPress stores or retrieves it. Clean and surgical.

Now here’s where it gets a bit more nuanced — hook priority. When multiple functions are attached to the same hook, WordPress needs to know what order to run them in. That’s where priority comes in. Every hook has a default priority of ten. Lower numbers run earlier, higher numbers run later.

So if you have two filters both attached to the post title hook, and one has a priority of five while the other has a priority of fifteen, the one set to five runs first. It gets to modify the title before the second function even sees it. This matters a lot when the output of one function is meant to feed into another. Getting the order wrong can produce unexpected results, so it’s worth being deliberate about priority when you’re stacking multiple hooks.

Now let’s bring this back to NZRT specifically. If you’re working on anything inside the WP-Script plugin, you’ll see hooks used heavily to integrate Dolibarr REST API calls directly into the WordPress request cycle. Rather than building bespoke page loads or custom endpoints from scratch every time, hooks let the plugin slot into exactly the right moment in WordPress’s flow to make those API calls happen transparently.

SmartSlider 3 Pro, which you might be working with for visual content, also hooks into the theme templates — meaning it can inject slider content at template-level hook points without requiring manual template edits.

And if you’ve been involved in the agent role-based content filtering work, that’s another place hooks shine. Custom hooks allow content to be shown or hidden based on a user’s role, all handled through filter logic rather than conditional spaghetti scattered through templates.

So to pull it all together: actions let you run code at events, filters let you modify data in transit, priority controls the order everything fires in, and NZRT uses all of this to keep WordPress integrations modular and maintainable. If you want to dig deeper, the related topics to check out are Plugin Development, the WordPress REST API, and the WP-Script Core documentation.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Post Types and Taxonomies.

If you’ve ever wondered how WordPress decides what kind of content you’re looking at, post types are the answer. Every piece of content in WordPress belongs to a post type, and each type has its own rules about what it can do and how it behaves.

Out of the box, WordPress gives you three default post types. First, you have posts. These are your classic blog-style articles. They support comments, they can be sorted into categories, and you can attach tags to them. Second, you have pages. Pages are for static content, things that don’t really change often, like an About page or a Contact page. Unlike posts, pages don’t have a publication date and they don’t support comments. Third, you have attachments. These are your media files, things like images, videos, and documents that you upload through the media library.

On top of those defaults, WordPress lets developers create what are called Custom Post Types. You can think of these as entirely new content categories that you define yourself. Common examples are things like videos, products, or testimonials. When a custom post type doesn’t quite fit into a standard blog post, you build a new one that does exactly what you need.

Now, how do you actually create one of these custom post types? There’s a WordPress function called register post type, and when a developer calls it, they pass in a few key settings. They give the post type a name, in one example that would be video. They set it to public so it shows up on the site. They list the features it supports, things like a title, a main content editor, and a featured image or thumbnail. They can also switch on an archive page, so all videos can be listed in one place, and they can set a custom URL slug, so the web address reads something clean like slash videos.

That’s it in plain terms. You’re telling WordPress this new type exists, what it looks like, and where to find it.

Now let’s talk about taxonomies, because they work alongside post types to keep everything organised. A taxonomy is basically a way to group and label your content.

WordPress ships with two default taxonomies. Categories are hierarchical, meaning you can have parent categories and child categories nested inside them. They’re great for broad groupings. Tags on the other hand are non-hierarchical, flat lists of keywords. You’d use tags for more specific descriptive terms.

Just like with post types, you can also create custom taxonomies. Examples would be something like genres for a music site, regions for a local news site, or partners for a business directory. Any grouping logic that doesn’t fit neatly into categories or tags can get its own custom taxonomy.

Now, in the NZRT context, this matters a lot. NZRT’s WordPress setup uses a flexible post type and taxonomy structure that mirrors how Dolibarr, the ERP system, organises things by module. Pages in WordPress are mapped to Dolibarr modules, things like Customer, Sales, Finance, and HR. Custom taxonomies are then used to handle the category structure for each of those modules. So the two systems speak a similar language when it comes to how content is grouped and presented.

If you want to go deeper, the related areas to look at are WordPress Overview, Page Structure and Navigation, and Module Category Pages. Those will give you the fuller picture of how everything connects.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📚 WordPress Overview.

So, let’s talk about WordPress. If you’ve spent any time in the web industry, you’ve almost certainly come across it. WordPress is a content management system built on PHP, and it’s genuinely enormous in scale — it powers more than forty percent of all websites on the internet. That’s not a small number. From simple personal blogs all the way through to complex web applications, WordPress handles an impressive range of use cases, and the reason it can do that comes down to a few core design decisions around plugins, themes, and its REST API. We’ll get into all of those.

Let’s start with the most fundamental building blocks — content types. When you first set up a WordPress site, you get two out of the box. You have posts, which are typically your blog articles and time-based content, and you have pages, which are meant for static content that doesn’t change much — things like an About page or a Contact page. But here’s where it gets interesting. WordPress lets you go well beyond those two defaults through something called Custom Post Types. If you’re building a site that needs to manage videos, or products, or reviews, you can define entirely new content types that sit alongside posts and pages and behave just like them. That flexibility is a big part of why WordPress scales so well across different kinds of projects.

Now, once you have content, you need ways to organise it. That’s where taxonomies come in. You’re probably familiar with the built-in ones — categories and tags — but just like post types, taxonomies can be custom too. You might create a taxonomy called genres if you’re running a music site, or regions if you’re managing location-based content. It’s the same underlying system, just tailored to your needs.

Next up, and this one is really central to how WordPress works under the hood — hooks. There are two kinds: action hooks and filter hooks. The idea behind both is that WordPress fires off signals at specific points during its execution, and your plugin or theme can listen for those signals and respond to them. Action hooks let you run additional code at a given moment, while filter hooks let you intercept data and modify it before it’s used. The really important thing here is that this system lets you customise or extend WordPress behaviour without ever touching the core files themselves. That’s a key principle — you don’t edit core, you hook into it. It keeps your changes safe when WordPress updates.

Speaking of themes and plugins, let’s cover those quickly. A theme controls how your site looks. It’s made up of template files, stylesheets, and assets like images and fonts. When someone visits your site, WordPress pulls together the right template, applies your theme’s styles, and delivers the rendered page. Plugins, on the other hand, are about functionality rather than appearance. Want to add a contact form? There’s a plugin. Want to integrate with an external payment service or add SEO features? Plugins handle all of that. They’re self-contained packages that slot into WordPress and extend what it can do.

Now let’s talk about the actual file structure, because understanding where things live matters when you’re working with WordPress directly. At the top level, you have the core files. The wp-includes folder contains the core functions that make WordPress run. The wp-admin folder is your backend — the dashboard interface. Then there’s the wp-content folder, and this is the one you’ll spend the most time in. Inside it, you’ll find a themes folder, a plugins folder, and an uploads folder where media files live. The wp-content directory is essentially the home for everything site-specific and user-generated, keeping it neatly separated from the core.

Underneath all of this is a database — MySQL or MariaDB — that stores your posts, your metadata, your users, and your site options. Pretty much everything that makes your site unique lives in that database.

And finally, the REST API. WordPress exposes JSON endpoints that allow programmatic access to your content. This means external applications, mobile apps, or other services can read from and write to your WordPress site without going through the browser interface at all. It’s what makes WordPress viable as a headless CMS or as a backend that integrates with other platforms.

Which brings us to the NZRT context specifically. At NZRT, WordPress is the primary web platform for content delivery. It also integrates with the Dolibarr ERP system, which means WordPress isn’t sitting in isolation — it’s part of a broader connected stack where content and business operations talk to each other.

If you want to dig deeper after this episode, the related areas to explore are Theme Development, Plugin Development, Hooks and Filters, and the WordPress REST API — each of those builds on what we’ve covered today.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🔌 WordPress REST API.

So what is the WordPress REST API? Put simply, it’s a way for other software to talk to your WordPress site using standard web requests. Instead of logging into a dashboard and clicking around, you can send a request to a specific web address and get data back in a format called JSON — which is just structured text that machines are very good at reading. Plugins, mobile apps, and external services all use this approach to read and write things like posts, users, and custom data.

Let’s talk about the basic building blocks. There are five core actions you’ll use constantly. First, you can fetch a list of all your posts by hitting the posts endpoint on your site’s API path. Second, if you want just one specific post, you add its ID to the end of that same address. Those two are read-only, so no credentials needed. But the next three — creating a new post, updating an existing one, or deleting one — all require you to be authenticated first. WordPress won’t let just anyone write or delete content through the API, which makes sense.

Speaking of authentication, how do you prove who you are? The most common approach at NZRT is application passwords. Think of it like a special one-time key you generate in your WordPress user profile — separate from your main login password. When you make a request, you pass your username and that application password together. There’s a command-line example that shows this in action: you send a request to the users endpoint asking for your own profile, and you pass your credentials alongside it. If everything checks out, WordPress returns your user data as JSON. OAuth2 is another option if you’re building something more complex that needs delegated access.

Now here’s where things get really powerful — custom endpoints. WordPress lets you register your own API routes, not just the built-in ones for posts and pages. There’s a PHP snippet that shows exactly how this works. You hook into WordPress at the point where the REST API is being set up, then you declare a new route — in this example it lives under a namespace called myapp version one, and the path is slash data. You tell WordPress it should respond to GET requests, point it to a callback function that actually handles the logic, and set a permission callback. In this case the permission is set to always return true, meaning anyone can call it — though in a real-world scenario you’d want to lock that down based on user roles.

So why does all of this matter at NZRT specifically? Your WP-Script plugin is the practical answer. It uses the WordPress REST API as a bridge between WordPress and Dolibarr — your ERP system. When data changes in Dolibarr, whether that’s customer records, invoices, or HR data, WP-Script can pull that through via REST API calls and keep things in sync. External integrations also rely on this same mechanism for data exchange, so anything talking to your WordPress site from the outside is almost certainly going through these endpoints.

If you want to dig deeper, check out the related notes on WordPress Overview, WP-Script Core, and Dolibarr REST API Setup — they’ll give you the full picture of how these pieces connect.

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