All posts by PAM - Products

000DOL, 01 - Product Management

Product Management

Welcome to the NZRT Wiki Podcast. Today we’re looking at Product Management.

Product Management in Dolibarr is the part of the system that controls your full product lifecycle. That means everything from the moment you define what a product is, all the way through to how it sits in your warehouse, how it gets manufactured, and how it moves out the door. If you work with physical goods or services in any structured way, this is the area of the system you will be living in most.

Let’s walk through what Product Management is actually made up of. There are seven sub-modules, and each one handles a distinct part of the product world.

The first is Products and Services, which is your master catalogue. Think of this as the source of truth for everything your business sells or uses. Every item, every service, every component — it lives here first.

The second is Stock and Warehouse Management. This gives you real-time visibility into your inventory. You can see what you have on hand, where it is physically located, and how stock levels are changing as things move in and out.

Third, you have Barcodes. This module handles both the generation and scanning of barcodes, which is useful when you need to speed up receiving, picking, or stocktaking processes.

Fourth is Batches, Lots, and Serials. This one is all about traceability. If you need to track which batch a product came from, when it was made, or which serial number belongs to which unit, this module gives you that level of detail.

Fifth is Product Variants. This is where you manage combinations of things like colour and size. So if you sell a t-shirt that comes in three colours and four sizes, you don’t need twelve separate catalogue entries — you manage it as one product with variants.

Sixth is the Bill of Materials. A Bill of Materials tells the system what components go into making a finished product. It’s the recipe. If you manufacture anything, this is a foundational module because it defines what raw materials or sub-assemblies you need before you can produce the end result.

And seventh is Manufacturing Orders. This is where MRP-driven production happens. MRP stands for Material Requirements Planning, and what that means in practice is the system can look at what you need to produce, check your Bill of Materials, and work out what stock you need to fulfil that production run.

Now let’s talk about how all of this connects together in a typical workflow. The process starts with your Catalogue — you define what you’re making or selling. From there, you move to your Bill of Materials, where you specify what components are required. That feeds into a Manufacturing Order, which triggers the actual production process. Once production is complete, you get a Stock Movement — meaning your finished goods are recorded as entering your warehouse. And then finally, those goods flow out through Sales and Shipping.

So the chain looks like this in practice: you set up your product, you define its recipe, you raise an order to make it, the stock gets updated when it’s done, and then it goes out to the customer. Each step feeds the next, which is what makes this module set so powerful when you have it configured correctly.

It’s also worth noting how Product Management connects to the rest of the Dolibarr system. Customer Orders consume your stock when a sale is made, so the two are tightly linked. Purchase Orders work in the other direction — when your stock is running low, you use Purchase Orders to replenish it from your suppliers. And if you want to understand how profitable your products actually are, the Margins module ties in here too, letting you see product profitability across your catalogue.

So to pull it all together — Product Management is the backbone of your operational system. It’s not just a list of things you sell. It’s a connected set of tools that track what you have, how you make it, what it costs, and how it moves. Whether you’re a product-based business, a manufacturer, or somewhere in between, understanding these seven sub-modules and how they interact will save you a significant amount of time and guesswork.

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

000DOL, 01 - Product Management

Products Services Catalogue

Welcome to the NZRT Wiki Podcast. Today we’re looking at Products & Services Catalogue.

So let’s start with what this catalogue actually is. Think of it as the master reference for everything NZRT sells, buys, or manufactures. If an item appears on an invoice, a purchase order, or a commercial proposal, it lives here first. Every product, every service, every line item has to be defined in this catalogue before it can go anywhere else in the system. It’s the single source of truth for your product and service data.

Now let’s walk through the key fields you’ll encounter when you open up a product or service record. There are several important pieces of information that make each record tick, and understanding them will save you a lot of confusion down the line.

The first field is the Reference. This is the unique product code that identifies the item. No two products share the same reference, so when you’re searching, filtering, or reporting, this is the field that keeps everything unambiguous. It’s essentially the item’s ID across the whole system.

Next up is the Label. This is the display name — the human-readable name that shows up on documents like quotes, invoices, and proposals. Customers see this, so it needs to be clear and descriptive.

Then you have the Type field, and this one is important because it determines how the system handles the item. A product is stock-tracked, meaning the system monitors quantities, movements, and inventory levels. A service, on the other hand, is non-stock — it doesn’t have physical inventory behind it. Think of hours of consulting work versus a physical piece of hardware. Same catalogue, different behaviour under the hood.

After that, you’ve got the Selling Price and the Cost Price. These two fields work together to give you your margin calculation. The selling price is what you charge the customer. The cost price is what it costs you to provide or procure the item. The gap between the two is your margin, and the system uses these fields to surface that for you automatically on reports and proposals.

The VAT Rate field defines the tax rate applied to the item when it appears on invoices and proposals. Getting this right at the product level means you don’t have to think about it every time you raise a document — it just flows through correctly.

The Unit of Measure field tells the system how the item is counted or measured. This could be pieces, kilograms, hours, litres, or any other unit relevant to the item. It’s what appears alongside the quantity on your documents, so again — setting it correctly here saves effort everywhere else.

You’ll also notice two additional fields referenced in the catalogue: Barcodes and Variants. Barcodes are covered in their own dedicated section of the wiki, so if you’re working with physical products and need to assign or scan barcodes, that’s where you’ll find the detail. Variants are similarly covered separately — these come into play when a single product exists in multiple configurations, like different sizes or colours. Both of those topics go deeper than the catalogue overview, so they have their own space.

Now let’s talk about where the Products and Services Catalogue connects to the rest of the system. There are three key areas.

First is Stock and Warehouse Management. Any item typed as a product — meaning it’s stock-tracked — will feed into your stock levels, warehouse locations, and inventory movements. The catalogue is where the item is defined; the stock module is where its physical life plays out.

Second is Bill of Materials. If you manufacture or assemble anything, the Bill of Materials module uses catalogue items as the components. You define what goes into a finished product by referencing other catalogue entries, so a clean, well-maintained catalogue directly supports your production workflows.

Third is Commercial Proposals. When your team puts together a quote for a customer, they’re pulling items directly from this catalogue. The label, the selling price, the VAT rate, the unit of measure — all of it flows from the catalogue record into the proposal automatically. This is why keeping catalogue data accurate is so important — errors here show up directly on customer-facing documents.

So to bring it all together — the Products and Services Catalogue is the foundation layer for almost everything commercial in the system. You define an item once, with the right reference, label, type, pricing, tax rate, and unit, and that definition then powers your invoicing, your stock management, your manufacturing, and your sales proposals. The more accurate and consistent your catalogue entries are, the smoother everything downstream runs.

If you’re new to managing products in the system, start by understanding the distinction between products and services — that Type field really does change how the system behaves. And make sure your reference codes follow whatever naming convention your team has agreed on, because once references are in use on transactions, renaming them gets complicated.

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

000GIT, 02 - GitHub Features

Github Pages

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? GitHub Pages.

So what exactly is GitHub Pages? Put simply, it’s a feature built right into GitHub that lets you host a static website directly from one of your repositories. You don’t need a separate server, you don’t need to manage hosting accounts, and you don’t need to worry about uptime. GitHub handles all of that for you. It’s particularly well suited for project documentation, development blogs, and public portfolios.

Let’s start with the concept of a source. When you set up GitHub Pages, you tell GitHub where to find your website content. You have a few options here. You can point it at a folder called docs inside your main branch, you can use your main branch directly, or you can use a dedicated branch called gh-pages. Whichever you choose, that’s where GitHub looks when it builds your site.

Now, speaking of building, GitHub Pages has a built-in static site generator called Jekyll. Jekyll is what takes your Markdown files and turns them into proper HTML pages. So if you’re writing documentation in Markdown, you don’t have to manually convert anything. You just write your content, push it to your repository, and Jekyll does the rest. You can also skip Jekyll entirely if you prefer to write your own HTML directly.

One of the nicest things about GitHub Pages is that deployment is fully automatic. Every time you push an update to your source branch, GitHub picks it up and rebuilds your site. You do need to factor in a short wait though. Build times typically run somewhere between one and five minutes, so don’t expect changes to appear instantly. Give it a few minutes and then refresh.

Let’s talk about your web address. By default, your site will be available at a github dot io URL based on your username and repository name. But you can also connect a custom domain if you want something more professional. To do that, you point your domain’s DNS records to GitHub Pages’ IP addresses, then configure the custom domain inside your repository settings. Once that’s done, your site is reachable at whatever domain you’ve set up. And on the security side, GitHub Pages automatically provides SSL certificates for github dot io domains, so you get HTTPS without any extra setup.

For NZRT specifically, GitHub Pages opens up some interesting possibilities. There are three potential sites worth thinking about. First, an API documentation site, which would sit at api dot nzrt dot io and could be auto-generated directly from the codebase. Second, an internal docs and guides site at docs dot nzrt dot io. And third, a development blog at blog dot nzrt dot io. All three of these could be maintained as GitHub repositories and deployed automatically whenever content is updated.

So how do you actually get started? There are five steps. First, you go into your repository’s settings on GitHub and enable the GitHub Pages feature. Second, you select your source, so that’s either your main branch with a docs folder, or the gh-pages branch. Third, you either pick one of GitHub’s built-in themes or supply your own custom HTML. Fourth, once it’s live, you access it at the github dot io URL that GitHub assigns you, or at your custom domain if you’ve set one up. And fifth, from that point on, any time you push a change to your source branch, the site redeploys automatically. You don’t need to do anything else.

That’s the core of GitHub Pages. It’s a lightweight, low-maintenance way to get a professional-looking static site live quickly, backed by the same version control workflow you’re already using for your code. For a consultancy like NZRT, it makes a lot of sense as a way to publish API docs or internal guides without adding another tool to the stack.

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

000GIT, 05 - Integrations

WordPress Github Integration

Welcome to the NZRT Wiki Podcast. Today we’re looking at WordPress GitHub Integration.

So let’s start with the big picture. When it comes to the NZRT setup, WordPress and GitHub work together through a combination of webhooks, REST APIs, and GitHub Actions. The key thing to understand is that there are two separate sources of truth here. Code lives in GitHub, and content lives in the WordPress database. Those two responsibilities never cross over, and keeping that distinction clear makes the whole system much easier to reason about.

When you push code, it flows from GitHub through a GitHub Actions pipeline and lands on the WordPress server via SSH. If product data changes in WordPress, a webhook can fire and sync that change over to Dolibarr through its API. Theme files, plugin code, and configuration are all version controlled in git. And you’ve got two environments to work with: the develop branch deploys to staging, and the main branch, via a release tag, deploys to production.

Now let’s talk about how the code itself is organised in the repository. Picture a root folder called dolibarr-custom. Inside that you’ve got a wp-content folder, which contains a plugins folder and a themes folder. Under plugins, there’s a plugin called wp-sync-core, and inside that you’ll find a src folder with three sub-folders for Admin, Frontend, and API logic. Alongside src there are folders for templates, and assets which holds CSS and JavaScript. The plugin’s main entry file sits at the root of that plugin folder, along with a composer.json for PHP dependencies. Back in wp-content, the themes folder holds the nzrt-theme, which contains template parts, assets, a functions file, and a stylesheet. At the very root of the repository you’ll also find the main WordPress config file, an environment variables file, a Docker Compose file for local development, and a readme.

Let’s walk through the product sync flow, because this is where a lot of the integration magic happens. When you edit a product in the WordPress admin, WordPress fires a REST API hook. The wp-sync-core plugin picks up that event and prepares a request for Dolibarr. That request packages up the product name, SKU, price, category, images, and any relevant metadata. It then sends a POST request to the Dolibarr products endpoint to either create or update the record. Once Dolibarr responds, WordPress stores the Dolibarr product ID and a timestamp in its own post metadata, so you always know when a product was last synced and what its Dolibarr identifier is. Finally, the event gets written to an audit trail for traceability.

The PHP code that handles this lives in a class called DolibarrSync inside the API folder of the plugin. It reads the Dolibarr API URL and your API key from the environment, then defines a method that accepts a WordPress product ID. It fetches the product details, builds a payload with the label, price, tax rate, and status, then sends that payload to Dolibarr using WordPress’s built-in HTTP helper. If the request fails, the error gets logged. If it succeeds, the returned Dolibarr ID gets saved back into WordPress meta. Clean, self-contained, and auditable.

Now for the deployment pipeline. The GitHub Actions workflow triggers whenever you push to either the develop or main branch. It starts by checking out the code on a fresh Ubuntu runner, then sets up PHP version eight point one. Next it installs Composer dependencies without the dev packages, then runs a PHP lint check across every PHP file in wp-content to catch any syntax errors before anything hits a server. The deploy step then reads your deploy key from GitHub secrets, writes it to a temporary SSH key file, locks down its permissions, adds the target host to the known hosts file, and finally SSH’s in to run a git pull on the server. The target host is determined automatically: main branch points to production, any other branch points to staging.

For local development, you’re using a Docker Compose setup with two services. One runs the latest WordPress image connected to a MySQL database, maps port eighty through to your host, and mounts your repository folder directly into the web root so changes are instant. The other service runs MySQL eight, creates the dolibarr-custom database on startup, and exposes port three three zero six for direct database access.

That’s the full picture: code in GitHub, content in WordPress, syncing to Dolibarr via the plugin, deployed automatically through Actions, and reproducible locally with Docker.

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

000WOR, 06 - Content & Media

Content Strategy

Welcome to the NZRT Wiki Podcast. Today we’re looking at Content Strategy.

If you work with NZRT’s website or digital content, understanding how everything fits together will save you a lot of time. That’s exactly what today’s episode covers — the thinking behind how NZRT creates, organises, and publishes content across its platforms.

Let’s start with the big picture. NZRT’s content strategy is built around five core ideas. First, content is organised around modules — specifically Dolibarr modules, which are the backbone of NZRT’s business operations. Think of it like each part of the business gets its own dedicated section of the website. Second, visual content plays a major role. You’ll find heavy use of tools like SmartSlider, along with video and imagery woven throughout the site. Third, the strategy goes beyond static pages — it actually pulls in live data from Dolibarr and displays it alongside content, keeping things current and relevant without manual updates every time something changes. Fourth, content is tailored based on who’s reading it. NZRT uses a role-based access approach, meaning the virtual agents — the AI roles that power NZRT’s operations — see content suited to their specific function. And fifth, everything is structured with search visibility in mind, so SEO is baked into the site architecture from the ground up.

Now let’s talk about what kinds of content actually live on the site, because there’s more variety than you might expect.

You’ve got your standard pages — these are the static module pages covering areas like Customer, Sales, Finance, and other core business functions. Then there are blog posts, which handle news, tutorials, and general updates. Video content is a significant part of the mix too — think product demos, how-to tutorials, and customer testimonials in video form. Speaking of testimonials, those are actually their own dedicated content type, separate from blog posts, and they focus specifically on customer success stories. Case studies work similarly — they get their own space for highlighting project outcomes. And finally, there are resources, which cover things like guides, whitepapers, and downloadable documents.

So you’ve got six distinct content types all working together: pages, blog posts, videos, testimonials, case studies, and resources. Each one serves a different purpose in the overall mix.

Now, how does all of this get published in an organised way? That’s where the content calendar comes in. Rather than publishing things whenever they happen to be ready, NZRT plans content on a structured schedule. Module pages get updated as the underlying Dolibarr data changes, so the site stays in sync with what’s actually happening in the business. Blog posts go out either weekly or monthly depending on the period. Video content publishes as it’s produced. And news or announcements go live as needed, so there’s built-in flexibility for time-sensitive information.

The important thing to understand is that this isn’t a generic website content plan — it’s directly tied to how NZRT runs as an organisation. The content structure mirrors the Dolibarr module structure, which means when something changes in the ERP system, there’s a clear update path on the website. The virtual agent roles are also factored into the strategy, so content reaches the right audience at the right level. And all of it ties back to NZRT’s broader business objectives.

If you’re ever figuring out where a piece of content belongs, it helps to ask yourself a few quick questions. Does it relate to a specific Dolibarr module? Then it likely belongs on a module page. Is it informational or educational? That points you toward a blog post or a resource document. Is it demonstrating real-world value — a project outcome or a satisfied client? That’s your case study or testimonial territory.

For anyone who wants to go deeper, the NZRT wiki has closely related notes on the NZRT Site Overview, the Virtual Agents System, and SmartSlider Templates — all of which connect directly to what we’ve covered today.

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

000WOR, 06 - Content & Media

Media Management

Welcome to the NZRT Wiki Podcast. Today we’re looking at Media Management.

If you work with content at NZRT, you are going to be touching media files constantly. Images, videos, documents — they all live in a managed system built around WordPress and a handful of carefully chosen plugins. Today we are going to walk you through how that system works, how files are organised, and what the rules are for different types of media.

Let’s start with the big picture. NZRT uses the WordPress media library as the central hub for uploaded files. On top of that, there are a few key plugins doing important work. Featured Image Plus handles the automatic cropping and sizing of featured images. SmartSlider Three is used for building and displaying hero sliders, including video sliders. There is also a YouTube importer that pulls in video content from YouTube. Together, these tools give you a solid, repeatable workflow for managing visual content across the site.

Now let’s talk about how media is organised, because structure matters here. Every piece of media belongs to a combination of three things. First, a module. The modules at NZRT are Customer, Sales, Finance, HR, Supplier, and EDM. So when you are uploading something, you should know which of those modules the content belongs to. Second, media is categorised by type. That means images, videos, or documents. And third, it is sorted by purpose — whether it is a hero image, a thumbnail, or a background image. Keeping those three dimensions in mind when you upload or label anything will save a lot of confusion later.

On to image sizing, because this is where a lot of people get tripped up. There are three sizes you need to know about. Featured images should be twelve hundred by eight hundred pixels. When you upload at that resolution, the Featured Image Plus plugin will automatically crop and position it correctly wherever it appears on the site. You do not need to manually crop — the plugin handles it for you. Thumbnails are three hundred by three hundred pixels and those are also auto-generated from your upload, so again, you do not need to produce those separately. The third size is the original full-size file. You should always keep this in the library as an archive copy, even if it is larger than what the site currently displays. That archive copy gives you flexibility if requirements change down the line.

Now let’s cover video, because NZRT supports a couple of different approaches depending on where the video lives. If the video is on YouTube, you embed it using the YouTube importer shortcode. You do not download and re-upload YouTube content — you link to it. That keeps file sizes down and lets YouTube handle the streaming. If you have a self-hosted video, that goes in as an MP4 file directly into the WordPress media library, just like any other upload. And if you are working with the hero sliders on the site, those are managed through SmartSlider Three, which can display both image and video content as part of its slider templates.

So where does the actual content live on the back end? There are a few places to know about. First, there is a folder called ColorChart and Images — this is where you will find the module category JPGs and the colour chart PDF that support NZRT’s visual brand standards. Second, there is a SmartSlider folder that holds the images and templates specifically used by the slider plugin. And third, everything that gets uploaded to the site lands in the WordPress media library itself. Those three locations together form the complete picture of where media assets are stored.

Zooming out to the bigger context — all of this media work exists to support NZRT’s content strategy. The goal is consistent visual branding across the site, with imagery that is appropriate for each module and video content that adds value to the pages where it appears. When you follow the organisation structure and the sizing rules, you are not just keeping things tidy — you are making sure the site performs well and looks consistent no matter which page a visitor lands on.

If you want to dig deeper into any of this, the related areas to look at are the Content Strategy documentation, the SmartSlider Templates reference, and the Featured Image Plus notes. Those three resources give you the detail behind the decisions covered in today’s episode.

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

000WOR, 03 - Plugins Reference

Pages With Category Tag

Welcome to the NZRT Wiki Podcast. Today we’re looking at Pages with Category & Tag.

If you’ve spent any time working with WordPress, you’ll know that out of the box, the platform treats posts and pages very differently. Posts get all the organisational tools — categories, tags, archives — while pages are left on their own, floating without any taxonomy support at all. That’s where the Pages with Category & Tag plugin comes in, and today we’re going to walk you through exactly what it does and how NZRT puts it to work.

So let’s start with the problem it solves. When you create a standard WordPress page — think your About page, your Contact page, a Services overview — WordPress gives you no built-in way to group or label those pages with categories or tags. They just exist independently, with no organisational structure connecting them. For a small site with five or ten pages, that’s probably fine. But once you’re managing dozens or even hundreds of pages covering different departments, content types, or business units, that gets messy very quickly.

The Pages with Category & Tag plugin fixes that by bringing the same taxonomy tools you already know from posts and applying them directly to pages. Once it’s active, you can do things you simply couldn’t do before.

Let’s go through the five main features. First, you get page categories. Just like you’d assign a blog post to a category, you can now assign any page to one too. This lets you group related pages together in a logical way. Second, there are page tags. Tags work differently from categories — they’re more freeform and keyword-based — and now your pages can carry them as well, making it easier to surface related content across the site.

Third, the plugin adds archive pages. If you navigate to a category or tag that contains pages, WordPress will now generate an archive view listing all of those pages. This is really useful if someone wants to browse everything within a particular grouping without having to search or click through menus. Fourth, there are taxonomy filters, which let you filter your pages by category or tag — handy when you’re managing content behind the scenes and want to quickly find everything in a particular group. And fifth, you get sidebar widgets for page categories and tag clouds. If you want to show visitors a visual list of page categories or a tag cloud in your sidebar, those widgets are now available to you.

Now let’s talk about how NZRT actually uses this plugin, because that’s where it gets practical for your day-to-day work here.

NZRT uses page categories primarily for module organisation. The modules in play include Customer, Sales, Finance, HR, Supplier, and EDM. So if you’re building out or maintaining pages that belong to one of those business areas, you should be assigning the appropriate page category when you publish. This makes it much easier to manage those sections as the site grows — you can quickly pull up all Finance pages, for example, or filter to see everything under HR without digging through the entire page list manually.

Beyond modules, NZRT also uses page categories for department pages, so pages that belong to a specific internal team or division get categorised accordingly. There’s also provision for regional pages, which would apply if content needs to be segmented by geographic area. And finally, content type pages fall into this system too — things like case studies and testimonials get grouped under their own category so they’re easy to find and manage as a distinct content type.

The core idea behind all of this is that WordPress pages, as powerful as they are for building a structured site, benefit enormously from some extra organisational scaffolding once the volume of content grows. The plugin provides that scaffolding without changing how pages fundamentally work. You’re not rethinking your page structure — you’re just adding a layer of taxonomy on top of what you already have.

If you’re ever adding new pages to the NZRT WordPress site, keep this in mind: check whether the page belongs to one of the established categories before you publish. Leaving pages uncategorised works against the whole point of having this plugin active. And if you think a new category might be needed — say for a new business unit or content type — that’s worth flagging with the team rather than creating unofficial categories without alignment.

This plugin sits alongside other tools documented in the NZRT wiki, including notes on post types and taxonomies more broadly, page structure and navigation, and the general plugins overview. Those are all worth a read if you want the fuller picture of how the WordPress setup here is organised.

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

000WOR, 03 - Plugins Reference

Plugins Overview

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

If you’re working with the NZRT WordPress setup, this episode gives you a clear picture of the plugin ecosystem that keeps everything running. There are nine active plugins in total, and they cover four main areas: media management, data import, navigation, and content flexibility. One thing worth noting right up front is that Dolibarr integration is handled separately through agent REST API calls using the nzrt-tools MCP server, so there is no plugin bridge needed between WordPress and Dolibarr. That’s all taken care of at the agent layer.

Now let’s walk through the nine plugins one by one so you know what each one does.

First up is SmartSlider3 Pro, made by Nextend. This one handles your hero sliders and image galleries. If you see a visually polished sliding banner on an NZRT page, that’s SmartSlider3 doing its job.

Next is JC Importer. This is a CSV and data import utility, originally from the Joomla ecosystem but used here on the WordPress side. When you need to bring in bulk data from a spreadsheet or CSV file, this is your tool.

Third is Menu Icons, made by Icomoon. This gives you an icon-based menu system, so you can add visual icons alongside your navigation menu items instead of plain text links.

Fourth is YouTube Mass Videos Importer. The name tells you exactly what it does — it lets you embed large numbers of YouTube videos in bulk rather than adding them one at a time.

Fifth is Featured Image Plus, made by Pix. This extends WordPress’s default featured image handling with additional options, giving you more control over how thumbnail and hero images behave across different post types.

Sixth is Pages with Category and Tag. By default, WordPress doesn’t let you apply categories and tags to pages, only to posts. This plugin adds that taxonomy support so your pages can be organised the same way your posts are.

Seventh is Post Type Switcher, made by johnbillion. This is a conversion utility that lets you change a piece of content from one post type to another, for example turning a post into a page or vice versa, without having to recreate it from scratch.

Eighth is WPCat2Tag Importer. This one handles category-to-tag migration, which is useful when you want to reorganise your taxonomy and move items that were filed under categories into tags instead.

And ninth is the Kadence theme, made by Kadence WP. While technically a theme rather than a plugin, it’s listed here because it functions as the flexible block-based foundation the site is built on and is managed alongside the plugin stack.

All nine of these are currently active.

Now, if you ever need to install or reinstall any of these, the plugin zip archives are stored in the NZRT vault. The folder structure there mirrors the plugin names, so you have subfolders for the video embedder, featured image plus, JC Importer, menu icons, the SmartSlider3 Pro package, pages with category and tag, post type switcher, WPCat2Tag importer, and the YouTube mass videos importer. To activate any of them, you go to WordPress Admin, then Plugins, then Add New, and use the Upload Plugin option to push the zip file directly.

To put the full picture together, it helps to think of the plugins in four groups. For media, you have SmartSlider3 Pro, the YouTube importer, and Featured Image Plus. For content organisation, you have Pages with Category and Tag, WPCat2Tag Importer, and Post Type Switcher working together to give you a flexible taxonomy system. For admin and data tasks, JC Importer handles bulk data ingestion and Menu Icons tidies up the navigation. And as mentioned at the start, Dolibarr sits outside this plugin layer entirely, connected through the agent REST API rather than any WordPress-side bridge.

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

000WOR, 03 - Plugins Reference

Post Type Switcher

Welcome to the NZRT Wiki Podcast. Today we’re looking at Post Type Switcher.

If you’ve spent any time managing a WordPress site, you’ve probably run into this situation. You’ve got a blog post that really should be a page, or a page that belongs in a custom post type, and you’re staring at it wondering how to move it without breaking everything. That’s exactly the problem Post Type Switcher solves.

At its core, Post Type Switcher is a WordPress plugin that lets you convert content from one post type to another. So if you’ve written something as a standard blog post and you later realise it actually belongs in your custom post type for case studies, or testimonials, or module pages, you can make that change without losing a single thing. Your content stays intact, your metadata stays intact, your comments stay intact. It just lives under a different post type.

Let’s talk about what the plugin actually gives you. There are five main capabilities worth knowing about.

The first is what the plugin calls Quick Convert. This is a one-click conversion experience. You’re inside a post or page, you make your selection, and the switch happens. No complicated workflow, no export and reimport dance.

The second is Bulk Convert. Rather than opening posts one at a time, you can select multiple pieces of content and convert them all at once. If you’re doing a bigger site reorganisation, this saves a lot of time.

Third is what’s described as Safe Conversion. This is probably the most important one to understand. When you switch a post from one type to another, everything that belongs to that post comes with it. The content itself, the custom fields and metadata, the comment threads. Nothing gets left behind.

Fourth, there’s Hierarchy Support. If you’re working with post types that have parent and child relationships, those relationships are preserved through the conversion. So if you had nested pages or structured content with a parent, that structure stays coherent after the switch.

And fifth, Status Preservation. When you convert a post, it keeps whatever publishing status it had. If it was published, it stays published. If it was a draft, it stays a draft. You’re not accidentally taking live content offline just by changing its type.

Now let’s look at how NZRT actually uses this. There are four main use cases documented for us.

The one you’ll probably encounter most is converting blog posts into module pages. If the team has written something as a news post or a blog entry and it turns out it really belongs as a structured page inside a specific site module, Post Type Switcher handles that transition cleanly.

Similarly, if a page needs to become a product, that’s a straightforward conversion. Same goes in the other direction. The plugin doesn’t care which way you’re going.

The other two use cases are about converting standard posts into testimonials or case studies. These are typically custom post types, and getting content into the right type means it shows up in the right templates and feeds. Rather than recreating a post from scratch inside the correct type, you just switch it.

The underlying reason all of this matters for us is content structure. When you’re running a site with multiple custom post types, it’s easy for content to end up in the wrong bucket, especially early in a project when the structure is still being defined. Post Type Switcher gives you a way to correct that without a data migration headache.

It’s also worth noting what the plugin does not do. It’s not changing your content, it’s not reformatting anything, and it’s not touching your taxonomies or terms in ways that would break associations. It’s genuinely just moving the post from one type to another while keeping everything else as is.

If you want to dig deeper into how post types work in WordPress generally, the wiki cross-references a note on Post Types and Taxonomies, as well as the broader Plugins Overview and WordPress Overview pages. Those are good places to go if you need context on how the ecosystem fits together.

The short version is this. Post Type Switcher is a simple, safe utility that gives you flexibility when your content structure evolves. And in a managed WordPress environment like ours, that kind of flexibility is genuinely useful.

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

000WOR, 01 - WordPress Core

Post Types Taxonomies

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.

000WOR, 01 - WordPress Core

WordPress Overview

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.