frankarr

In June 2012, an Australian developer named Shea Bunge got annoyed at their web host. It wouldn’t let them edit their theme files directly. So they built a plugin to work around it: a simple interface for adding PHP to WordPress without touching functions.php. They called it Code Snippets. Each snippet gets a name, a toggle, and a text box. That’s basically it.

Most people use it to add a Google Analytics tag or disable the WordPress admin bar. A handful of lines, a checkbox, done.

We use it to run a website. This is my love letter 💌 to Code Snippets.

The count

Right now, SmallBizAI has 34 active snippets doing real work on every page load. That’s not 34 Google Analytics tags. That’s 34 distinct pieces of logic, each solving a specific problem, each one added because something on the site needed to work a certain way and a full plugin felt like overkill.

Some are three lines. Some are a hundred. A few of them I’d describe as clever. One of them nearly took the site down, and I learned more from that one than from all the others combined.

The plumbing nobody sees

The most invisible snippets are the ones preventing things from going wrong.

When you run Jetpack alongside a dedicated SEO plugin, you end up with two systems both trying to write the same Open Graph tags into every page’s HTML. Two og:title tags. Two og:description tags. Social platforms and search crawlers don’t handle that gracefully. The fix is a snippet that tells Jetpack to stand down. One filter, four lines, problem gone permanently. It runs silently on every page load and has never needed touching since.

Same story with sitemaps. Two plugins, both generating sitemaps, both trying to claim the canonical URL. One snippet redirects all sitemap traffic to the right place. It’s been running since the early days and I forget it exists most of the time. That’s exactly what good infrastructure should feel like.

There’s also a redirect guard. Early on, some catch-all redirect logic occasionally misfired on canonical URLs, sending the site into a redirect loop on its own pages. A snippet with a higher priority fires first and blocks that from happening. It’s a bouncer for the redirect system.

And then there’s the one-liner: a snippet that caps WordPress post revisions at three per post. Left unchecked, WordPress saves every single revision indefinitely. On a site this size that’s thousands of rows of dead weight in the database. One line of PHP, problem permanently contained.

Connective tissue

The snippets I rely on most aren’t the dramatic ones. They’re the connective tissue, the bits that wire different systems together in ways no existing plugin was designed for.

When someone buys something through Gumroad, a webhook fires. That webhook hits a snippet. The snippet parses the purchase, figures out which product group it belongs to, adds the buyer to the right MailerLite subscriber group, and logs the transaction to a database table. All in a single request cycle. No Zapier. No Make. No third-party automation platform with its own account, pricing tier, and single point of failure. Just PHP running on the same server as the rest of the site.

The newsletter signup form works the same way. The form on the site posts to a custom REST endpoint registered by a snippet. That endpoint validates the submission, calls the MailerLite API, handles the response, and returns a proper JSON result to the browser. It’s the entire backend of the subscription system. When it went down once (a token rotation I forgot to update in two places) I knew exactly where to look and had it fixed in minutes. No support tickets. No waiting on a third-party platform. The logic was right there in front of me.

There’s a snippet that listens for new Gumroad purchases and immediately fires a notification to Telegram. There’s one that receives MailerLite webhooks when a new subscriber confirms — and sends a (tastefully masked) notification. These feel small, but the cumulative effect is a site that tells me what’s happening in real time without me having to go check dashboards.

Gumroad also shows up on the content side. A shortcode registered by a snippet drops a matched product CTA after the first paragraph of relevant industry posts. The right prompt pack for the right audience, automatically. Another shortcode renders a full product card anywhere on the site with a single tag. Drop [gumroad_upsell product="200-prompts"] into a page and it renders the name, price, and buy link. The product details live in the snippet; the pages stay clean. Add a new product, update one place, every instance updates.

Live data everywhere

One of the things that bothered me early on was hardcoded numbers. Pages that said “178 posts” when we had 300. Category pages with “explore our 12 guides” when we had 40. Every time we published something, something else was silently wrong.

The fix is a shortcode registered by a snippet. Drop it into any page, it queries the live post count and outputs the number. No caching quirks. It’s always right. That shortcode now appears on the homepage, the About page, the Resources page, the Topics page, and the AU Companies page. Every one of them shows the correct number, always, without anyone touching them. Same approach for series post counts: a snippet registers a shortcode that takes a category as a parameter and returns the live count. Add a new episode to any series, every reference to that series count updates automatically.

The Sunday Specials section of the homepage works this way too. Rather than baking the current episode into page content (which would need manual updating every week), a snippet registers a REST endpoint and a shortcode. The publish script calls that endpoint on Sunday morning, stores the current episode data, and the shortcode renders it dynamically on every page load. The homepage never needs to be touched. It just knows.

The Sunday Specials hub page takes the same approach for upcoming episodes. A separate shortcode reads from a stored option — a JSON array set by the pipeline script — and renders the “coming up” list dynamically. The list is always current. Nobody maintains it manually.

The SEO layer

Rank Math handles SEO. But Rank Math’s data isn’t exposed to the REST API by default, which makes programmatic SEO work basically impossible: auditing hundreds of posts, checking meta coverage, updating focus keywords in bulk.

One snippet fixes that. It registers Rank Math’s meta fields with the WordPress REST API. Now every script that talks to WordPress can read and write SEO meta the same way it reads and writes post content. That single change unlocked the entire automated SEO audit stack.

There’s also a snippet that fires on every publish and auto-derives a focus keyword from the post title if one hasn’t been set. It strips stop words, applies a few AU-specific rules for posts targeting Australian categories, and sets the keyword. Not perfect, but 95% of posts go live with something sensible set rather than blank, and it costs nothing to run.

Redirects get their own snippet: a custom REST endpoint that lets scripts create, update, and delete Rank Math redirections programmatically. When the 404 monitor finds a URL pattern that needs a redirect, it calls this endpoint. No browser, no manual steps, no WP Admin. The redirect exists thirty seconds after the 404 was detected.

The publishing layer

A snippet auto-injects hub backlinks when posts are published. Every post in a hub category gets the right footer link added automatically, pointing back to the hub it belongs to. Before this existed, every post needed a manual check. Now it happens at publish time and I never think about it.

The hub pages themselves are powered by a custom REST endpoint: a snippet that accepts a category ID and page size, then returns posts with title, link, date, and excerpt in a clean JSON response. Every hub rebuild script calls this endpoint. It’s the data layer the whole hub system sits on top of.

And there’s the mascot. A snippet in the footer loads a small JavaScript data array (43 mascots, each with a name, image URL, and destination link) and rotates a random one into the homepage widget on every page load. Active mascots link to their hub. The ones in the waiting room link to the mascot library. It’s probably the most unnecessary snippet on the site and also one of my favourites.

There’s one that handles reading time, auto-calculating it from word count and setting it as post meta on publish. Another adds word count and last-updated columns to the WP Admin posts list, so you can see at a glance which posts are thin and which ones haven’t been touched in six months. A stale news flag fires on any news post older than 90 days and marks it in the admin. Time-sensitive content has a shelf life.

Google Search Console verification lives in a snippet. GA4 tracking lives in a snippet. The chrome-free template that strips the header and footer from private dashboard pages — snippet. The WP Admin dashboard widget that shows publishing stats for the month — snippet.

The admin layer

WordPress ships with a decent admin interface. It tells you whether a post is published, when it was published, and who wrote it. That’s about it.

For a site running 1,300+ posts across 41 industries, that’s not enough. So there are snippets for that too.

The posts list now has two extra columns: word count and last updated. At a glance, I can see which posts are thin (under 600 words and probably needs expanding) and which ones haven’t been touched in six months (and might need a refresh). No plugin. No paid SEO tool. Just two columns that WordPress should have included anyway.

The WP Admin dashboard has a widget showing every published post or page with zero views in the last 90 days. It pulls from the Jetpack stats API, caches for 12 hours, and lets you sort by title, type, or publish date. There’s a CSV export button if you want to take the list somewhere else. The idea is simple: if something has been live for three months and nobody has found it, that’s either a distribution problem or a content problem — but you have to know it exists before you can fix it.

Another widget shows published post count grouped by month since launch. It’s the publishing cadence in one screen — easy to see the months where output dropped, the months where we pushed hard, the overall trajectory. And there’s a companion widget for top publishing days: the ten days with the highest single-day output since April 2026. Mostly useful for spotting patterns (Tuesdays, as it turns out).

None of these required installing anything. Each one is a snippet — a dashboard widget registered with wp_add_dashboard_widget(), querying data that was already there. The admin interface WordPress gives you is fine for a five-page brochure site. For something this size, you build the tools you actually need.

What I’ve learned from this

Every snippet in that list started the same way: something on the site needed to work differently than it did out of the box, and the options were a) install a plugin, b) edit core theme files, or c) write 20 lines of PHP in a sandbox where I can toggle it off instantly if something breaks.

Option C has won every time.

One thing I wish I’d known earlier: Code Snippets has a safe mode. If something goes wrong and you can’t get into the admin, you can disable all snippets instantly by adding a parameter to the URL. No login required. Given that one of our snippets nearly took the site down, I could have used that.

One more thing worth saying: I didn’t write a single one of these snippets. I described what I needed, in plain English, in a chat window, and Claw wrote the PHP. Every webhook handler, every shortcode, every dashboard widget. The AI agent built the invisible engine. That feels like the most Behind the Build detail of all.

Plugins are fantastic for things that need a proper UI, regular updates, and significant functionality. But for the connective tissue, the wiring that makes your specific site do your specific things, plugins are often too much. They add admin pages you don’t need, settings you’ll never change, and database overhead for features you’re not using. A snippet does one thing, you can read the whole thing in two minutes, and if it breaks you can switch it off without touching anything else.

There’s also something about ownership. When the logic that runs your newsletter signups lives in a plugin built by someone else, you’re dependent on that plugin’s update cycle, support queue, and continued existence. When it lives in a snippet you wrote, you understand every line of it. That’s a different relationship with your own infrastructure.

I’ve thought about this a lot as we’ve built the AI layer on top of the site: the scripts, the crons, the automated publishing pipeline. The principle is the same. Keep the pieces small, keep them readable, keep them switchable. A 30-line snippet that does exactly one thing is almost always better than a 3,000-line plugin that does 50 things and charges $9/month for the pro tier.

Code Snippets gave us that. It’s not glamorous software. It doesn’t have an AI feature. It’s just a clean, reliable place to put logic that needs to live somewhere, and it’s quietly running 34 jobs on this site right now without anyone noticing.

That’s the best kind of tool.