Category Archives: 09 – Reference

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