Short Description

With “Deactivate Plugins Per Page” you can easily disable plugins on certain WordPress pages (or on all except a selected page).
This is useful for speeding up your site mainly because many front-end plugins will load their JavaScript and CSS assets on every page, even if you use them on one page.

How it works?

You can add deactivation rules for active plugins. For example for a contact form plugin, that you only use on the contact page, simply add a rule to deactivate it on all URI except on the contact page.

Deactivation Rules Options

1. Deactivation Type
– Deactivate on selected URI
– Deactivate on all URI except selected
2. URI selection type
– Page
– Custom
3. [Page] Select pages to extract URI from (it will update automatically if the page slug changes)
3. [Custom] Custom URI condition
– URI equals …
– URI does not equal …
– URI contains …
– URI does not contain …
– URI starts with …
– URI does not start with …
– URI ends with …
– URI does not end with …
– URI matches the regular expression …

4. Affected devices
– All
– Desktop
– Mobile

Plugin Groups

Create groups of multiple plugins in order to add deactivation rules that affect them all.

Debug Mode

Enable debug mode to see what is the URI and which plugins are active/inactive on the current page on the front-end. This will help you create rules and test current ones. A debug box will appear on the front-end if you are an administrator user.

Does it affect the Back-end?

There is an option (not enabled by default) that makes all rules with Custom URI selection to also affect the back-end. Some back-end pages will still not be affected in order to avoid problems, like the pages that control plugin activation, deactivation, updates, and installation.

Export/Import Rules and Settings

Since version 1.9.0 you can export all your deactivation rules and settings of the plugin and import them on another site. Rules with Page URI selection type, will be skipped if the same pages (both same ID and slug) do not exist on the destination site. In a multisite you can import into multiple sites at once.

Custom PHP function as condition

Since version 1.15.0 you can add the name of your own PHP function to a deactivation rule so it is used as an additional condition. The rule will only work if your function also returns true. The function must be loaded in a must use plugin so it is available before regular plugins load.

Client Reviews

Precautions

Group plugins that work together
If you have a plugin that requires another plugin to be active in order to work, you need to add these plugins in a plugin group, and add deactivation rules to that group. Deactivating only one of these could lead to errors or the global deactivation of the other plugin.
Don’t deactivate plugins required by your theme
Some themes require certain plugins in order to work properly. If you deactivate these plugins you may experience problems.
Deactivation hooks will not run
When plugins are deactivated via my plugin, the actual deactivation function is not called, and the deactivation hooks will not run. Instead, to make it work per page, plugins are just dynamically removed from the list of active plugins before the page loads. This means that if a plugin has some actions that it performs when it is deactivated, these actions will not run when it is deactivated via my plugin.
For example, some plugins add code to your ”.htaccess” file when they are activated, and when they are deactivated, they remove it. In this case if you add a deactivation rule with my plugin to stop the plugin on a certain page, the ”.htaccess” code will still be there and work on that page, even though the plugin will not be active on it.
Don’t use this plugin to hide sensitive data
It is not made to work securely for that. It is mainly made for site speed optimization and it can also be used for debugging or solving plugin compatibility issues.
Backup your site
Deactivating plugins per page is not a natural thing for WordPress, and plugin and theme developers are not expecting that. It works great in most cases, but sometimes can lead to problems, to other plugins being deactivated or settings being changed. Always have a recent backup of your site and if you can, test your changes in a staging site.

Feedback / Support / Questions

Use the support section (requires sign-in), or my email nikolay@nikolaydev.com

Tested Up To

WordPress 6.3
PHP 8.2.6

Hire me to make a custom plugin for you

You need something different? Send me an email: nikolay@nikolaydev.com

Changelog

1.16.0 – 19 June 2023

ADDED: Regular expressions can now be used as a custom URI condition. This allows for more advanced URI targeting that was impossible in previous versions. For example now it is possible to make a rule that only affects URIs that contain multiple separate keywords at the same time.
ADDED: An option to ignore only chosen URI parameters for page rules, for better compatibility with plugins that add URI parameters to pages. This is now the default setting.
ADDED: An option to change the admin menu cache expiration time (only used if back-end deactivation is enabled along with admin menu cache).
IMPROVED: Moved some settings in a separate section called Advanced Settings. For most users they will not need to be changed.
IMPROVED: Set some of the plugin settings to not be auto-loaded in the memory by WordPress, to slightly reduce server memory usage.
IMPROVED: Added the “v” parameter to be a chosen URI parameter by default so it is ignored by the rules. This parameter is added by WooCommerce if geolocation is enabled, and we don’t want the rules to consider it a different page when it changes.
FIXED: Incorrect admin menu links in certain cases when the cache is enabled and a conflicting plugin is back-end deactivated.
FIXED: We show an error when invalid custom condition value is entered, instead of just removing the invalid characters.
FIXED:…