Most WordPress snippet collections focus on micro-optimizations: shaving milliseconds off page loads, disabling features you forgot existed, tweaking things nobody notices. That’s fine, but it’s not particularly useful when you’re managing real client work.
These five snippets solve actual workflow problems. They’re the ones I find myself reaching for multiple times a week, not because they’re clever, but because they handle situations that come up constantly in a professional WordPress development environment.
1. Create an Admin Account Programmatically
When you need this: You’re working with a client site. Previous developer’s account was removed. Client isn’t responding to email. You have SFTP access. You need to fix something now.
The code:
How to use it: Add this to functions.php via SFTP, refresh any page once, then immediately remove the code. You can now login with the credentials placed in the code.
Important: Remove this code as soon as you’ve created your admin account. This is a temporary access tool, not something that should live in your codebase.
2. Display Active Template in Admin Bar
When you need this: I often inherit WordPress sites that are developed in strange ways. Sometimes, finding the template associated with a page isn’t always immediately obvious. This code snippet adds immediate visibility of the template in-use.
The code:
What it does: Shows the current template filename in your admin bar with a direct link to edit it. Simple, visible, saves several clicks every time you need to know which template is rendering.
Why it’s useful: Add this to your theme or a mu-plugin once, and you’ll stop asking yourself “which template is this?” every time you’re debugging template hierarchy issues.
3. Lock Content Updates
When you need this: A new feature needs to be developed on an existing site that contains database changes. You start working on staging, and inevitably, the work takes longer than expected to be signed off by the client. In the meantime, the client has made multiple changes to content on the live site. Now you’ve got to manually copy content from staging to live. You could, of course, use a database sync plugin but it’s safer just to lock the site down while you make the changes.
The code:
What it does: Prevents access to all pages except WooCommerce orders, which clients will often use to see their recent orders and the customer data. With the new WooCommerce HPOS system, you can selectively just ignore the HPOS tables when moving your database environment over from staging to live, which saves a headache.
Why this approach: Blocking admin access to content pages means the clients can’t then find pages. You could lock them out the admin panel altogether, but if the client needs partial access to view (like the WooCommerce side), this solution allows that.
4. Prevent search indexing on staging environments
When you need this: I’ll take an educated guess that in every WordPress developer’s career, they’ve accidentally had staging sites indexed or worse, live sites de-indexed when moving environments around. There are, of course, methods to handle different environments, such a .env files. However, setting them up can be a chunk of time added to any project. As a freelancer, I often work with multiple environments and setups that can sometimes prohibit these alternative options or I just end up forgetting. I therefore came up with this snippet of code that handles cross environment handling. Granted, it’s not effective 100% of the time as you’d need to know every possible URL that may be used for staging sites. If you use a pattern (like a subdomain staging.site.com), this would suit your workflow nicely.
The code:
What it does: If the URL is a staging or local URL, it will automatically set blog_public option to false to prevent the site being indexed by search engines. Equally, if the site is LIVE, it’ll stop your site from being de-indexed.
Practical application: Ideally, you’d bake this code snippet into your starter theme as a set and forget but you could also make it an mu-plugin or even just a standard plugin but beware the latter may be far less effective as plugins can easily be turned on or off.
5. Disable Admin Email Verification
When you need this: WordPress periodically asks you to verify your admin email address. When managing multiple client sites, this becomes a regular interruption—especially when you’re trying to handle something urgent.
The code:
add_filter('admin_email_check_interval', '__return_false');
What it does: Disables the admin email verification prompt entirely. One line, no complexity.
When to use it: This makes sense in agency environments where admin emails are managed centrally and verification adds no security value. If you’re managing your own sites and handle admin email changes through proper procedures anyway, this removes an unnecessary interruption.
Building a Useful Snippet Library
The value in maintaining a snippet library isn’t about collecting every possible solution you find online. It’s about curating answers to problems you actually encounter repeatedly.
When you solve the same problem twice, that’s a signal to save the solution. When you find yourself thinking “I’ve done this before,” add it to your library. When a plugin seems excessive for a simple task, write a snippet instead.
Organization matters. Tag snippets with relevant keywords: language, framework, category, use case. When you need something under deadline pressure, you’ll find it in seconds rather than minutes.
The best snippet library is one that reflects your actual work. These five snippets are mine. Yours might look different based on the types of projects you handle, the frameworks you use, and the problems you encounter most often.
The goal is the same: stop solving the same problems repeatedly. Save the solution once, use it every time you need it.