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.

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.

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.