Tag Archives: wordpress

000GIT, 05 - Integrations

WordPress Github Integration

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

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

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

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

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

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

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

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

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

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

000NCL, 05 - Integrations

WordPress Integration

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

If you work with NZRT’s content or user management systems, this episode is going to give you a clear picture of how Nextcloud and WordPress talk to each other — and why that connection matters for your day-to-day work.

Let’s start with the big picture. Nextcloud and WordPress are integrated across three main areas: user authentication, media asset storage, and collaborative content editing. Nextcloud acts as the media library backend for WordPress, meaning it’s the central place where files live, and WordPress pulls from it rather than managing everything on its own.

Let’s talk about user sync first. NZRT uses something called LDAP and single sign-on, or SSO, to connect accounts between the two systems. What that means for you practically is this: when a new Nextcloud user is created, a corresponding WordPress user gets created automatically. And you only need one password for both platforms. You log in once and you’re covered across both systems — no separate credentials to manage.

Now let’s look at media management. WordPress media assets — things like images, photos, and press release files — are stored in Nextcloud rather than sitting inside WordPress itself. This happens through the REST API, which is essentially a way for the two systems to communicate and pass data back and forth. The specific folder in Nextcloud that handles this is called WordPress Media, and it’s shared with the content team. Featured images and uploads get automatically backed up there too, so you have version control and an archive without any extra effort on your part.

To give you a sense of how the technical side is configured, there is a setup that points the WordPress LDAP plugin to an internal server address, specifies a base directory location for user accounts, and sets a user path within that directory. On the Nextcloud side, there is an API endpoint pointing to the WordPress Media folder, using a combination of a username and a token to verify access. You do not need to memorise any of that, but it is worth knowing these two systems are talking to each other constantly in the background.

Now let’s walk through the actual content workflow, because this is what you will interact with most. An editor logs into WordPress using their normal single sign-on credentials. From there, an author writes a blog post inside WordPress. But here is where Nextcloud steps in: draft documents live in a Nextcloud folder called WordPress Drafts, and the team can edit those directly using Nextcloud Office, the built-in collaborative editing tool. Once a post is ready to publish, the featured image auto-syncs from the Nextcloud media folder into WordPress. And when the post goes live, a version is saved into a Nextcloud archive folder for long-term storage.

So you can think of it as a two-track system. WordPress is your publishing front-end — it is where the post goes live and where readers see it. Nextcloud is your back-end storage and collaboration layer — it is where files live, where the team edits together, and where everything gets archived.

Speaking of folders, here is how the Nextcloud WordPress directory is structured. At the top level there is a folder called WordPress. Inside that you have a Media folder, which contains three subfolders — one for Blog images, one for Press Releases, and one for Photos. Then there is a Drafts folder, where you would find documents like a named blog post file for a specific month. And finally there is a Published Archive folder, where completed posts are stored for reference.

The key people working within this integration at NZRT are pam and ema — the content team — who use Nextcloud Office to collaborate on blog posts before they go live. By keeping media assets in Nextcloud rather than relying on WordPress alone, the team gets version control, easy sharing, and a reliable archive all in one place.

If you want to dig deeper, there are a few related topics worth exploring. There is an Integrations Overview document that gives you the wider picture of how NZRT’s systems connect. There is also a dedicated page on LDAP and SSO if you want to understand the authentication side in more detail. And Nextcloud Office is worth a look if you are going to be collaborating on drafts.

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

Post Types Taxonomies

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

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

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

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

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

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

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

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

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

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

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

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

000WOR, 01 - WordPress Core

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, 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

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.