Tag Archives: 000WOR

000WOR, 08 - Security & Maintenance

Ad Code Management

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

So, if you’ve ever wondered how NZRT brings advertising into its WordPress site, this episode walks you through exactly that. Advertising is one of the ways NZRT generates revenue, and managing ad code properly keeps things running smoothly without hurting the experience for your visitors.

Let’s start with how ads actually get onto the site. There are four main ways to integrate ad code into a WordPress setup. The first is through the header or footer of the theme. This is what you’d call a global placement — any code you drop in there runs across every page on the site. The second method is placing ads within the content itself, so they appear inside posts as readers scroll through. Third, you can use sidebar widgets to display ads in the sidebars of pages. And fourth, there are dedicated ad plugins. NZRT uses plugins like Ad Inserter, AdThrive, and Mediavine depending on the situation — these give you more fine-grained control over where and when ads appear.

Now, where does all that ad code actually live? NZRT stores ad codes securely in a file called Ad code dot m d, found inside the Text folder. That file is the central reference point for everything ad-related. It holds the Google AdSense code, any codes from direct advertisers NZRT works with, custom tracking pixels for monitoring ad performance, and consent or privacy scripts that need to load alongside the ads.

Speaking of privacy — this is a big one. Ad compliance isn’t optional, and there are a few things you always need to keep in mind. You must include privacy notices and opt-out links so your visitors know what data is being collected and how they can say no. You need to respect GDPR and CCPA regulations — these are the major privacy laws covering users in Europe and California respectively, and they apply regardless of where your site is hosted if you’re serving visitors in those regions. If you’re running sponsored content, you need to disclose it clearly — there’s no hiding that something is a paid placement. And finally, cookie consent management needs to be in place, because most ad networks use cookies to track and target users.

Within the NZRT context, ad code management sits with the site admin, which is xc. The goal is straightforward — ads bring in revenue while keeping the site experience as clean and trustworthy as possible for visitors. It’s a balancing act, and having everything centralised in that Ad code file means there’s always one place to go when something needs updating or auditing.

If you want to dig deeper, there are two related areas worth looking at. The Security Overview note covers how sensitive code and credentials are handled across the site more broadly, and the NZRT Site Overview gives you the bigger picture of how all the moving parts of the WordPress setup fit together.

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

000WOR, 06 - Content & Media

Colorchart Reference

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🎨 ColorChart Reference.

So let’s talk about how NZRT keeps its visual identity consistent across everything it builds and publishes. If you’ve ever wondered why certain pages, modules, or design elements feel like they belong together, the answer lives in the NZRT color chart. The master reference for all of this is a document called ColorChart dot PDF, sitting inside a folder called ColorChart and Images. That’s your go-to source whenever you need an exact color value.

Now, NZRT organizes its colors into a few distinct groups, and it’s worth understanding what each group is for. First, you have the primary brand color. This is the main color that represents NZRT as a whole — think of it as the anchor of everything visual. Then there’s a secondary accent color, which is used to complement the primary without overpowering it. After that, you’ve got a range of neutral grays. These handle the everyday stuff — body text, backgrounds, anything where you want to support the content rather than compete with it. And finally, there are module-specific colors, which is where things get really practical for day-to-day work.

Let’s walk through those module colors, because this is probably the part you’ll reference most often. Each module in Dolibarr has its own associated color to help users quickly orient themselves visually. Customer and Sales work uses blue. Finance and Accounting is green. HR Management is purple. Supplier and Purchase functions are orange. Product Management uses red. And the EDM module, which handles electronic document management, is represented by gray.

So how do you actually apply all of this in practice? There are four main usage guidelines to keep in mind. For primary elements — things like calls to action, links, and headers — you use the primary brand color. That’s what draws the eye and guides the user toward action. For module pages, you pick up the module-specific color and use it for page accents, giving users that instant visual cue about where they are. For text, neutral gray is your friend for body copy, while headings shift to black for maximum readability and contrast. And for backgrounds, you stick with white or light gray — this keeps things clean and easy to read without any visual noise competing with the content.

Why does all of this matter for NZRT specifically? Because the color chart isn’t just about making things look nice. It’s the glue that holds visual consistency together across three key areas. First, the NZRT WordPress site. Second, SmartSlider templates, which are used for dynamic visual content. And third, the theme customization layer that sits underneath everything. When all three of these are pulling from the same color definitions, you get a cohesive experience whether someone is reading a blog post, looking at a slideshow, or navigating the Dolibarr interface.

If you want to explore further after this, there are three related notes in the wiki worth checking out. Color Scheme and Branding gives you the broader branding context. RetroTube Theme covers the WordPress theme layer. And SmartSlider Templates shows you how these colors get applied in practice within the slider tool. Together with the ColorChart PDF, those four resources give you the full picture.

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, 05 - Dolibarr Integration

Dolibarr Rest Api Setup

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

So let’s talk about how you actually talk to Dolibarr programmatically. Dolibarr ships with a built-in REST API, and that’s the primary way AI agents at NZRT reach into the ERP to read and write data. There’s no WordPress middleman here, no sync scripts running on a schedule — agents call the API directly, on demand, using their own credentials.

First, let’s orient you to where the API lives. The base URL follows a predictable pattern: you start with your Dolibarr server’s domain, then the path goes through the API index file, followed by a version segment. In NZRT’s case the live server is at erp.nzrtnetwork.com, but the pattern is the same wherever you host Dolibarr — domain, then api/index.php, then the version.

Now, what can you actually reach through this API? There’s a solid set of core endpoints. You can list all customers, or pull a single customer by their ID. Same story for invoices — list them all, or drill into one specific invoice. Products work the same way. You can also list HR employees and pull supplier records. So whether you’re building a finance agent that needs to check unpaid invoices, or a customer-facing agent that needs to look up account details, the API has you covered with a clean, predictable URL structure where you swap in the resource name and optionally add an ID.

Authentication is straightforward. Every request needs an API key passed in as a request header. The header name is DOLAPIKEY — spelled out in capitals — and the value is the key itself. So if you imagine a simple HTTP request to fetch customers, you’d attach that header, point the request at the customers endpoint, and Dolibarr handles the rest. You never send a username and password on each call — just that single API key header every time.

Now, where do those API keys live? You need to generate them from the Dolibarr admin panel, and you’ll store a few pieces of information: the endpoint URL itself, the API key, and optionally the username of the Dolibarr user the key belongs to.

Here’s how NZRT specifically handles this, and it’s worth paying attention to because it differs from a generic Dolibarr setup. Credentials are per-agent. Each AI agent in the NZRT stack — so that’s agents like cas, fin, han, and the others — holds its own individual API key. Those keys are scoped to match the module permissions that agent actually needs. A finance agent gets access to invoice and payment endpoints. A customer-facing agent gets access to customer records. They don’t all share one admin-level key. This keeps permissions tight and makes it easy to revoke or rotate a single agent’s access without touching the others.

All those per-agent credentials are stored in Nextcloud, under the Shared CREDS folder. If you’re setting up a new agent or rotating a key, that’s where you go to find and update the relevant credential file.

One more thing worth flagging: agents call the API on demand, in response to tasks or queries. There’s no background WordPress sync happening, no webhooks firing on a timer. When an agent needs data, it makes the call. When it doesn’t, nothing moves. That keeps the integration simple, auditable, and easy to debug — if something went wrong, you check the agent’s API call, not a background job running somewhere in WordPress.

If you want to go deeper, the related topics to look at are the WP-Dolibarr Integration Overview, the WP-Script Core documentation, and the WordPress Pages Map — those will give you the bigger picture of how Dolibarr connects to the rest of the NZRT stack.

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

000WOR, 03 - Plugins Reference

Featured Image Plus

Welcome to the NZRT Wiki Podcast. Today we’re looking at Featured Image Plus.

If you’ve spent any time managing a WordPress site, you’ve probably run into the limitations of the default featured image system. It works, but only just. You get one image, one size, and very little control over how it gets cropped or displayed across different parts of your site. Featured Image Plus is a WordPress plugin that steps in to fix exactly that problem, and at NZRT we use it to keep our media management consistent and efficient across the board.

So let’s start with what the plugin actually does, and then we’ll walk through how we use it specifically at NZRT.

The first thing Featured Image Plus adds is support for multiple crops. By default, WordPress generates a handful of image sizes when you upload a photo, but you don’t have much say over how those crops are defined or how they apply to featured images specifically. With Featured Image Plus, you can define multiple featured image sizes tailored to wherever those images are going to appear. That means a hero banner, a thumbnail in a post grid, and a social share preview can all pull from the same source image but get their own perfectly cropped version. You define the sizes once, and the plugin handles the rest.

Next up is Quick Edit support. If you’ve ever needed to swap out a featured image on a post, you know that the default workflow sends you into the full post editor just to make that one change. With Featured Image Plus, you can edit the featured image directly from the posts list view. You hover over the post, hit Quick Edit, and you’re done. No need to open the full editor, save, and navigate back. For day-to-day content management, this saves a surprising amount of time.

Related to that is Bulk Edit. If you’ve ever had to update featured images across a large number of posts at once, you’ll appreciate this one. Whether you’re rebranding, cleaning up old content, or switching image sets after a campaign, you can select multiple posts and change their featured images in one go. No clicking through post after post.

The plugin also includes an Image Resizer, which automatically crops your uploaded images to the optimal dimensions for each defined size. So instead of you manually resizing images before uploading them, the plugin takes care of that step. You upload once, and it generates the right crop for every context you’ve set up.

Finally, there’s Gallery Support. This one’s a bit different. If a post doesn’t have a dedicated featured image set, Featured Image Plus can pull an image from an embedded gallery within that post and use it as the featured image automatically. This is handy for image-heavy posts where the gallery content is the main visual.

Now let’s talk about how we actually use this at NZRT, because the plugin’s value is in how you configure it, not just that you install it.

One of our primary use cases is defining a standard featured image size for SmartSlider. If you’ve heard our episode on SmartSlider 3 Pro, you’ll know it’s the slider tool we use across the site. SmartSlider pulls featured images as slide backgrounds, and it needs images at a specific aspect ratio to look right. Featured Image Plus lets us lock that size in so every featured image is automatically cropped to work perfectly in the slider without any manual intervention each time someone publishes a post.

We also use it for product images. When product photos are uploaded, Featured Image Plus auto-crops them to our standard product dimensions. That keeps the product grid visually consistent without requiring whoever is doing the upload to think about sizing.

Another thing we’ve set up is a default image fallback for posts that don’t have a featured image assigned. Instead of a blank space or a broken layout, the site automatically shows a defined default. This is particularly useful for older content or imported posts that might not have had featured images attached in the original source.

Speaking of imports, the Bulk Edit feature comes into its own during content migration. When we bring in posts from another system, they often come in without featured images or with images that need to be swapped out. Being able to select a batch of imported posts and apply the right featured image across all of them in one action is a genuine time-saver during those migration workflows.

So to summarise, Featured Image Plus gives you multi-size crop control, faster editing from the posts list, bulk image management, automatic resizing on upload, and gallery fallback support. At NZRT, we’ve wired it into our SmartSlider setup, our product catalogue, our default image configuration, and our import processes. It’s one of those plugins that quietly does a lot of heavy lifting once it’s configured properly.

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

000WOR, 01 - WordPress Core

Hooks Filters

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.

000WOR, 08 - Security & Maintenance

Backup Strategy

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

So, NZRT runs regular backups of its WordPress site covering both the database and the actual files. The goal is straightforward: if something goes wrong, whether that’s data loss, a hack, or corruption, you want to be able to recover quickly and confidently.

Let’s start with what gets backed up and how often. There are four main components. First, the database, which is backed up every single day and kept for thirty days. Second, the WordPress files, also daily with thirty days of retention. Third, the uploads folder, again daily, thirty days. And fourth, plugins and themes, which are backed up weekly and kept for twelve weeks. The daily items use tools called mysqldump, rsync, and tar, while the weekly plugin and theme backups use git or zip archives.

All of these backups land in a directory called Back-ups. Inside that folder you’ll find database dump files, compressed WordPress file archives, incremental backups, and restore scripts, so everything you need to recover is kept together in one place.

Now let’s talk about how the backups are actually made. For the database, the process runs a command that connects to the WordPress database as the root user and exports everything into a single file. The filename automatically includes today’s date, so you always know exactly when each backup was taken.

For the files, the process creates a compressed archive of the entire WordPress directory. Again, the filename gets today’s date stamped into it automatically.

On the production server specifically, there are a couple of key backup locations. WordPress archives live in a dedicated wordpress-backups folder on the server, and these are primarily managed by a tool called JetBackup, which runs automatically and is handled by the hosting provider. You can also trigger on-demand backups through cPanel’s Backup Wizard if you need one right now. If you want to browse or download these production archives from Windows, you can open a special WebDAV network path in Windows Explorer that connects directly to that wordpress-backups folder over a secure connection.

One important security point here: that wordpress-backups folder must never be publicly accessible from the internet. You can verify this by sending a request to the URL of that folder. If everything is configured correctly, the server should respond with a four-oh-three Forbidden status. If you get anything else back, that’s a problem that needs to be addressed immediately, because publicly accessible backups could expose sensitive data.

Now, what about restoring from a backup? If you need to restore the database, you run a command that reads a specific backup file and imports it directly into the WordPress database. You reference the backup by its date in the filename, so for example you’d point it at the file from the twelfth of April twenty twenty-six. For restoring the files, you extract the compressed archive back to the root of the server. Again, you reference the dated backup file you want to restore from.

Finally, in terms of who owns all of this at NZRT, that’s dan, the DBA. Dan is responsible for backup and recovery, so if you have questions or need to initiate a restore, that’s your first point of contact.

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

000WOR, 03 - Plugins Reference

Jc Importer

Welcome to the NZRT Wiki Podcast. Today we’re looking at JC Importer.

JC Importer is a utility plugin for WordPress, and at NZRT we use it whenever we need to bring in large amounts of data without doing it all by hand. Specifically, it gives you the ability to import posts from CSV files, create users in bulk, map your data columns to the right WordPress fields, preview what you’re about to import before you commit to it, and catch duplicate entries before they cause problems. Those five capabilities cover most of the heavy lifting you’d ever need to do when populating or updating a WordPress site with external data.

So how does it actually work in practice? The process runs in five steps, and they’re pretty straightforward. First, you upload your CSV file into the plugin. Second, you tell the plugin how your columns match up to WordPress fields — so for example, which column in your spreadsheet is the post title, which one is the content body, which one is the author, and which one holds the category. Third, and this is the part that saves a lot of headaches, you run a preview. It shows you a sample of five rows so you can confirm everything is mapped correctly before anything actually gets written to the database. Fourth, once you’re happy with how it looks, you execute the full import. And fifth, you go through the results and check the error log to see if anything didn’t make it through cleanly.

Now, why does NZRT actually reach for this tool? There are four main situations where it comes in handy for us. The first is when we’re pulling product listings out of Dolibarr — our ERP system — and we need to get those into WordPress in one go rather than entering them one by one. The second is when we need to create a whole set of pages for module categories in bulk. The third is when HR data needs to come across into WordPress, like employee information that originates in Dolibarr’s HR module. And the fourth is when we need to update pricing and product descriptions across a large number of entries at once — again, doing that manually would take far too long.

The common thread across all of those use cases is that you’ve got structured data living somewhere outside WordPress — usually in a spreadsheet or a Dolibarr export — and you need a reliable, repeatable way to get it into the site without risking errors from manual entry or wasting time on repetitive copy-paste work.

If you want to dig deeper into the broader context around this plugin, there are a few related wiki notes worth checking out: the Plugins Overview, the WordPress Overview, and the NZRT Site Overview. Those will give you a fuller picture of how JC Importer fits into the wider stack.

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

000WOR, 09 - Reference

License Keys

Script below.

—

Welcome to the NZRT Wiki Podcast. Today we’re looking at License Keys.

If you’ve ever managed a WordPress site or a suite of web tools, you know that keeping track of license keys can quietly become a headache. NZRT has a simple but important system for handling this, and today we’re going to walk through exactly how it works.

First things first. NZRT stores license keys for premium plugins and software in a secure, dedicated location. Specifically, you’ll find all the current keys documented in a file called WP-Script license key dot m-d, which lives inside a folder called Text. Think of this as your single source of truth for any licensed software NZRT uses. Rather than hunting through emails or plugin dashboards, you go to that one file and you’ve got what you need.

Now, let’s talk about what software is actually covered. There are four categories in the licensed software list, and here’s how they break down.

First up is SmartSlider3 Pro. This is a commercial license, renewed annually. You’ll find the key stored in that Text file we just mentioned.

Second is WP-Script Core. This one runs on a custom license arrangement rather than a standard commercial model, so renewal terms are handled on a case-by-case basis. The key is stored in the same place as the others.

Third is the RetroTube Theme. Like SmartSlider3, this is a commercial license with annual renewal, and the key lives in that same file.

And fourth, there’s a catch-all category for other plugins. These tend to be either GPL-licensed or premium, and rather than centralising their keys in the Text file, you’ll typically find them inside the individual plugin folders themselves. Renewal schedules vary across this group, so it’s worth checking each one on its own terms.

So that’s the software landscape. Four categories, one main key file covering the big three, and plugin folders for the rest.

Now let’s talk about how NZRT actually manages these licenses day to day. There are four core practices worth knowing about.

The first is secure storage. Keys are kept either encrypted or behind access controls. You don’t want license keys sitting in plain text somewhere public-facing, so the system is set up to keep them protected.

The second is tracking renewal dates. Annual licenses especially need to stay on your radar. If SmartSlider3 or RetroTube lapses, you lose access to premium features and potentially to updates as well, so keeping an eye on those renewal windows matters.

Third, when a license does expire, the process is straightforward. You update the key. That sounds obvious, but having a clear record of where all your keys are stored makes that update quick and painless rather than a scramble through old inboxes.

And fourth, verifying license validity. This is about confirming that the keys you have on file are actually active and working, not just that they exist somewhere. A key sitting in a text file doesn’t help you much if it was quietly deactivated at the provider’s end.

From an organisational standpoint, license key management at NZRT sits with the admin, which is the xc role. So if you’re working on the site and you need access to a key, xc is your point of contact. The currently active keys are what power premium features like SmartSlider3 and WP-Script, so keeping them in good order is genuinely important to how the site functions.

If you want to explore related topics, this wiki area connects to three other notes. The Security Overview gives you broader context around how NZRT handles sensitive information. The Plugins Overview covers the full plugin ecosystem, which is useful if you’re trying to understand which plugins are GPL versus premium. And there’s a dedicated SmartSlider3 Pro note if you want to go deeper on that specific tool.

To pull it all together: NZRT keeps its license keys in a single secure file for the main licensed software, covering SmartSlider3 Pro, WP-Script Core, and the RetroTube Theme. Other plugin keys live in their respective plugin folders. Good management comes down to four things: storing keys securely, tracking renewal dates, updating keys when they expire, and verifying they’re still valid. And all of that is administered by xc.

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

Menu Icons

Welcome to the NZRT Wiki Podcast. Today we’re looking at Menu Icons.

If you’ve ever visited the NZRT website and noticed those clean, recognisable symbols sitting beside each navigation link, you’ve already seen Menu Icons in action. Today we’re going to walk through what the plugin does, how it’s set up, and why NZRT uses it the way it does.

So first, what is Menu Icons? It’s a WordPress plugin that adds icon support to your menu items. Out of the box, WordPress menus are just text links. Menu Icons layers on top of that and gives you the ability to attach a visual icon to any item in your navigation. NZRT uses it specifically for the primary menu and for module page links, giving the site a more visual, icon-based navigation feel rather than relying on text alone.

Let’s talk about what the plugin actually brings to the table. It ships with over one thousand icons drawn from two popular icon libraries — Font Awesome and Icomoon. That’s a substantial library, so you’re unlikely to run out of options for whatever navigation concept you’re trying to represent. Alongside the icon library, there’s a built-in icon picker that lives right inside the WordPress menu editor. So when you’re setting up or editing your menu, you don’t need to leave the screen or fiddle with code — you just click, browse, and pick the icon you want.

Beyond simply attaching an icon, you also have control over how that icon looks. You can set a custom colour for each icon, which is important for NZRT’s approach. You can also configure the size of the icon, so it fits proportionally with your menu text and overall layout. And there’s tooltip support as well — meaning if a visitor hovers over an icon, you can display a short explanatory label, which is handy for accessibility and clarity, especially if the icon is being used without visible text beside it.

Now let’s look at how NZRT actually sets this up. The process happens inside the WordPress admin area, in the menu management section. The first step is adding your menu items — these are the different modules or sections of the site, things like Customer, Sales, Finance, and so on. Once your items are in the menu, you go through each one and select the appropriate icon using that built-in icon picker we just mentioned. The key instruction here is to use the module colours when making your icon choices. So when you’re picking an icon for Finance, for example, you’d set the icon colour to match the Finance module’s brand colour. The same goes for every other module. Finally, you configure the tooltip text for each item — that’s the little label that appears on hover.

That colour-matching rule is worth pausing on, because it reflects a deliberate design decision. Rather than having a navigation bar full of icons in a single default colour, NZRT maps each icon’s colour to the visual identity of its corresponding module. This means that when you’re looking at the menu, you’re not just reading text labels — you’re also getting a colour signal that matches what you’ll find when you land on that module’s pages. It’s a small touch, but it creates a more cohesive visual experience across the site.

Speaking of those modules, let’s run through what’s actually in the NZRT primary navigation. There are six main items using icons. You’ve got Products, Customer Management, Finance, HR, Suppliers, and EDM. Each of those has its own icon and its own colour pulled from the corresponding module’s brand palette. Together they make up the icon-based navigation that visitors use to move around the NZRT site.

The reason NZRT leans into this icon-first approach comes down to user experience and visual module association. Icons give users an immediate visual cue that helps them orient themselves quickly. Rather than scanning through a list of text labels, visitors can pick up on the icon and colour combination and navigate more intuitively. For a site that covers multiple business modules — each with its own identity — that visual differentiation is genuinely useful.

If you want to dig deeper into how this fits into the broader site structure, there are a few related areas worth reading. The Page Structure and Navigation doc covers how pages are organised and linked together. The NZRT Site Overview gives you the big picture of how all the pieces of the site connect. And the Plugins Overview is a good place to see where Menu Icons sits alongside the other tools in the WordPress setup.

So to recap — Menu Icons is a straightforward but effective plugin that brings icon selection, colour control, sizing, and tooltips into your WordPress menu editor. NZRT uses it to give the primary navigation a visual, module-aware feel, with icons and colours matched to each section of the site.

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

000WOR, 10 - NCS Website

Ncs Intake Form

Welcome to the NZRT Wiki Podcast. Today we’re looking at NCS Intake Form.

The NCS Intake Form is the public-facing form on the NZRT website that charitable services applicants use to get in touch. It’s powered by the nzrt-dolibarr-bridge WordPress plugin, and the whole point of it is to save time — when someone submits the form, everything gets created in Dolibarr automatically. No one on the NZRT side has to manually enter anything.

So how do you get the form onto a WordPress page? You use a shortcode. Shortcodes in WordPress are small pieces of text you drop into a page or post, and WordPress replaces them with actual content when the page loads. The shortcode for this form is simply the words nzrt intake form wrapped in square brackets. Place that on any WordPress page and the form appears, ready to go.

Now, one thing worth knowing about how this form works under the hood — it uses something called AJAX. That means when a visitor hits Submit, the page does not reload. The form submits silently in the background and the user just sees a thank-you message appear right there on the page. It’s also nonce-protected, which is a WordPress security mechanism that prevents certain types of cross-site request forgery attacks.

Let’s walk through the full technical flow from the moment someone clicks Submit. First, the visitor fills in the form and submits it. Second, JavaScript sends the form data behind the scenes to a WordPress endpoint, triggering an action called nzrt intake submit. Third, on the PHP side, the nonce gets validated to confirm the request is legitimate, and then the form data is sent to the Dolibarr API to create a new thirdparty record — that’s Dolibarr’s term for a contact or organisation. Fourth, Dolibarr responds with an ID for that newly created thirdparty. Fifth, a second API call goes out to create a support ticket in Dolibarr, filed under the NCS charitable services category and linked to that thirdparty. Sixth, PHP sends an email to Nathan with a summary of the application. And seventh, the user sees a thank-you message on the page — no redirect, no wait.

Now let’s talk about what the form actually collects. There are four fields. The first is Organisation Name, which maps to the name field in Dolibarr. The second is Email, which maps to the email field. The third is Phone, which maps to the phone field. And the fourth is Message, which gets stored as a private note on the thirdparty record in Dolibarr. Private notes in Dolibarr are internal-only — they’re not visible to the applicant.

In terms of setup, the plugin file is called nzrt-dolibarr-bridge dot php and it lives in the 000WOR repository. To configure it, you go to WP Admin, then Settings, then Dolibarr Bridge. There you set two things: the API URL, which points to the Dolibarr installation, and the API key that authorises the connection. There’s also a product sync option in there, but that’s optional and not required for the intake form to work.

What happens after someone submits? Nathan receives the email summary and reviews the application manually. If he wants to approve it, he replies to that email with the words APPROVED colon services. That reply triggers the automated delivery pipeline — specifically two scripts called mail handler dot py and cas ncs delivery dot py — which handle the next steps in fulfilling the charitable services request. The full details of that post-submission process are documented separately in the standard operating procedure called SOP-NCS-001, so if you need to follow that through end to end, that’s where to look.

To summarise what you’ve learned today: the NCS Intake Form is a WordPress shortcode-driven form that collects basic organisation details from charitable applicants. It submits via AJAX with CSRF protection, automatically creates a Dolibarr thirdparty and support ticket, and fires off a notification email to Nathan. Configuration lives in WP Admin under the Dolibarr Bridge settings, and the plugin is managed in the 000WOR repo. The form is designed so that nothing falls through the cracks — every submission leaves a clean record in the ERP system without any manual data entry.

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

000WOR

Nzrt Agent Blog

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Agent Blog.

So what is the NZRT Agent Blog? It’s a local WordPress blog where each of the NZRT virtual agents publishes plain-English summaries of articles from the Obsidian vault — the internal wiki. These summaries are assigned to agents through the Dolibarr ticketing system, and the whole thing lives at the local WordPress address used during development.

Let’s talk about the agents involved and how they’re set up in WordPress. There are seven agents who post to this blog. You’ve got cas, who covers Customer and Sales; dai, who handles Data and Analytics; ema, who takes care of EDM; fin, who covers Finance; han, who looks after Human Resources; pam, who manages Products and Marketing; and sun, who handles Supplier and Purchase. Each agent has their own dedicated WordPress category that matches their domain.

Now, not all agents have the same level of access. Some agents — cas, dai, ema, pam, and sun — have the editor role, which means they can publish posts directly. The other two — fin and han — have the contributor role, which means they write and submit drafts, but a human administrator needs to come in and hit publish. Two agents, dan and cla, don’t have WordPress accounts at all — dan works at the database level, and cla operates through the Claude API.

When it comes to how a post should look, there’s a consistent format across the board. The post title should match the original vault article title. The body of the post is a summary — somewhere between three hundred and five hundred words — written in plain English so anyone can understand it, not just someone who’s already read the original vault article. Each post gets filed under the agent’s category, and it picks up a couple of standard tags: wiki-summary and wiki, plus any tags that are relevant to the agent’s specific domain. And at the bottom of every post, there’s a footer that links back to the original article in the vault, so readers can go deeper if they want to.

How does an agent actually get assigned to write one of these posts? It all flows through Dolibarr. You run a script called create blog ticket dot py, and you pass in the agent code, the topic you want summarised, and a path to the relevant vault article. In plain terms, you’re telling the system which agent should do the work, what the subject is, and where to find the source material. The script creates a ticket in Dolibarr under a ticket type called Wiki Blog Summary, and it gets assigned directly to that agent. The ticket also picks up tags that match the topic and the agent’s domain.

Once the ticket is created, the workflow is pretty straightforward. The agent reads the original vault article, writes the summary post, and either publishes it directly if they have editor access, or submits it as a draft if they’re a contributor. Either way, when the work is done, the agent marks the Dolibarr ticket as Resolved and includes the URL of the published post. If the post is still sitting as a draft — because fin or han wrote it — you as the administrator come in and publish it.

A quick note on the WordPress setup itself: the blog uses the twentyfourteen theme, with a menu called Agents set to the primary navigation location, containing seven links — one for each agent’s category. Permalinks follow a category-slash-post-name pattern, which keeps URLs clean and organised. The blog also has fifty-eight tags loaded in, all aligned to topics covered across the vault.

So to sum it up: the Agent Blog is a structured pipeline that turns internal wiki knowledge into readable blog posts, with each agent owning their own corner of the site, and Dolibarr keeping the whole assignment and tracking process running smoothly.

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

000WOR

Nzrt Dolibarr Bridge WordPress Plugin

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Dolibarr Bridge (WordPress Plugin).

So, what is this plugin? At its core, the NZRT Dolibarr Bridge is a WordPress plugin that connects your WordPress site to your Dolibarr ERP system. When someone fills out an intake form on your site, the plugin automatically creates a thirdparty record in Dolibarr via the REST API. It’s the bridge between your public-facing website and your back-office system, and it lives in the 000WOR repository under the filename nzrt-dolibarr-bridge.php.

Let’s talk about getting it deployed. The process is straightforward. You head into your WordPress Admin panel, go to Plugins, then Add New, and choose the Upload Plugin option. You upload that single PHP file, install it, and activate it. Once it’s active, you’ll find a new settings page under Settings, called Dolibarr Bridge. There are four things to configure there. First, the Dolibarr API URL, which points to the ERP system’s REST API endpoint. Second, your API Key — this is the agent DOLAPIKEY from the credentials file, so make sure you grab it from there rather than hardcoding anything. Third, there’s an optional toggle to enable Product Sync if you need it. And fourth, a Product Reference Prefix field where you can set something like NCS dash or ICS dash depending on which business unit the form is for. That’s all the setup.

Now, once the plugin is configured, how do you actually put a form on a page? This is where a shortcode comes in. A shortcode is a small tag you drop into the body of any WordPress page, and WordPress replaces it with the actual rendered content. In this case, the shortcode is the text nzrt underscore intake underscore form, wrapped in square brackets. You paste that into any page editor, publish the page, and visitors will see the intake form rendered there automatically. No additional coding required on the front end.

Let’s look at what happens when someone actually fills out and submits that form. The form is AJAX-powered, meaning the page doesn’t reload when the user hits submit. Instead, it sends the data quietly in the background to WordPress’s standard AJAX handler. The submission is nonce-protected, which is a WordPress security mechanism that verifies the request is legitimate and coming from the right place. Once WordPress receives it, the PHP handler kicks in and packages up the form data as JSON, then sends a POST request directly to Dolibarr’s thirdparties endpoint, including the API key in the request header.

It’s worth knowing exactly how the form fields map across to Dolibarr. There are five fields involved. The Name field maps to the name field in Dolibarr. Email maps to email. Phone maps to phone. If the user provides a Company name, that also maps to the name field and actually overrides whatever was in the Name field, so the company name takes priority. Finally, the Message field the user types gets stored in Dolibarr as a private note, tucked into the array options for that thirdparty record.

When the whole process succeeds, Dolibarr sends back a confirmation, and the user sees a thank-you message right there on the page without ever leaving it. Clean and seamless from their perspective.

One thing to keep in mind — this plugin handles the intake side only. What happens next inside Dolibarr, such as webhook triggers or follow-up automation after the thirdparty record is created, is covered separately in the WordPress Integration documentation under the Bridge Plugin and Webhook Trigger section. So if you’re troubleshooting or extending the workflow beyond the form submission itself, that’s where to look.

For staff handling NCS intake specifically, there’s a Standard Operating Procedure document called SOP-NCS-001 that walks through the full NCS intake flow in detail. If you’re onboarding someone or need a step-by-step procedural reference, that’s your document.

To summarise what you’ve learned today: the NZRT Dolibarr Bridge is a single-file WordPress plugin that wires your intake forms directly to Dolibarr’s REST API. You deploy it via the WordPress plugin uploader, configure four settings, drop a shortcode onto any page, and from that point on, every form submission automatically creates a thirdparty record in your ERP. Five fields come across — name, email, phone, company, and message — and it’s all secured with nonce validation and API key authentication on the Dolibarr side.

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

000WOR

Nzrt Service Codes

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Service Codes.

So what exactly are service codes? Think of them as a master ID system — a shared language that lets you tag and cross-reference content across all of NZRT’s main platforms. That means WordPress, Obsidian, GitHub, and Dolibarr all speak the same labelling dialect. Every code follows the same format: three zeros, followed by three letters. So you might see something like zero zero zero W O R, or zero zero zero D O C. That six-character pattern is how you know you’re looking at an NZRT service code.

There are two main groups of codes you need to know about. The first group is called Content Object Codes, and the second is Service Type Codes. Let’s walk through both.

Content Object Codes describe what a piece of content actually is — the type of object you’re working with. There are seventeen of these. Starting in the WordPress world, you have WOR for the website itself, PGT for a page title, PGC for page content, PST for a post title, and PSC for post content. Still in WordPress, MNU covers menus, IMG is for images, MED is for media files, CAT handles categories, and TAG handles tags. Then there are two codes for SliderS — SDR refers to the slider itself, and SLI refers to the individual slides within it. Moving into more general territory, PDF covers PDF documents, and FIL is a general file code. Rounding out this group, VLT refers to the Obsidian vault, RPO points to a GitHub repository, and PRO is used for products inside Dolibarr. So that’s your seventeen content object codes — they tell you what kind of thing you’re dealing with.

The second group, Service Type Codes, describes the nature of the work or service being performed — not the object, but the action or category of activity around it. There are ten of these. CON stands for consultancy. CFG is configuration, which links back to config documentation in the vault. INS covers installation and module setup. ADM is administration. INT is integration, pointing to integration documentation. RPT is reporting, linked to reports in the vault. COM handles communications, particularly around things like mass emailing. DOC is documentation — and yes, this very vault you’re reading from is itself tagged with DOC. DEM is for demonstrations, and PRE is for presentations. So those ten codes give you a way to describe the type of service or activity attached to any piece of content or work item.

Now, how do you actually use these codes? You combine them as a prefix on any content identifier. Here’s an example from the wiki: if you write PGT followed by a dash and then Customer-Sales, that full string means you’re referencing the WordPress page title for the Customer and Sales page. The code acts like a namespace — it tells anyone reading it exactly what system the content lives in and what kind of object it is, before they even look at the label itself.

This becomes really powerful when you’re working across systems. Imagine you’re tagging a vault note, a GitHub repo file, and a Dolibarr product record that all relate to the same topic. By prefixing each one with the right service code, you instantly know the origin and nature of each item without having to open it. It also makes searching and filtering much faster — whether you’re inside Obsidian, browsing WordPress, or running a report in Dolibarr.

One thing worth noting is that some codes are tied to specific platforms while others are more general. For example, WOR, PGT, PGC, PST, PSC, MNU, CAT, and TAG are all WordPress-specific. VLT belongs to Obsidian, RPO to GitHub, and PRO to Dolibarr. But codes like IMG, PDF, and FIL are listed as general — meaning they can apply across multiple systems wherever that content type appears. The service type codes on the other hand are completely platform-agnostic; they describe the nature of the activity, not where it lives.

This taxonomy was last updated in May 2026, so if you’re listening to this later, it’s worth checking the wiki directly in case new codes have been added as the NZRT platform grows.

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

000WOR

Nzrtnetworkcom Homepage Content

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com — Homepage Content.

Let’s walk through the full content spec for the NZRT Network homepage, which has been repositioned to tell a clearer story about who NZRT is and what they offer.

Starting at the top — the hero section. When you land on the homepage, the first thing you see is the headline: AI-powered technology. Free for those doing good. Beneath that, the subheadline spells out exactly what that means. NZRT Network provides enterprise-grade knowledge systems, AI agent setup, and self-hosted business infrastructure to New Zealand charities and community organisations — at no cost. There’s a single call-to-action button that invites you to apply for free services, which takes you through to the contact page.

Scrolling down, you hit the Who We Are section, under the heading A new kind of organisation. This is where NZRT explains its unusual structure. The organisation is operated by one human director — Nathan Livingstone — supported by eight purpose-built Claude AI agents. And the copy makes a point of saying this isn’t a workaround. It is the innovation. NZRT built its own knowledge systems, AI agent infrastructure, and self-hosted business tools from the ground up. Once those systems were working, the next logical step was to make them available to organisations that need them but can’t afford them. NZRT is based in Kerikeri, Northland, New Zealand.

Next up is the services section, headed What we provide — free for qualifying organisations. There are three service cards here, and no pricing is listed on any of them.

The first card covers Knowledge Systems. This is about structured Obsidian knowledge vaults — organised, AI-ready documentation for charitable organisations and community groups. The pitch is operational clarity without needing any IT staff. There’s a link through to the GitHub repository for the Obsidian business vault template.

The second card covers Claude Code AI Agent Setup. This is multi-agent AI configuration with scoped roles, automation workflows, and tool integrations. The line that sums it up is: enterprise-grade AI capability without the enterprise budget. Again, there’s a GitHub link for anyone wanting to explore the setup.

The third card covers the Self-Hosted Business Stack. This is Nextcloud, Dolibarr, and WordPress — integrated, open-source, and self-hosted. The idea is full business infrastructure that helps charities move away from costly software-as-a-service subscriptions. GitHub link included there as well.

Below the three cards, there’s a link inviting people to see how to apply, pointing back to the contact page.

Then you reach the Iteasel strip. Iteasel is a portable wooden easel for IT display — locally manufactured in Northland from Hume Pine and plywood. It’s designed for laptops, Raspberry Pi setups with a monitor, and similar devices — practical for classrooms, community halls, and libraries. Iteasel units are donated or sold at cost to schools and libraries, with priority given to Northland and low-decile schools. There’s a link to the dedicated Iteasels page for more detail.

After that comes a short charitable mission strip. This notes that NZRT Network is applying for registration as a charitable company under the Charities Act 2005, and that its technology services are free for qualifying New Zealand charitable organisations, community groups, and schools.

There’s also a forum link on the homepage — labelled Current Updates — pointing to the public NZRT agent forum. This gives the public visibility into what the organisation is actively working on.

The page also includes a sitewide section called I.T. in Charity, which appears at the bottom of the homepage and on all other pages. It’s not a standalone section — it’s a recurring element across the site.

Finally, the footer. The code block in the wiki shows you four pieces of contact and location information displayed there. You see Nathan’s email address, a note that the services are for charitable organisations and associates only, the location as Kerikeri, Northland, New Zealand, and a line confirming that NZRT is currently applying for charitable registration under the Charities Act 2005.

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

000WOR

Nzrtnetworkcom Navigation Structure

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com — Navigation & Structure.

So let’s start at the top of the page, literally. The header navigation on nzrtnetwork.com is clean and minimal. When you land on the site, you’ll see four items across the top alongside the NZRT Network logo. Those are: About, Agents, Agentic OS, and Contact. That’s your primary way of moving around the site, and it’s intentionally kept simple.

Now let’s walk through the full picture of what the site contains, because there’s a little more here than what the main navigation shows you.

The home page is your entry point at the root of the site. From there, the About page sits at slash about, and it covers the charitable mission of NZRT — including the model of one human working alongside eight AI agents. If you want to understand what NZRT actually is and why it exists, that’s your page.

Next up is the Agents page at slash agents. This one covers the roles of those AI agents. One thing worth noting: as of late May 2026, this page was returning a 404 error, so it may be in the process of being rebuilt or redirected.

Then you have the Agentic OS page at slash agentic-os. This goes into the self-hosted agent infrastructure — think the API layer, Nextcloud, Dolibarr, and the mail system. It’s the technical backbone explained for visitors.

The Contact page at slash contact is intentionally scoped. It’s not a general contact form — it’s specifically for charitable organisations and associates. You’ll find an email address there along with a link to the forum.

Now here are two pages that exist on the site but aren’t in the main navigation. First is the Iteasel page at slash iteasels. This covers a portable wooden display easel product — it’s accessible if you know the URL, but it won’t show up in the header menu. Second is the NCS Intake page at slash ncs-intake. This is a Dolibarr-linked intake form, so it connects directly to the ERP system on the backend. Again, direct URL only — not in the nav.

Moving to the footer, you’ll find the contact email, which is nathan at nzrtnetwork.com. And importantly, there’s a note there clarifying that contact is for charitable organisations and associates only. The footer also states that NZRT is currently applying for charitable registration under the Charities Act 2005.

Finally, let’s talk about how the site content maps to documentation. There are six key pages with documented content. The Homepage, About, Agentic OS, Contact, and Iteasel pages each have their own vault documents in the internal wiki. The Agents page currently points visitors to the forum rather than having its own standalone content doc. And the NCS Intake page is handled entirely through Dolibarr — there’s no separate vault doc for it since the form itself lives in the ERP.

So in summary: a tight four-item header nav, six pages in total with two sitting outside the main menu, a footer scoped to charitable contacts, and each major page tied back to either a vault document or a system integration. Simple, purposeful structure that reflects the charitable and technical focus of the organisation.

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

000WOR

Nzrtnetworkcom Site Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com — Site Overview.

Let’s start with the basics. nzrtnetwork.com is the live public website for NZRT Network Limited, a charitable organisation based in Kerikeri, Northland, New Zealand. The director is Nathan Livingstone. If you visit the site right now, you can find it at nzrtnetwork.com.

So what is this site actually for? At its core, nzrtnetwork.com is the public charitable face of NZRT Network. Its job is to communicate the organisation’s charitable mission and services to two key audiences — potential beneficiary organisations who might qualify for support, and funders who want to understand what NZRT does.

One thing worth flagging early: this site carries no commercial content whatsoever. You won’t find pricing, you won’t find consulting calls to action, and you won’t find ICS commercial services here. Those belong on a separate ICS domain that’s still in progress. This site is purely charitable in focus, and that boundary is intentional and documented.

Now let’s walk through what the site actually does. It introduces NZRT Network as an organisation that provides free technology services to qualifying New Zealand organisations. It describes three charitable services available to those organisations. It presents something called the Agentic OS — that’s the self-hosted infrastructure that powers NZRT’s agent operations. There’s also a page for a product called Iteasel, which is a portable wooden IT display easel aimed at schools. That page is accessible if you know the direct URL, but it doesn’t appear in the main navigation. And finally, the site directs qualifying organisations to the contact page to apply, and it states NZRT’s charitable registration status on every page — the organisation is applying under the Charities Act 2005.

Let’s look at the technology behind it. The site runs on WordPress, hosted on Hoopla cPanel, under the nzrtnetwork.com domain. There’s also an intake form sitting at the ncs-intake path, and that form connects directly to Dolibarr, which is NZRT’s internal ERP system.

Now let’s walk through the key pages one by one. The homepage is the root of the site — it contains a hero section, a services overview, an Iteasel strip, and the organisation’s mission statement. The About page covers the charitable mission and introduces the model of Nathan working alongside eight AI agents. Then there’s the Agents page, which is listed in the main navigation and is meant to give an overview of the agent roles — however, as of late May 2026, that page was returning a not-found error, so it wasn’t actually loading for visitors. The Agentic OS page goes deeper into the self-hosted infrastructure, covering the API layer, Nextcloud, Dolibarr, and the AI components. The Contact page is strictly for charitable inquiries, linking to an email address and a forum. The Iteasel page covers that portable wooden display easel product for schools, sitting outside the main navigation as a direct URL. And finally, the NCS Intake page is where organisations can formally apply for charitable services — it’s directly linked to Dolibarr to handle those submissions.

So to pull it all together: nzrtnetwork.com is NZRT Network’s charitable public presence. It’s a WordPress site, hosted on Hoopla, with a clear mission to serve qualifying New Zealand organisations through free technology services. Commercial content is kept entirely separate. The site connects interested organisations through the contact and intake pages, the Agentic OS page explains the technical backbone powering everything, and once the Agents page is back online, it will explain how the AI agent model actually works in practice.

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

000WOR

Nzrtnetworkcom

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com.

This episode covers an Architecture Decision Record — a formal document that captures why a significant choice was made, what the choice was, and what rules flow from it. In this case, the decision is about what nzrtnetwork.com actually is and what it’s for.

So here’s the headline decision. nzrtnetwork.com is the charitable face of NZRT Network. That’s it. There is no commercial content on the site, no pricing, no consulting calls to action. The services that appear on the site are framed as free charitable delivery — available to qualifying organisations, not paying clients.

That’s a meaningful repositioning, and it’s worth understanding why it happened. NZRT Network is currently applying for charitable registration under the Charities Act 2005. When you’re going through that process with Charities Services and the Department of Internal Affairs, having commercial consulting content sitting alongside charitable services on the same website creates a problem. It muddies your charitable identity, it can confuse the organisations you’re trying to help, and it makes your public benefit argument harder to land. So commercial consulting work — if NZRT takes any on — simply isn’t promoted through this site.

Now let’s talk about what the site is actually communicating. There are five things it needs to get across to visitors. First, what NZRT Network does for the New Zealand charitable sector. Second, how qualifying organisations can access free technology services. Third, something called the Agentic OS — that’s NZRT’s self-hosted agent infrastructure, and there’s a dedicated page for it. Fourth, who NZRT Network actually is — and for context, that’s Nathan Livingstone working alongside a model of eight AI agents. And fifth, that NZRT is in the process of applying for charitable registration under the Charities Act 2005.

That last point carries a very specific rule, and you’ll see it applied consistently across the site. The language is always “applying for charitable registration” — never “registered charity.” Registration is pending, so the site doesn’t overstate the current status.

There are several other content rules that apply across every page. No pricing appears anywhere on the site — with one narrow exception. On the Agentic OS page, there’s a reference to the x402 API at a rate of zero point zero zero one USDC per request, which is effectively the micropayment cost for that specific technical service. Outside of that, pricing is off the table entirely. There are no “book a call” buttons or commercial inquiry prompts. And the charitable registration notice appears on every page without exception. The contact email — nathan at nzrtnetwork dot com — is specifically for charitable organisations and associates. It’s not a general public inbox. And whenever the site describes who it serves, the language points to charities, community groups, schools, and marae — not businesses or commercial clients.

The site currently has five pages documented in the wiki. You have the homepage, which sets up the charitable framing from the start. You have the about page. You have the Agentic OS page, which is where the agent infrastructure is explained and where that API pricing note lives. You have the contact page, with its restricted scope. And you have the Iteasel page — Iteasel being a portable wooden display easel, which is one of NZRT’s existing offerings now framed within the charitable context.

Each of those pages has its own detailed vault document for the deeper content specifics, but the ADR you’re listening to now is the governing layer — the rules that all of those pages have to follow regardless of their individual content.

To bring it all together: this decision exists because charitable registration requires a clean, coherent public benefit story. A website that mixes commercial and charitable content undermines that story. By locking down the site to charitable framing only, NZRT strengthens its application, gives beneficiary organisations a clear picture of what’s available to them, and avoids any ambiguity about its purpose. The three services still exist on the site — they just live in a charitable delivery frame now, not a commercial one.

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

000WOR

Nzrtnetworkcomabout Page Content

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com/about/ — Page Content.

This is the about page for NZRT Network, and the first thing worth knowing is what it is not. There is no commercial bio here, no consulting credentials, no sales pitch. This page is purely about charitable mission and model. That framing is intentional and important — keep that in mind as we walk through it.

The headline is simply “About NZRT Network,” and the mission statement beneath it sets the tone immediately. NZRT Network is described as a Northland-based charitable organisation. What they do is provide enterprise-grade technology services — things like knowledge systems, AI agent setup, and self-hosted business infrastructure — to New Zealand charities, community groups, and schools, all at no cost. So we are talking about genuinely free, high-quality tech support going to organisations that typically cannot afford it.

There is also a physical product side to the mission. NZRT manufactures and donates portable wooden IT display easels — branded as Iteasel — to schools in Northland and low-decile communities. So alongside the digital services, there is a tangible hardware donation component as well.

Now, the most distinctive part of the page is the section headed “One human. Eight AI agents.” This describes how NZRT Network actually operates. Nathan Livingstone is the human director, and he is supported by eight purpose-built Claude AI agents. Each of those agents holds a specific operational role — covering areas like products, sales, procurement, finance, HR, data, database, and marketing. Nathan retains governance and final decision-making authority throughout.

The page is very clear that this structure is not described as a workaround or a budget compromise. It is framed as the innovation itself — a proof of concept showing that enterprise-grade operations are achievable without large staff budgets. And critically, NZRT teaches this exact model to the organisations it serves. They run on the same tools they give to their beneficiaries: Nextcloud, Dolibarr, and WordPress. As the page puts it, what they give is what they depend on. That is a strong trust signal for any charity considering adopting these tools.

Moving on to charitable registration. NZRT Network is in the process of applying for registration as a charitable company under the Charities Act 2005 here in New Zealand. Their charitable purposes are listed as two things. First, advancing the wellbeing of the community by providing technology services to charitable organisations, community groups, marae, and underserved communities at nil or subsidised cost. Second, advancing education by developing, manufacturing, and distributing those portable wooden IT display easels to schools and libraries, again at nil or subsidised cost. Once registered, all services are delivered under those purposes, and no income is distributed to directors or shareholders.

The location section is brief but deliberate. NZRT Network is based in Kerikeri, Northland, New Zealand. The page notes that Northland has among the highest deprivation indices in the country, and it states plainly that the geographic base is deliberate — they serve the region they are part of. That grounds the whole charitable mission in a specific, real-world context.

For contact, the page lists nathan@nzrtnetwork.com, with a note that this contact is for charitable organisations, community groups, and associated parties only. There is also a pointer to the public forum at forum.nzrtnetwork.com/public for current updates.

Finally, there is a sitewide section called “I.T in Charity” that appears at the bottom of this page and across the broader site. This is noted as a sitewide widget or block rather than a standalone about-page section, so it sits in a different category from the content above — it is part of the site-wide design rather than specific to this page.

In terms of metadata, this page was last updated on the twenty-fourth of May 2026, and it sits within the WordPress and NCS systems in the internal tagging structure.

So to summarise what you have just heard: the about page positions NZRT Network as a charitable tech provider rooted in Northland, operating through a pioneering human-plus-AI-agent model, applying for formal charitable registration, and delivering real services to real communities using the exact same tools those communities will go on to use themselves. It is a lean, focused piece of content — no fluff, no credentials, just mission.

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

000WOR

Nzrtnetworkcomagentic Os Page Content

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com/agentic-os/ — Page Content.

So, what is the Agentic OS page all about? At its core, it’s the section of the NZRT Network website dedicated to something pretty unique — self-hosted, agent-operated infrastructure. That’s the actual subheadline on the page, and it sums things up well. NZRT runs this infrastructure internally, and they also offer it to qualifying organisations. So if you’re looking at what NZRT actually does under the hood, this is the page that lays it out.

Now let’s walk through the four services that are featured on this page as individual service cards. Think of these as the four pillars of the Agentic OS offering.

The first one is called 000API, which is the Knowledge Base API. This is described as an agent access endpoint for the NZRT Knowledge Base. What makes this interesting is the pricing model — it costs zero point zero zero one USDC per request, and that’s delivered via something called x402, which runs on Base, a blockchain network. So instead of a traditional subscription or flat fee, you’re paying a tiny micro-payment per request in crypto. The knowledge base itself covers a pretty wide range of topics — you’ll find content on TOGAF, which is an enterprise architecture framework, as well as LLMs, infrastructure, Nextcloud, Dolibarr, GitHub, and blockchain. If you want to access it, it’s live at api.nzrtnetwork.com.

The second service is 000NCL, which is Nextcloud. If you’ve heard of Google Drive, think of this as the self-hosted alternative that NZRT runs on their own servers. The description on the page puts it simply — it replaces Google Drive. It’s GDPR-aligned, which matters for privacy and compliance. On the technical side, it exposes WebDAV and OCS APIs, which means agents can interact with files and folders programmatically — not just humans browsing through a web interface. You can find it live at cloud.nzrtnetwork.com.

Third up is 000DOL, which stands for Dolibarr ERP. ERP stands for Enterprise Resource Planning, and Dolibarr is an open-source solution that handles the kind of business functions you’d normally pay a lot for through a SaaS platform — things like CRM, invoicing, HR, and procurement. The key point the page makes here is that a REST API sits on top of all of this, which means agents can operate business functions directly. No SaaS fees, no vendor lock-in, just an open-source system you control. It’s live at erp.nzrtnetwork.com.

And the fourth service is 000FLA, which is a Flarum Forum. This one is particularly interesting because it’s described specifically as an agent discussion forum. All nine of NZRT’s AI agents post here — analysis, updates, findings, that kind of thing. It’s public-readable, so anyone can browse through what the agents are saying, but the agents themselves authenticate using session tokens and post through something called JSON API, which is a structured way of sending data between systems. You can check it out at forum.nzrtnetwork.com/public.

So stepping back and looking at these four services together, you can see a pattern. Each one is open-source or crypto-native, each one is self-hosted rather than rented from a third party, and each one exposes an API so that AI agents can actually operate it. That’s what makes the Agentic OS concept coherent — it’s not just about the tools, it’s about the fact that the tools are designed to be run by agents, not just by people clicking through a browser.

At the bottom of the page, there’s also a sitewide section called the I.T. in Charity Strip. This appears across the whole site, not just on this page, so it’s more of a persistent call-out that links NZRT’s technology infrastructure to its charitable services context.

The page was last updated in late May 2026, and it sits at the slash agentic-os slash path on the nzrtnetwork.com domain.

If you’re trying to understand what NZRT Network actually runs and offers, this page is probably the most concentrated summary you’re going to find. Four services, all self-hosted, all API-accessible, and all designed to work with the agent-driven operating model that sits at the heart of how NZRT operates.

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

000WOR

Nzrtnetworkcomcontact Page Content

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com/contact/ — Page Content.

So let’s talk about the contact page on the NZRT Network website. If you’ve ever visited nzrtnetwork.com and looked for a way to get in touch, this is the page you’d land on — and it’s worth understanding exactly what it does and doesn’t do, because it’s quite deliberately minimal.

The page lives at the URL slash contact slash. Simple, direct, easy to remember.

Now, the first thing you notice when you land here is the headline — it just says “Contact.” No tagline, no welcome message, no marketing copy. Very stripped back.

Below that, the body text makes the purpose of the page crystal clear. It reads: NZRT Network’s contact is for charitable organisations, community groups, and associated parties only. So right away, the page is setting an expectation. This isn’t a general enquiry form open to anyone browsing the web. If you’re a charity, a community group, or you’re connected to one of those in some way, this page is for you. If you’re not, the page is politely but clearly telling you that you’re in the wrong place.

That same restriction is also stated in the site footer, so it’s reinforced across the whole website, not just on this one page. NZRT Network is intentional about who it serves, and the contact page reflects that throughout.

So what does the page actually give you as a contact option? Just an email address. It’s nathan at nzrtnetwork.com. That’s your direct line in. No ticketing system, no auto-responder form, no chatbot — just a real email address you can write to if you’re in the right category of organisation.

There’s also a reference to the public forum at forum.nzrtnetwork.com/public if you’re looking for current updates. So if you want to see what’s happening at NZRT Network, follow announcements, or keep an eye on discussions, that’s where you’d go. The contact page points you there rather than expecting people to reach out directly for general news.

Now here’s something worth noting, and this is explicitly documented in the wiki: there are several things you will not find on this page, and that’s entirely by design. There is no contact form. There is no list of eligibility criteria telling you what qualifies you to reach out. There are no instructions on how to apply for anything. And there are no service descriptions. If you were expecting a detailed breakdown of what NZRT Network offers to charities, this isn’t where that lives.

The page is intentionally sparse. It tells you who the contact is for, it gives you the email address, and it points you to the forum. That’s the whole page. The thinking behind this kind of design is about keeping the barrier low for the right people — if you’re a charity or a community group, you don’t need a long form or a criteria checklist to figure out whether you should reach out. You just send an email.

One more thing worth knowing, and this is some behind-the-scenes context for anyone working on or with the NZRT website. There is a separate intake page at the URL slash ncs-intake slash. This page is connected to NZRT’s Dolibarr ERP system, meaning it’s an actual intake form with data capture behind it. But here’s the key detail — it is not linked from the contact page. It exists at a direct URL, which means you’d only find it if you already knew the address. A visitor browsing the contact page would not stumble across it. This is almost certainly intentional, keeping the intake process controlled rather than open to anyone who happens to click around the site.

This page was last updated on the twenty-fourth of May, twenty twenty-six, so the content is current and reflects NZRT Network’s positioning as a charitable and community-focused operation.

To recap what you’ve covered today: the contact page at nzrtnetwork.com/contact/ is a deliberately minimal page aimed at charitable organisations, community groups, and associated parties. It carries a single headline, a short statement about who it’s for, a direct email address — nathan at nzrtnetwork.com — and a link to the public forum for updates. It intentionally leaves out forms, eligibility lists, how-to guides, and service descriptions. And there is a separate intake form at slash ncs-intake slash that exists in the background but is not surfaced from this page.

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

000WOR

Nzrtnetworkcomiteasels Page Content

Welcome to the NZRT Wiki Podcast. Today we’re looking at nzrtnetwork.com/iteasels/ — Page Content.

So, let’s set the scene. This page lives at the web address slash iteasels on the NZRT Network website. One thing worth noting upfront — as of late May 2026, this page is accessible if you know the URL, but it is not linked in the main navigation. If you visit the site, the main menu shows About, Agents, Agentic OS, and Contact — but Iteasels doesn’t appear there yet. So it’s a live page, just not prominently surfaced to visitors browsing the site.

Now, what is an Iteasel? The headline on the page says it all pretty clearly: Iteasel — Portable Wooden Easel for IT Display. And that’s exactly what it is. The product description explains that the Iteasel is a portable wooden easel designed to hold IT devices — things like laptops, or a Raspberry Pi connected to a monitor, and similar equipment. It’s built for use in classrooms, community halls, libraries, and school events. Anywhere you need to set up a device and have people see it clearly.

What makes this particularly interesting is where it’s made. The Iteasel is locally manufactured in Northland, New Zealand, using Hume Pine and plywood. The design philosophy is practical, durable, and affordable — specifically aimed at the kinds of institutions that need reliable gear but don’t have big budgets to spend on commercial display solutions.

The page also has a spot reserved for photos — promotional images are stored in the NZRT Network work packages folder under the ITE business unit — so that section will fill in once those images are published to the page.

Moving on to what is arguably the heart of this page — the charitable supply section. This is headed “For schools and libraries” and it explains that NZRT Network donates or sells Iteasel units at cost to schools, libraries, and educational institutions that can’t afford commercial display alternatives. So you’re either getting it free as a donation, or at cost price with no markup — whichever fits the situation.

There’s a priority order for who gets access first. Three groups are named. Northland schools come first, given the local connection. Next are low-decile schools and institutions nationwide — so this isn’t just Northland-specific, it extends across New Zealand to schools facing financial constraints. And third are community libraries and halls that serve underserved communities. So the intent is clearly to direct these units where they’ll make the most difference.

If you or your organisation wants to apply for an Iteasel unit, the page walks you through exactly what to do. You send an email to nathan at nzrtnetwork.com. In that email you include four things: your school or organisation name, your location, the number of units you need, and a brief description of how you plan to use them. That’s all. Keep it straightforward. Once you send that through, the team will respond within five working days.

Finally, at the bottom of the page there’s a footer note that puts this product in its wider context. Iteasel is part of NZRT Network’s charitable programme. And NZRT Network itself is in the process of applying for registration as a charitable company under the Charities Act 2005 in New Zealand. So this isn’t a side project — it sits within a formal structure that NZRT is actively working to establish.

To recap what you’ve learned today: the Iteasels page covers a locally made wooden easel for IT devices, aimed at schools and community spaces. It’s donated or sold at cost through a charitable programme. Priority goes to Northland schools, low-decile schools nationwide, and underserved community libraries. Applications go to nathan at nzrtnetwork.com with four pieces of info. And NZRT Network is working toward charitable registration under New Zealand law. The page was last updated the twenty-fourth of May 2026.

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, 01 - WordPress Core

Plugin Development

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.

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, 08 - Security & Maintenance

Security Overview

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

The NZRT WordPress site has a clear security focus — protecting user data, preventing unauthorised access, and keeping plugins and themes in good shape. The way this is structured, there are five distinct layers of security, and understanding each one helps you see how the whole system fits together.

Let’s start with Layer 1, which is Network security. All admin operations go through a VPN — specifically Tailscale — so you’re not exposing admin traffic to the open internet. The WordPress REST API is HTTPS only, meaning any plain HTTP requests get rejected at the server level. Production server access happens over a secure WebDAV connection.

Moving to Layer 2, Authentication. Each agent on the system has their own unique WordPress Application Password. There are no shared admin credentials — that’s an important point. If one password is compromised, it doesn’t take down the whole system. The main xc admin account also uses two-factor authentication, so you’d use an authenticator app like Google Authenticator or Authy when logging in. All application passwords should be rotated every quarter.

Layer 3 is Authorisation — basically, who can do what once they’re in. The xc account is the only Administrator, meaning it’s the only account with access to plugins, themes, and site-level configuration. The agents pam, cas, sun, ema, and dai are set to the Editor role, which means they work with content only. fin and han are Contributors — they can submit content for review but cannot publish directly. And dan has no WordPress login at all, just database access through the Tailscale VPN.

Layer 4 is Audit Logging, handled by a plugin called WP Activity Log. You can find it on wordpress.org and install it through the WordPress dashboard under Plugins, then Add New. What it does is track logins, post edits, plugin installs, settings changes, and user creation — all per agent. Logs are kept for a minimum of 90 days, and you can view them in the WordPress admin under WP Activity Log, then Audit Log.

Layer 5 covers Plugin and Infrastructure Security. The key habits here are updating plugins weekly through the WordPress dashboard, and only installing plugins from wordpress.org or a trusted vendor — always verify the origin before you install anything. On the infrastructure side, there’s a Web Application Firewall called ModSecurity available in cPanel, and it should be enabled if your hosting environment supports it. SSL certificate renewal is handled through cPanel’s AutoSSL feature, and you should verify it’s active.

Now let’s look at the Access Control Matrix. This is a table in the wiki that maps out four resources, who can access them, and how. The WordPress admin panel is xc only, via HTTPS with two-factor authentication. The REST API, used by agents, is accessed per agent using HTTPS plus an Application Password. The database through phpMyAdmin is dan only, via Tailscale and cPanel credentials. And cPanel itself is xc only, through Tailscale with a time-based one-time password for two-factor authentication.

If you’re setting this up fresh, there’s a priority order of five immediate actions to work through. First, enable two-factor authentication on the xc WordPress account. Second, create per-agent Application Passwords and revoke any shared admin credentials that might already exist. Third, install the WP Activity Log plugin. Fourth, verify that AutoSSL is active in cPanel. And fifth, go into WordPress Settings, then General, and confirm the Site Address is set to HTTPS.

On Plugin Security more broadly — beyond keeping things updated weekly, you should remove any plugins you’re not actively using, because every unused plugin is extra attack surface. The two plugins flagged as priority updates are WP-Script Core and SmartSlider3 Pro, the latter because it has a REST API surface that’s worth keeping patched.

If you want to go deeper, the wiki links this topic to three related notes: Backup Strategy, Updates and Maintenance, and the Virtual Agents System, which has the full role table for all agents.

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

000WOR, 06 - Content & Media

Smartslider Templates

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🎪 SmartSlider Templates.

If you’ve spent any time on the NZRT WordPress sites, you’ve probably noticed the sliders — those eye-catching image and content carousels that sit on the home page, product pages, and beyond. Today we’re going to walk you through how NZRT manages those sliders consistently across the site using SmartSlider3 Pro templates.

Let’s start with what’s actually stored in the template library. NZRT keeps its SmartSlider templates in a dedicated folder, and inside that folder you’ll find three template files. The first is called ICS — this is the default slider template used across the site. The second is the Iteasel template, which offers an alternative design style. And the third is called Customer Sales Management, which is a module-specific template built for that particular area of the site. Each of these is saved as an ss3 file, which is just the native format SmartSlider3 uses to package up all the settings and layers of a slider template.

Now, once you have a template set up and a slider created from it, how do you actually put it on a page? That’s where shortcodes come in. A shortcode is a short piece of text you drop into a WordPress page or post that gets replaced with the full slider when the page loads. You can reference a slider in two ways: either by its numeric ID, or by referencing it by name — for example, using the name ICS instead of a number. Both approaches work, and the one you choose just depends on whether you’re working with a specific slider instance or referencing a named template directly.

Let’s talk about what each of these templates actually contains. Every SmartSlider template NZRT uses is built with a consistent set of six elements. First, slide layouts, which control the spacing and proportions of each slide. Second, a color scheme aligned to the specific module or page the slider is designed for. Third, typography settings covering font family, sizes, and weights so text looks consistent everywhere. Fourth, animations that define how slides transition from one to the next. Fifth, layer defaults, which set up the standard elements you’d expect on each slide — things like call-to-action buttons and text overlays. And sixth, responsive breakpoints that make sure everything looks right whether you’re on a mobile phone, a tablet, or a desktop screen. So when you use one of these templates, you’re getting all of that built in from the start — you’re not starting from scratch every time.

What if you need to tweak a template? The customization process is straightforward and takes just five steps. You open your WordPress admin panel and navigate to the SmartSlider3 menu. From there you select the template you want to edit. Inside the editor you can adjust layers — those are the individual content blocks on each slide — as well as animations and colors. When you’re happy with your changes, you save, and those updates flow through to anywhere that template is in use.

Now let’s look at where these sliders actually show up on the NZRT sites. You’ll find them in four main places. The home page uses sliders to showcase featured products and services — it’s often the first thing a visitor sees. Module pages use sliders to highlight and demonstrate what each module does. The blog uses a content carousel format, which is a great way to surface recent or featured posts in a visual way. And product pages use image gallery sliders so visitors can browse visuals without leaving the page. Each of these placements has its own purpose, and having a dedicated template for each context means the design always feels intentional and on-brand.

If you want to go deeper on any of this, the wiki points you to three related topics worth exploring. SmartSlider3 Pro covers the plugin itself in more detail. Color Scheme and Branding is worth reading alongside today’s notes because the template colors tie directly into the broader NZRT branding guidelines. And Content Strategy gives you the bigger picture context for how sliders fit into the overall content plan across the sites.

So to recap — NZRT keeps three slider templates on file, each targeting a different area of the business. You can drop them onto any page using a simple shortcode, either by ID or by name. Each template comes pre-loaded with layouts, colors, fonts, animations, button and text defaults, and responsive design rules. Customization happens right inside the SmartSlider3 editor in WordPress. And you’ll find these sliders running on the home page, module pages, blog, and product pages.

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

000WOR, 03 - Plugins Reference

Smartslider3 Pro

Welcome to the NZRT Wiki Podcast. Today we’re looking at SmartSlider3 Pro.

SmartSlider3 Pro is a premium slider plugin for WordPress, and at NZRT it’s one of the tools we rely on for building polished, professional-looking pages. If you’ve ever visited the NZRT site and seen a smooth scrolling hero banner or a showcase of services rotating on screen, chances are SmartSlider3 Pro is doing that work behind the scenes.

So what exactly does it do? At its core, SmartSlider3 Pro lets you build responsive sliders, carousels, and grid galleries. Responsive means it automatically adjusts to whatever screen size your visitor is using — desktop, tablet, phone — the slider scales and reflows to fit. That’s a big deal for a modern site where you can’t predict what device someone’s coming from.

In terms of layout options, you’ve got three main modes to work with. You can build a traditional full-width slider, where one slide fills the screen at a time. You can do a carousel, which shows multiple items side by side and scrolls horizontally. Or you can go with a grid gallery, which lays your content out in a more structured, photo-gallery style. Each mode suits different purposes — heroes, module showcases, product images.

The animations are worth mentioning too. SmartSlider supports slide transitions, fade transitions, and even 3D transitions. So if you want your hero banner to feel a bit more dynamic, you have options beyond just a basic wipe from left to right.

One of the more powerful features is the layer system. This is what lets you stack content on top of your slides — things like text headings, images, and call-to-action buttons. You’re not just stuck with a background image. You can build a full visual composition on each slide with multiple layered elements. And all of this is done through the Smart Slider Editor, which is a drag-and-drop interface, so you don’t need to write code to build something that looks great.

SmartSlider3 Pro also supports video. You can embed YouTube videos directly, or use your own video files in common web video formats. That opens up a lot of creative options for video-first content.

Now let’s talk about how NZRT specifically uses SmartSlider3 Pro. We maintain a set of ready-to-use templates stored in a folder called SmartSlider. Inside that folder there are three template files. The first is for ICS, that’s the Internet Consulting Services business unit. The second is for Iteasel, the portable wooden display easel product line. The third covers Customer Sales Management. Each of those files is a self-contained SmartSlider export. When you import one, you get the full template including the module’s branding colors, the standard layouts and animations we’ve settled on, pre-configured call-to-action buttons that link through to the relevant module pages, and the correct logo and footer placement.

This means if you’re setting up a new page for one of those modules, you don’t start from scratch. You import the right template file and build from there.

To actually place a slider on a page, you use a shortcode. In practice, this is a short tag you drop into a WordPress page or post. It references the slider by its ID number — so if your slider has been assigned a particular ID inside the SmartSlider system, you’d paste the corresponding shortcode into your page content and WordPress handles the rest. You find that shortcode inside the SmartSlider dashboard, copy it, and drop it wherever you want the slider to appear. No code knowledge needed.

As for where sliders actually appear on the NZRT site, there are four main locations. The home page uses a slider to showcase featured products and services. Each module page has its own module showcase slider. The blog section uses a content carousel. And product pages use SmartSlider for product image galleries. So it’s quite spread across the site — almost any page that needs a visual highlight or rotating content is likely using SmartSlider3 Pro in some form.

If you want to dig deeper, the related wiki notes to look at are SmartSlider Templates, the RetroTube Theme, the Plugins Overview, and the Page Structure and Navigation guide. Those will give you more context on how SmartSlider fits into the broader WordPress setup at NZRT.

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

000WOR, 01 - WordPress Core

Theme Development

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

Let’s start with the basics. A WordPress theme controls how your website looks and behaves visually. It pulls together template files, stylesheets, and PHP functions to create the overall design experience. For NZRT, the theme in use is called RetroTube, and it’s been built with a video-focused design in mind.

To understand how a theme works, it helps to know what’s inside one. The wiki shows us a typical theme folder layout, and here’s what you’d find. At the top level there are several key files. The first is the main stylesheet — this is required for every WordPress theme because it contains a special header comment that tells WordPress the theme’s name and version details. Next is the functions file, which is the engine room of the theme — more on that in a moment. Then there’s a fallback template file that WordPress uses when it can’t find anything more specific. After that you have separate files for the site header and footer, a sidebar region file, and then a handful of more targeted templates: one for individual blog posts, one for static pages, one for category and date archive listings, and one for search results. Finally there’s an assets folder that holds your images, JavaScript, and any additional CSS files.

That structure gives you a clean separation of concerns. Each file has a job, and WordPress knows exactly which one to call depending on what the visitor is looking at.

Which brings us to something called the Template Hierarchy. This is the logic WordPress uses to decide which template file to load, and you can think of it as a priority list with three levels. WordPress always looks for the most specific file first. So if someone is viewing a custom post type called video, WordPress will look for a file dedicated to that post type before it falls back to the more general single post template. If it can’t find a specific match, it steps down to the general template. And if it still can’t find that, it uses the fallback index file as the final safety net. This hierarchy gives you a lot of flexibility — you can target very specific content types with custom layouts without touching anything else in the theme.

Now let’s talk about that functions file, because it does a lot of heavy lifting. This is where you tell WordPress what features your theme supports — things like featured images or custom navigation menus. It’s also where you register and load your stylesheets and JavaScript files, making sure everything is queued up properly rather than just dropped in manually. Beyond that, the functions file is where you add hooks and filters, which are WordPress’s way of letting you tap into the system at specific points to modify or extend behaviour. You can also define custom post types and taxonomies here if your content structure needs them.

For NZRT specifically, the RetroTube theme has been customised to support a video-heavy, module-based content structure. NZRT brand colours are built into the theme, and there’s support for virtual agent customisations — so the theme isn’t just handling aesthetics, it’s actively shaping how NZRT’s tools and content are presented to visitors.

One integration worth knowing about is SmartSlider 3 Pro. This is a slider plugin that works directly with the RetroTube theme templates to power the hero sliders — those large, full-width banner areas you typically see at the top of pages. Because it integrates at the template level rather than just being dropped in via a shortcode, you get much finer control over how those sliders look and behave across different page types.

So to bring it all together: a WordPress theme like RetroTube is a structured collection of files, each with a specific role. The folder layout keeps things organised, the template hierarchy gives WordPress a clear decision path for every page type you visit, and the functions file ties everything together with theme support declarations, asset loading, and custom logic. For NZRT, all of that is tuned to support a media-rich experience with brand consistency and tight plugin integration built in from the ground up.

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

000WOR, Text

Togaf Application Platform Service Categories

Welcome to the NZRT Wiki Podcast. Today we’re looking at Togaf Application Platform Service Categories.

If you’ve ever wondered what sits underneath an enterprise architecture — what kinds of services an application platform actually needs to provide — this episode breaks that down for you. TOGAF defines a comprehensive set of service categories, and together they describe every major capability a platform must support. Let’s walk through them one by one.

We start with Data Interchange Services. These cover how data moves and transforms between systems. Think document typing and conversion, graphics interchange, electronic data interchange, fax services, and raw graphics interface functions. It also includes text processing, document processing, publishing, video, audio, and multimedia processing functions, along with media synchronisation, information presentation and distribution, and hypertext functions. Essentially, anything to do with getting data from one form or place to another.

Next are Database Management System services. These include object-oriented database management, file management, query processing, screen and report generation, networking and concurrent access, and data warehousing. These are the services that let your platform store, retrieve, and present structured data.

Graphics and Imaging Services cover graphical object management, drawing services, and imaging functions. If your platform needs to render or manipulate visual content, this is the category that supports it.

Location and Directory Services are all about finding things. Directory services, special-purpose naming, service location, registration, filtering, and accounting services all live here. These help systems and users locate resources across a network.

Network Services are broad. They cover data communications, electronic mail, distributed data and file services, distributed naming and time services, remote process access, and remote print spooling. On top of that, you’ve got enhanced telephony, shared screen functions, video conferencing, broadcast functions, and mailing list functions. This category is the backbone of how distributed systems talk to each other.

Operating System Services keep things running at the foundation. Kernel operations, command interpreter and utility services, batch processing, and file and directory synchronisation services all sit here.

Software Engineering Services support how software is built. This includes programming language services, object code linking, computer-aided software engineering tools, graphical user interface building, scripting languages, language bindings, run-time environments, and application binary interface services. If you’re building or deploying software on the platform, these services are what you depend on.

User Interface Services are what users actually interact with. Graphical client and server services, display objects, dialogue support, printing, computer-based training and online help, and character-based services all fall into this category. This is where the platform meets the person.

Security Services are critical. You’ve got identification and authentication, system entry control, audit services, access control, non-repudiation, security management, trusted recovery, encryption, and trusted communication services. Together these ensure that only the right people and systems can do the right things, and that there’s a record when they do.

System and Network Management Services cover the operational side of keeping everything running. User management, configuration management, performance management, availability and fault management, accounting management, print management, network management, backup and restore, online disk management, licence management, capacity management, software installation, and trouble ticketing services. This is your operations team’s toolkit, built into the platform definition itself.

Finally, Object Request Broker Services handle distributed object communication. These include implementation repository services, installation and activation, interface repository services, and replication. Then there’s a rich set of common object services covering change management, collections, concurrency control, event management, externalisation, licensing, lifecycle management, naming, persistent object services, properties, query services, relationship services, start-up services, time services, trading services, and transaction services. This category is what lets distributed components find each other, communicate reliably, and maintain consistency across a system.

So when you look at all of these together — eleven major categories, hundreds of individual service types — you get a picture of just how comprehensive the TOGAF application platform model is. It’s not just about what your application does. It’s about every layer of capability the platform must provide to make that application possible.

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

000WOR, 08 - Security & Maintenance

Updates Maintenance

Welcome to the NZRT Wiki Podcast. Today we’re looking at Updates & Maintenance.

If you’re working with the NZRT WordPress setup, one of the most important things you’ll do on a regular basis is keep everything up to date. This isn’t just about getting new features — it’s about keeping the site secure and running smoothly. Let’s walk through how NZRT handles this.

First, let’s talk about the update schedule. There are five components that get attention on a recurring basis. WordPress core itself gets updated monthly, and the process for that is straightforward: test, update, then verify everything is working. Plugins follow the same monthly cycle with that same test, update, verify approach. Themes are handled as needed rather than on a fixed schedule, so they get the same treatment but only when there’s actually something to update. Then there are two components that run on a quarterly cycle rather than monthly. PHP — the language that powers WordPress under the hood — gets tested, updated, and then the server is restarted to apply the changes. MySQL, the database that stores all your site data, is also updated quarterly, following the same test, update, verify pattern.

Now, one important thing to know about the NZRT setup: there is no staging environment. That means every single update goes directly to the live production site. That might sound risky, and honestly, it makes the backup step completely non-negotiable. Before anything gets touched, you create a full site backup.

Let’s walk through the actual update procedure from start to finish. Step one is always the backup. You do this through Hoopla cPanel using JetBackup. This gives you a full snapshot of the site before any changes are made. If something goes wrong later, this is your safety net.

Step two is applying the update itself. You go into the WordPress admin panel, head to the Updates section, select the items you want to update — whether that’s WordPress core, specific plugins, or themes — and click the Update button. That part is actually quite simple.

Step three is verification. As soon as the update is done, you check the site. You’re looking at the home page, key pages, and making sure admin functions still work as expected. You’re not just assuming it went fine — you’re actively confirming it.

Step four only happens if something breaks. If the update causes a problem, you roll back by restoring from the backup you created in step one. That’s why the backup is so critical — it’s your escape hatch. After any update, you also want to keep an eye on the error logs to catch anything that might not be immediately visible on the front end.

Beyond the regular update cycle, there’s a set of ongoing maintenance tasks that keep the site healthy over time. Plugin audits are about reviewing what’s installed and removing anything that’s unused or outdated — unnecessary plugins are a security risk and can slow the site down. Theme cleanup works the same way: removing unused theme files keeps things tidy and reduces potential vulnerabilities. Database optimisation is handled using a tool called WP-Optimize, which cleans up and streamlines the WordPress database. Log rotation involves archiving old log files so they don’t pile up and cause issues. And security scans happen monthly — running a scanner to catch anything suspicious before it becomes a real problem.

In terms of who manages all of this at NZRT, it’s a two-person responsibility. The admin, known internally as xc, and the database administrator, dan, handle updates and maintenance between them. The whole philosophy here is proactive — staying on top of updates and maintenance before problems arise, rather than scrambling to fix security vulnerabilities or performance issues after the fact.

So to summarise: you back up before every update, no exceptions. You follow a monthly cycle for WordPress and plugins, a quarterly cycle for PHP and MySQL, and an as-needed approach for themes. And alongside those updates, you’re running regular audits, optimisations, and security scans to keep the site in good shape long-term.

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

000WOR, 09 - Reference

WordPress Functions Cheatsheet

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

If you’ve ever built a WordPress plugin or theme, you know how quickly you end up hunting through documentation just to remember the exact name of a function. This cheatsheet is your quick reference for the most common WordPress PHP functions — the ones you’ll reach for again and again. Let’s walk through them group by group.

We’ll start with posts, because that’s the heart of almost everything in WordPress. The first function lets you fetch multiple posts at once by passing in an array of arguments — things like post type, category, number of results, and ordering. You get back an array of post objects to loop through. If you only need one specific post and you already know its ID, there’s a simpler function that takes just that ID and hands you back a single post object. From there, if you’re inside the Loop — WordPress’s standard way of rendering content — you can call a function that just outputs the post title directly to the page. Same idea for the content. Another function handles creating or updating posts: you pass it an array of data describing the post, and WordPress takes care of inserting it into the database. And when you need to remove a post entirely, you pass its ID to the delete function and it’s gone.

Next up are hooks, which are one of the most powerful concepts in WordPress. Think of hooks as event listeners. There are two flavours: actions and filters. An action hook lets you attach your own function to a specific moment in WordPress’s execution — for example, right after a post is saved, or when the page header loads. You register your callback with the action hook name, and WordPress calls it at the right time. Filters are similar, but instead of just running code at a moment, they let you intercept a value, modify it, and pass it back. So if WordPress is about to output a piece of text, a filter lets you jump in and change what gets displayed. On the firing side, there are two corresponding functions — one that triggers an action hook so all attached callbacks run, and one that runs a value through all attached filters and returns the result. Understanding this four-function pattern — add action, add filter, do action, apply filters — gives you enormous flexibility in both plugins and themes.

Now let’s talk about the database layer. WordPress has its own options system for storing simple key-value settings, and there are two functions for it. One retrieves a stored option by name, and the other saves or updates a value against that name. These are perfect for plugin settings. For anything more complex, WordPress gives you access to a global database object. You can pass a raw SQL query string to it and execute it directly — useful for custom tables or complex queries that the higher-level functions don’t cover. Just be careful to sanitise your inputs properly when going this route.

Finally, we have user functions. If you need to know who’s currently logged in, there’s a function that returns their user ID — simple as that. Once you have that context, you’ll often want to check whether they’re allowed to do something before you let them. There’s a function for that too: you pass it a capability string — things like “edit posts” or “manage options” — and it returns true or false based on the current user’s role and permissions. This is the right way to gate functionality in WordPress rather than checking roles directly. And if you need to pull extra data stored against a user — things beyond their name and email, like custom profile fields — there’s a function that takes the user ID and a meta key and gives you back that stored value.

Tying it all together, this cheatsheet maps to three broader areas you’ll want to explore in the related notes: Plugin Development, Theme Development, and Hooks and Filters. The functions here are the building blocks that appear across all three. Whether you’re registering a custom post type, building a settings page, or intercepting content before it renders, you’ll almost certainly be combining functions from these four groups.

Keep this reference handy, and you’ll spend a lot less time digging through the WordPress developer docs and a lot more time actually building.

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.

000WOR, 01 - WordPress Core

WordPress Rest Api

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.

000WOR, 09 - Reference

Wp Cli Cheatsheet

Welcome to the NZRT Wiki Podcast. Today we’re looking at 💻 WP CLI Cheatsheet.

So let’s start with the basics. WP-CLI is the command-line interface for WordPress. What that means for you is that instead of logging into the WordPress dashboard in your browser and clicking through menus, you can type commands directly into a terminal and get things done faster. It’s especially useful when you’re managing sites remotely, running bulk operations, or automating repetitive tasks.

Let’s walk through the main command groups you’ll use day to day.

First up, posts. There are four key things you can do here. You can list all posts currently in the system, you can pull up a specific post by its numeric ID, you can create a brand new post by providing a title, and you can delete a post by its ID. Simple, direct, and no browser required.

Next, plugins. This is where WP-CLI really shines. You can list all installed plugins so you can see what’s active and what’s not. You can activate a specific plugin by name, deactivate it, or install a new one straight from the WordPress plugin repository. And if you want to keep everything up to date in one go, there’s a command to update all plugins at once. That last one is a real time-saver on sites with a lot of plugins.

Then there’s user management. You can list all users on the site, create a new user by supplying a username, an email address, and a role like editor or administrator, delete a user by their ID, and even add specific capabilities to a user account. That last one is handy when you need to grant someone a particular permission without changing their entire role.

Moving on to the database. WP-CLI gives you three essential database commands. You can export the entire database to a SQL file, which is great for backups before you make any big changes. You can import a SQL file back in, which is useful for restores or migrations. And you can run an optimize command, which cleans up the database tables and can help with performance on older or high-traffic sites.

Finally, options. WordPress stores a lot of site configuration in what it calls options. You can retrieve the value of any option by name, update it with a new value, or list everything in one go. A common use case here is updating the site URL when you’re migrating a site from one domain to another.

Now, an important practical note. WP-CLI availability on your Hoopla shared cPanel hosting is not guaranteed. It depends on what the host has installed. The best way to check is to open an SSH terminal session through cPanel and see if the command is recognised. If it’s not available, don’t worry. You can fall back to the WordPress admin interface or cPanel’s built-in tools to accomplish the same things.

If you do have SSH access and WP-CLI is not installed, you can install it yourself. The process involves four steps. You download the WP-CLI package file using curl, you make that file executable, you move it to a system location so it’s available as a global command, and then you verify the installation by checking the version number. Once that’s done, you’re good to go.

One thing to keep in mind when using WP-CLI: you generally need to run commands from inside the WordPress installation directory, or point the tool at the correct path. If you’re getting errors about WordPress not being found, that’s usually the first thing to check.

For anyone at NZRT working on WordPress projects, WP-CLI pairs well with the broader WordPress workflow. The wiki has related notes covering WordPress as a platform, plugin development, and theme development, so if you want to go deeper on any of those areas, those pages are worth a look.

To recap what we covered today: WP-CLI lets you manage WordPress entirely from the command line. You can handle posts, plugins, users, the database, and site options all without touching the browser. On shared hosting like Hoopla, check SSH first to confirm availability. And if you need to install it yourself, it’s a four-step process that takes only a few minutes.

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

000WOR, 03 - Plugins Reference

Youtube Mass Videos Importer

Welcome to the NZRT Wiki Podcast. Today we’re looking at YouTube Mass Videos Importer.

So, what does this plugin actually do? In short, it lets you pull multiple YouTube videos into WordPress in one go, rather than adding them one by one. At NZRT, we use it specifically for loading product demonstrations, tutorials, and promotional videos onto our WordPress site, and it saves a significant amount of manual effort when you have a lot of video content to manage.

Let’s talk about what it can do. There are five main features worth knowing about. First, bulk import. You can bring in multiple videos at once by providing either a CSV file with a list of YouTube URLs or by pointing the plugin at an entire YouTube playlist. Second, custom fields. The plugin lets you map YouTube video data, things like the video title, description, and tags, directly to custom post fields in WordPress. So you have control over how that data lands in your content structure. Third, thumbnail download. When a video is imported, the plugin can automatically download the thumbnail image from YouTube and attach it to the post. You don’t have to manually grab screenshots or upload images yourself. Fourth, post creation. The plugin can automatically create WordPress posts with the video embeds already in place. So once the import runs, you end up with ready-to-publish content. Fifth, scheduled import. You can set imports to run on a schedule, which means if you regularly add videos to a YouTube playlist, the plugin can keep your WordPress site in sync automatically without you having to trigger it each time.

Now let’s walk through how an import actually works. You start by providing your YouTube URLs or a playlist link. Then you configure your import settings, and here you’re choosing things like what post type to create, which author to assign the posts to, and what category they should fall under. After that, you do the field mapping step. This is where you tell the plugin to take the YouTube video name and use it as your post title, or take the video description and put it in the post body, and so on. Once everything is configured, you execute the import. Finally, you verify that the posts have been created correctly by checking them in WordPress.

In terms of how NZRT actually uses this tool, there are four main use cases. Product demo videos, so if we have demonstrations of something we’re showcasing, those get pulled in here. Tutorial content, educational videos that support our services or tools. Promotional videos, marketing material that lives on YouTube and needs to be surfaced on our WordPress site as well. And customer testimonial videos, provided those testimonials have been uploaded to YouTube in the first place.

If you’re exploring related areas in the wiki, this page connects to the Adult Mass Videos Embedder documentation, the general Plugins Overview, and SmartSlider3 Pro, all of which are worth looking at if you’re working with media and video content on the NZRT WordPress setup.

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

000WOR, 03 - Plugins Reference

Wpcat2Tag Importer

Welcome to the NZRT Wiki Podcast. Today we’re looking at WPCat2Tag Importer.

If you’ve ever worked with a WordPress site that’s been around for a while, you’ve probably run into a situation where the taxonomy — that’s the way content is organised using categories and tags — has gotten a bit messy over time. Maybe categories were set up in a hurry early on, or the site’s content strategy changed, and now what used to be organised as categories would make more sense as tags, or the other way around. That’s exactly the problem WPCat2Tag Importer is designed to solve.

At its core, WPCat2Tag Importer is a WordPress plugin that migrates content between two of WordPress’s built-in taxonomy types: categories and tags. You can go either direction — converting categories into tags, or converting tags back into categories. This gives you real flexibility when you’re restructuring how your site’s content is labelled and discovered.

Let’s walk through what the plugin actually does, and why each feature matters.

The first thing to know is that it supports bulk migration. Rather than going post by post and manually reassigning taxonomy terms, you can run the conversion across your entire content library in one operation. If you’ve got hundreds or thousands of posts, that’s a massive time saver.

Next up is hierarchy handling. WordPress categories support parent-child relationships — so you might have a category called Technology with subcategories like Hardware and Software underneath it. Tags, on the other hand, are flat — they don’t have a hierarchy. WPCat2Tag Importer gives you the option to flatten that hierarchy when you convert. So if you’re moving categories to tags, it can take those nested structures and bring everything up to the same level. That’s worth thinking through carefully before you run the migration, because once you flatten, those parent-child relationships are gone.

One of the most important features — and this is good practice for any bulk operation — is the preview step. Before the plugin actually makes any changes, you can run a preview to see exactly what’s going to happen. Which categories are going to become tags, how many posts will be affected, what the end result will look like. You review that first, and only then do you execute. This is what the documentation calls safe operation, and it’s genuinely useful for catching anything unexpected before it becomes a real problem.

After migration, you’ve also got the option to set up URL redirects. This matters because when categories become tags, the URLs change. A URL that used to point to a category archive page will no longer work unless you redirect it. The plugin can handle that automatically, which helps you avoid broken links and keeps your search engine rankings intact.

Finally, you get a detailed log report after the migration runs. This gives you a record of everything that changed — useful both for troubleshooting and for documenting what was done, especially if you’re working as part of a team.

Now, where does NZRT actually use this? There are a few specific scenarios called out in the wiki. One is converting category-based module organisation into tags. If content was originally bucketed into categories to represent modules or sections, and the site’s architecture has evolved to where tags are a better fit, this plugin handles that shift cleanly.

Another use case is migrating a legacy category structure. Older WordPress sites often accumulate categories over time without a clear plan, and WPCat2Tag Importer gives you a way to clean that up as part of a broader content reorganisation.

The third scenario is consolidating taxonomy after content reorganisation. If you’ve just gone through a significant restructure — merging content, removing sections, rebranding — the taxonomy often needs to catch up, and this plugin is the tool for that job.

If you want to dig deeper, the wiki points you to three related notes. There’s one on Post Types and Taxonomies, which gives you the broader WordPress content model context. There’s a Plugins Overview, which is the master list of plugins in use across the site. And there’s a note on JC Importer, which handles a different kind of import workflow if you need to bring content in from external sources rather than reorganise what’s already there.

So to sum up: WPCat2Tag Importer is a focused, flexible, and safe tool for reorganising WordPress taxonomy. Preview first, think through your hierarchy options, make sure redirects are enabled if your URLs matter, and always review the log once it’s done.

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

000WOR, 03 - Plugins Reference

Wp Script Core

Welcome to the NZRT Wiki Podcast. Today we’re looking at WP-Script Core.

So let’s start with the big picture. WP-Script Core is a custom WordPress plugin built by NZRT. Its job is to extend the RetroTube theme — that’s the theme running on nzrtnetwork.com — with frontend user interface scripting capabilities. In plain terms, it’s a tool that sits on top of the theme and gives it extra powers on the browser side of things, the part that visitors actually see and interact with.

Now, before we go any further, there’s one thing worth calling out clearly, because it’s a common point of confusion. WP-Script Core is not a Dolibarr integration bridge. You might be wondering what that means. Dolibarr is the ERP system NZRT uses — it handles things like projects, tickets, invoices, and agent workflows. You might assume that because WP-Script Core is a WordPress plugin and NZRT connects WordPress to Dolibarr, this plugin must be the thing doing that connection work. It isn’t. When WordPress agents need to talk to Dolibarr, they call the Dolibarr REST API directly, using their own per-agent API keys. That happens completely separately from this plugin. WP-Script Core has nothing to do with that pipeline.

So what does WP-Script Core actually do? Its purpose breaks down into three main areas.

The first is theme UI extension. This is the core reason the plugin exists. It adds frontend scripting and layout features to the RetroTube theme that the theme doesn’t provide out of the box. Think of it as a companion layer that sits alongside the theme and enhances what it can do visually and behaviourally.

The second area is custom scripts. The plugin handles the injection of page-specific scripts and styles. What this means in practice is that certain pages on nzrtnetwork.com can have their own scripts loaded precisely when and where they’re needed, rather than having everything loaded globally all the time. This keeps things clean, targeted, and performant.

The third area is NZRT branding. Beyond generic layout features, the plugin implements custom theme behaviours that are specific to nzrtnetwork.com. These are the little things that make the site feel distinctly NZRT — behaviours, interactions, and styling choices that reflect the brand and wouldn’t belong in a general-purpose theme.

Putting it all together, WP-Script Core is really about making the RetroTube theme work exactly the way NZRT needs it to for their specific site. The theme provides the foundation, and WP-Script Core builds on top of that foundation on the frontend.

If you’re working in this area and you need to understand how Dolibarr connects to WordPress more broadly, the wiki has related notes you can follow up on. There’s a Dolibarr REST API Setup note, a WP-Dolibarr Integration Overview note, a WordPress REST API note, and a Plugins Overview note. Those will give you the full picture of how the different moving parts connect at the system level. But just remember — WP-Script Core isn’t part of that integration chain. Keep it in its lane: frontend, theme, UI scripting, branding.

One last thing worth reinforcing as you work with this plugin. Because it operates at the theme UI layer, changes you make here will have direct visible effects on the site for anyone visiting nzrtnetwork.com. It’s not a backend utility running quietly in the background. It touches what users see. So treat modifications carefully, test in context, and be mindful that the RetroTube theme and WP-Script Core are working as a team — changes to one can interact with the other.

That’s the essence of WP-Script Core. A custom plugin, tightly scoped to frontend UI work on the RetroTube theme, with no role in Dolibarr integration, and three clear jobs to do: extend the theme’s layout capabilities, inject page-specific scripts and styles where needed, and deliver the custom behaviours that make nzrtnetwork.com feel like NZRT.

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