Create a site-specific WordPress plugin when a site needs custom functionality that should stay separate from WordPress core and continue working if the theme changes. For a simple feature, start with a folder and PHP file in wp-content/plugins, add a valid plugin header, and register the behavior with a WordPress hook. Use a regular plugin unless the code must load automatically and should not be switchable from the standard Plugins screen.
Why put custom site functionality in a plugin?
Keep custom code out of WordPress core
WordPress advises developers not to edit core files: updates can overwrite those changes. Its Plugin Developer Handbook introduction recommends adding or modifying functionality through plugins instead. A plugin gives site-specific behavior its own place without changing the files WordPress updates.
Keep functionality independent of the theme
Use a plugin for behavior that should remain available when the site changes themes. The Theme Developer Handbook recommends putting features that should work regardless of design in a plugin. Code in a theme’s functions.php is tied to that theme; WordPress loads the active theme’s file, with a child theme able to add its own functions as well.
Conversely, code that exists only to control a particular theme’s presentation belongs with that theme. Separating the two avoids losing site functionality as a side effect of a design change.
#1 Best Overall
Give one-site code a maintainable home
A plugin does not have to be intended for public distribution. WordPress recognizes plugins that serve just one site as well as those shared with the community. A small feature may fit in a single PHP file; as it grows, its code can be organized into additional files.
How to create a minimal regular plugin
Build and check the plugin on a development copy before deploying it to a live site. For the folder, file, header, and activation steps, see the official Plugin Basics guide.
- Create a uniquely named folder. Under
wp-content/plugins, make a directory with a clear slug, such asitechs-guides-site-tools. Choose a name that will not be confused with another plugin. - Add a PHP file. Put a file in that directory, ideally with a name that matches the plugin slug, such as
itechs-guides-site-tools.php. - Add a plugin header. At minimum, the specially formatted PHP comment must include the plugin name. You can also include metadata such as author, version, and license. Only one file in the plugin folder should contain the header.
- Check the Plugins screen and activate. Save the file, open the WordPress admin Plugins screen, confirm the plugin appears, and activate it as you would any regular plugin.
- Add the smallest needed feature using a hook. Register a callback with the relevant WordPress hook instead of changing a core file. For example, if a site needs a small piece of behavior at a particular point in WordPress’s execution, identify the appropriate hook and write a callback for it. The exact hook and implementation depend on the feature.
- Test, then deploy. Check the feature and its failure cases in development, review applicable security and privacy guidance, and deploy through the site’s normal change process.
The minimal plugin structure consists of a directory, one PHP file, and a valid header. It does not require activation, deactivation, or uninstall routines unless the feature needs those lifecycle tasks.
How hooks connect plugin code to WordPress
A hook is a predefined point where code can interact with WordPress, a theme, or another plugin. The function registered to it is called a callback. WordPress’s Hooks guide explains the key distinction:
- Use an action when the callback should do something at a particular point in execution. An action callback performs a task; it does not return a value to the action hook.
- Use a filter when the callback should change data. A filter receives a value, modifies it, and returns the result so it can be used later.
Choose the hook based on what the feature needs to do. A filter that changes a value must return the resulting value; an action is for performing a task at the designated point. The appropriate hook is specific to the behavior you are adding.
Regular plugin or must-use plugin?
A regular plugin is the default for most site-specific features. A must-use plugin (often called an mu-plugin) fits code intended to load automatically and not be accidentally disabled in the standard Plugins screen. Their differences affect how administrators manage and maintain the code:
Rank #4
| Consideration | Regular plugin | Must-use plugin |
|---|---|---|
| Loading and control | An administrator can activate or deactivate it through wp-admin. | Loads automatically and cannot be disabled from the default Plugins list; remove its file to disable it. |
| Lifecycle hooks | Supports activation, deactivation, and uninstall hooks when needed. | Activation hooks do not run. |
| Admin update notices | Can use the normal plugin update-notification process. | Does not provide normal plugin update notifications. |
| File placement | Place it in a directory under wp-content/plugins. |
By default, place it under wp-content/mu-plugins. WordPress automatically looks only for PHP files directly inside this directory; code in a subdirectory needs a direct PHP loader file. |
| Best fit | Features an administrator may need to switch off, or that need the regular plugin lifecycle. | Small bootstrap or site-wide maintenance code that must always load and is deliberately managed outside the usual plugin controls. |
These mu-plugin details are documented in WordPress’s Must-Use Plugins guide. Automatic loading is a trade-off, not a general improvement over regular plugins: the maintainer must handle updates and testing, and should document why the code exists, who owns it, and how it is updated. Keep always-loaded code small and reviewed. If the feature should be manageable in wp-admin or needs normal activation behavior, use a regular plugin.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When to add lifecycle routines and security checks
Add lifecycle behavior only when the feature needs it. Activation can establish setup such as default options; deactivation may clear temporary data; uninstall is for cleanup when the plugin is deleted. Decide deliberately what data to remove, so uninstalling a feature does not unexpectedly erase information a site owner wants to keep.
Before deploying a feature, consult the relevant Plugin Developer Handbook guidance on security, input validation, capabilities, nonces, output escaping, sanitization, privacy, and testing. The right implementation depends on what the feature accepts, changes, and displays; a minimal plugin skeleton alone does not make those decisions safe.
Quick Recap
Choose where the code belongs
- Use a regular plugin for site functionality that should survive a theme change and remain manageable through wp-admin.
- Use a must-use plugin only when automatic loading and resistance to accidental deactivation are intentional, and someone will maintain it outside the normal plugin lifecycle.
- Use theme code for behavior that is genuinely part of that theme’s presentation and should not persist as a site feature after a theme change.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
