WordPress lets you customize a site in more ways than most people realize, and plugins aren’t the only route there. For a small, specific change, a short code snippet often does the job with less overhead than installing an entire plugin for one feature. These snippets can live directly in your theme’s functions.php file, or get managed through a plugin like WPCode if you’d rather keep them out of theme files entirely. Either way, the result is the same: a site that does exactly what you want without extra weight. Whether you want to hide the admin bar, display popular posts, or add a PayPal donation button, a snippet usually gets there faster than a plugin search.
Below are fourteen snippets worth knowing, covering navigation, security, performance, and a handful of smaller conveniences that tend to come up on almost every WordPress build. None of them require deep PHP knowledge to use, just a careful copy-paste and a basic understanding of where each one belongs.
1. Disable the WordPress admin bar
The admin bar sits at the top of the screen for logged-in users, and while it’s useful for administrators, it’s not always necessary for every role on the site. Add this to your theme’s functions.php file:
add_filter('show_admin_bar', '__return_false');
This removes the admin bar entirely for all users, administrators included. If you only want to hide it for specific roles, like subscribers or contributors, wrap the filter in a conditional check against current_user_can() so admins keep their bar while everyone else loses it.
2. Change the default login logo
Replacing the WordPress logo on the login screen with your own branding is one of the more visible customizations a snippet can make:
function custom_login_logo() {
echo '<style type="text/css">
h1 a { background-image: url(your-logo-url.png) !important; }
</style>';
}
add_action('login_head', 'custom_login_logo');
Replace your-logo-url.png with the direct URL of your logo image. For best results, size the image close to the login page’s default logo dimensions, roughly 320 by 84 pixels, so it doesn’t look stretched or cropped.
3. Disable the WordPress emoji script
WordPress loads a script by default so emoji render consistently across older browsers, which is rarely necessary on a modern site and adds a small amount of load weight for every visitor. Disable it with this pair of lines:
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');
The performance gain here is small on its own, a few kilobytes and one fewer script request, but it’s a genuinely free win with no downside on any site running a modern browser audience.
4. Redirect users after login
Sending users somewhere specific after they log in, rather than the default admin dashboard, is useful for membership sites or anything where “admin” isn’t the destination that makes sense for most users:
function custom_login_redirect($redirect_to, $request, $user) {
return home_url('/dashboard');
}
add_filter('login_redirect', 'custom_login_redirect', 10, 3);
Replace /dashboard with wherever users should land. For sites with multiple roles needing different destinations, check $user->roles inside the function and return a different URL depending on the role.
5. Remove the WordPress version number
Displaying your exact WordPress version in the page source gives potential attackers a head start on knowing which vulnerabilities might apply to your site. Hide it with:
remove_action('wp_head', 'wp_generator');
This is a small security-through-obscurity measure rather than a real defense on its own, since a determined attacker has other ways to fingerprint a WordPress install by checking file paths, readme files, or plugin-specific assets. Still, there’s no reason to leave the version number sitting in plain view for free, and pairing this with keeping WordPress core and plugins actually updated does far more for real security than hiding a version string ever could on its own.

6. Limit post revisions
WordPress saves a new revision every time you update a post, and on a site with heavily edited content, that history can quietly bloat the database over time. Cap it with:
define('WP_POST_REVISIONS', 3);
This keeps only the last three revisions of each post. Add this constant to wp-config.php rather than functions.php, since it needs to load before most of WordPress does. A site with years of frequently edited posts can see a real reduction in database table size after applying this and cleaning up existing old revisions, and a smaller wp_posts table means faster backups and a snappier admin post list too.
Cleaning up the revisions that already exist takes a separate step, since this constant only limits future revisions rather than retroactively trimming what’s already stored. A plugin like WP-Optimize, or a direct database query for anyone comfortable with SQL, handles clearing the backlog once the limit is in place.
7. Add a custom dashboard widget
A custom widget on the WordPress dashboard is a simple way to leave instructions, reminders, or branding for whoever else logs into the site:
function custom_dashboard_widget() {
echo '<p>Welcome to your WordPress site! Manage your content wisely.</p>';
}
function add_custom_dashboard_widget() {
wp_add_dashboard_widget('custom_widget', 'Custom Message', 'custom_dashboard_widget');
}
add_action('wp_dashboard_setup', 'add_custom_dashboard_widget');
This is especially handy on client sites, where a short note about who to contact for support saves a support email six months down the line when nobody remembers who built the site.
8. Disable right-click on images
Preventing casual image saving through the browser’s right-click menu is a light deterrent, worth setting expectations about upfront: it stops nothing but the most casual attempt, and anyone with basic browser tools can still save the image regardless.
function disable_right_click() {
echo '<script type="text/javascript">
jQuery(document).ready(function() {
jQuery("img").on("contextmenu", function() {
return false;
});
});
</script>';
}
add_action('wp_footer', 'disable_right_click');
For actual image protection against reuse or theft, a watermarking or DRM approach does far more than blocking a right-click menu ever will.
9. Remove the “Proudly powered by WordPress” footer text
Most default and many third-party themes print a credit line in the footer through a specific function tied to that theme. Removing it looks like this:
function remove_footer_credit() {
remove_action('wp_footer', 'twentytwentyone_credit');
}
add_action('init', 'remove_footer_credit');
The function name in the snippet, twentytwentyone_credit, is specific to the Twenty Twenty-One theme. Other themes use a different function name for their own footer credit, so check your theme’s footer template or functions file to find the correct hook name before this will actually remove anything.
10. Enable shortcodes in widgets
WordPress doesn’t process shortcodes inside text widgets by default, which trips people up the first time they try dropping one into a sidebar widget and nothing happens. Fix it with:
add_filter('widget_text', 'do_shortcode');
After adding this, any shortcode placed in a text widget renders exactly like it would in a post or page, which opens up widgets to plugin-generated content that previously only worked in the main content area.
11. Disable XML-RPC
XML-RPC exists for legacy remote publishing tools and the WordPress mobile app, but it’s also a common target for brute-force login attempts and pingback abuse. If nothing on your site actually uses it, turning it off closes that attack surface:
add_filter('xmlrpc_enabled', '__return_false');
Before disabling it site-wide, confirm nothing you rely on, certain mobile publishing workflows or specific plugin integrations, actually depends on XML-RPC being active. For most standard WordPress sites publishing through the block editor, it’s safe to turn off, and the reduction in brute-force login noise in your server logs is often noticeable within the first week.
Some security plugins offer a toggle for this exact setting in their dashboard, which is worth checking before adding a redundant snippet if you’re already running one. Duplicating a setting that’s already being enforced elsewhere just adds a line of code with nothing extra to show for it.
12. Change the excerpt length
WordPress defaults to a 55-word excerpt, which often cuts off mid-thought in a way that looks awkward on archive pages. Adjust it with:
function custom_excerpt_length($length) {
return 30;
}
add_filter('excerpt_length', 'custom_excerpt_length');
Swap 30 for whatever length actually fits your theme’s archive layout. Pair it with a custom excerpt-more string if the default “[…]” ending looks out of place against your site’s design.
13. Automatically link Twitter usernames in content
If your posts mention Twitter or X handles regularly, converting plain @username mentions into clickable links saves manually wrapping each one in an anchor tag:
function auto_link_twitter_username($content) {
$pattern = '/(^|\s)@(\w+)/';
$replacement = '$1@$2';
return preg_replace($pattern, $replacement, $content);
}
add_filter('the_content', 'auto_link_twitter_username');
This runs on every post’s content automatically once added, so an @mention typed anywhere in the post body becomes a working link without any manual formatting or extra plugin dependency. Test it on a post with a few mentions first to confirm the regex isn’t catching anything unintended, like an email-style string that happens to include an @ symbol.
14. Add a custom image size
WordPress ships with a handful of default image sizes, but a theme with a specific layout, a wide featured image band, a square thumbnail grid, often needs a size WordPress doesn’t generate by default:
function custom_image_sizes() {
add_image_size('custom-banner', 1200, 400, true);
}
add_action('after_setup_theme', 'custom_image_sizes');
The true at the end forces a hard crop to those exact dimensions rather than scaling proportionally. New image sizes only apply to images uploaded after the snippet is added, so run the Regenerate Thumbnails plugin afterward if you need the new size available for images already in your media library. Once registered, the custom size becomes selectable in the block editor’s image size dropdown, right alongside the built-in thumbnail, medium, and large options.
Troubleshooting a snippet that isn’t working
The most common failure mode is placement: a snippet added to the wrong file, or added after the hook it needs has already fired, simply does nothing rather than throwing a visible error. Double-check that action and filter hooks match what the snippet expects, and that the function name doesn’t collide with something else already defined in your theme or an active plugin, since two functions sharing the same name will trigger a fatal error the moment both try to load.
A white screen after adding a snippet almost always means a PHP syntax error, a missing semicolon or an unmatched brace being the usual culprits. If that happens, access the site via FTP or your hosting file manager, undo the change in functions.php, and the site comes back immediately. This is exactly why testing changes in a staging environment, or at minimum keeping a backup of the unmodified file, matters more than it seems like it should until the day it saves you from a locked-out site. It’s a five-minute precaution that turns a potential emergency into a two-minute rollback.
A few ground rules before you start pasting code
Snippets are powerful precisely because they run with the same access as the rest of your theme, which means a typo can break a page just as easily as a working snippet can fix one. Back up your site, or at minimum the file you’re editing, before making a change. Test in a staging environment when one is available, and never edit a parent theme’s functions.php directly, since a theme update will silently wipe out anything added there.
A child theme, or a snippet-management plugin like WPCode, solves that update problem cleanly. Either keeps your customizations separate from the theme files an update might overwrite, so a routine update doesn’t quietly undo weeks of small fixes you’ve long since forgotten you made.
functions.php versus a snippets plugin
There’s a real tradeoff between pasting these directly into a child theme’s functions.php and managing them through a plugin like WPCode. Editing functions.php directly means zero extra plugin overhead, but every snippet lives in one growing file with no individual on/off toggle, and a syntax error in one snippet can take down the whole file, and with it, potentially the whole site.
A snippets manager plugin wraps each piece of code individually, with its own toggle and, in most cases, some basic error handling that stops a broken snippet from crashing the entire site the way a raw PHP error in functions.php can. That safety net costs a small amount of overhead per page load, generally negligible, but it’s the more forgiving option for anyone less than fully comfortable reading PHP error messages under pressure.
A reasonable middle ground: use a child theme’s functions.php for snippets you’re confident in and rarely touch, and a snippets plugin for anything you’re still testing or expect to toggle on and off. That split keeps the permanent, stable customizations in version control alongside the theme while leaving room to experiment safely with newer additions.
Common questions
Will these snippets work with any WordPress theme?
Most will, since they hook into core WordPress actions and filters rather than anything theme-specific. The footer credit removal snippet is the exception, since it targets a function name specific to one theme, and needs adjusting to match whatever theme is actually active.
Do these snippets still work with the block editor and full site editing themes?
Yes. These hooks operate at the PHP level, beneath whatever editor or theme system sits on top, so they function the same whether the site runs a classic theme or a full site editing block theme.
Is it safe to add all of these at once?
Technically yes, but adding them one at a time and confirming the site still works after each addition makes troubleshooting far easier if something does go wrong. Bundling ten changes into one edit means a single mistake could be hiding anywhere in that block.
Do snippets slow down a site the way too many plugins can?
Generally no, if anything they’re lighter than an equivalent plugin, since a snippet runs exactly the code you wrote with none of a full plugin’s setup screens, database tables, or unrelated features loading in the background. A snippet doing one focused job is close to the leanest way to add that functionality to WordPress.
What’s the risk of copying a snippet from a random blog post without understanding it?
Read through any snippet before pasting it into a live site, this one included. Malicious code disguised as a helpful snippet is a real, if uncommon, risk, and even well-intentioned code can behave unexpectedly if it conflicts with something already running on your site. A quick read of what each function actually does takes a minute and avoids a much longer cleanup later.
Final thoughts
These snippets can make a WordPress site faster, more secure, and easier to manage without adding another plugin to the stack. Instead of reaching for a plugin every time a small customization comes up, a handful of these in a child theme or a snippets manager keeps the site lighter and easier to reason about later. Always back up before touching functions.php, and test each addition on its own before stacking several changes at once, so a problem is easy to trace back to its source rather than buried somewhere in a batch of ten simultaneous edits.
One final note: none of these snippets are exotic or hard to find elsewhere, the value here is having fourteen genuinely useful ones vetted and explained in one place instead of scattered across a dozen forum threads with varying quality.
Interesting Reads:
Best Quiz Plugins For WordPress