Discussion on Deactivate Plugins Per Page - Improve WordPress Performance


nikolaydev supports this item


This author's response time can be up to 1 business day.

27 comments found.

This plugin is amazing, thank you so much.

The only important feature that seems to be missing is the ability to select the backend only for custom urls.

For example: “deactivate on all backend pages where url doesn’t contain”


Thank you too. I will have to add an option to choose per rule separately if it affects back-end or front-end or both. I am writing this down in my file with new features to add. But I cannot say when it will be done. I will write a comment here when it is though.


When this plugin is network activated on multisite, can we control all the blogs at once?

We should fix this too. Unexpected response should never happen. So after which action it happens exactly? After saving the plugin settings? Or after adding a rule?

After adding a rule.

OK, I sent you a version that will show the response so we can see it. Please screenshot it and send me to see. Regards.

On the latest WP update 5.3.2 this plugin started messing up with my plugins and deactivated them randomly. It isn’t working now, which is a bummer because it had been working great all year.

I wouldn’t recommend it for newer installs.


Sorry to hear that. But that is very unlikely, since the 5.3.2 update is very minor, and also looking at the changes I don’t see how any of them could affect my plugin. Maybe something else is going on, and just happened after you updated. Please confirm that the 5.3.2 is the problem by going back to 5.3.1. You can download it, extract it, and upload all files and folders except the “wp-content” folder to your server. This will downgrade you to 5.3.1. Of course make a backup first just in case. Check if that solves the problem (just so we know, I am not suggesting to stay with that version).

Also I am not sure exactly what is being deactivated and when. I don’t think it is random though. It is best to test with just one other plugin activated, and just one deactivation rule first. So it is a simple environment, where you can easily see what is going on. Use the debug mode in my plugin to see on the front-end which plugin is active.

Sometimes when you deactivate a plugin, that is needed by other plugins, they get deactivated as well, because they cannot work without it. These plugins that work together you need to put in a group and add rules only to the group, so they are deactivated together. For example all WooCommerce add-ons require WooCommerce.

If you prefer, send me ( access to your site to do some testing, but also tell me in more detail how to first see the problem on your site (what happens and when that is the problem).


Is there a way to deactivate on all except more than one URI which “does not contain”? Whenever I select 2 all but uri “which does not contain”, the deactivation stops working everywhere.

What I’m trying to do is prevent it from running on the frontend at all, but I have two different admin dashboard urls. (“wp-admin” and “dashboard”)

I don’t want anything deactivated on the frontend. I want everything deactivated on the backend only except for certain pages on the backend.

I use deactivate on all except for “uri does not contain wp-admin” and it works, but adding another rule “uri does not contain dashboard” along with the first rule causes the rules to not take effect.

Ah, I think I understand now. I Thought you wanted to prevent the plugin from running on the front-end, but you want the rules to not run on the front-end. And you have two different dashboard strings to consider. Yes, this seems impossible then in the current plugin. Let me think a little about what feature I need to add for that to be possible.

I sent you an email (I have it from before) with a way to do that before I release the update that has the feature. Regards.

Hello, is there any chance to create something like that. When you have the debugger enable except for what active plugins are to show the amount of time the plugin took to load when you visit a page?

For example you go to home page and the debugger shows Contact Form enabled and next to it (0.3sec to load) something like that and make it optional to enable or disable just like debugger.

Thank you.

Hi. That sounds very cool, but I don’t think it is possible. Plugins hook into many different points in the loading process and add their PHP code, also do MySQL queries, also add static files to be loaded, all these things add to the loading time. It is not one action that happens all at once and loads the plugin that we can measure. It is too complicated, sorry.


Alumnay Purchased


Your plugin doesn’t seem to be working for custom post types such as blog articles, products from woocommerce and more.

Or am i missing something?

Hi. I assume you want to make a rule that targets all of that custom post type (or do you mean something else?) You can target products with a custom URI selection rule that affects all URI that contain /product/ for example. You wouldn’t be able to do that only for a post type that does not contain a unique word in the URI, which also depends on the permalink settings (usually normal posts if they only contain the post name). Give me an example of what are you trying to do exactly and how does your URI look like.


Alumnay Purchased


Yes I wanted to make a rule that target custom post types.

For example: I am using woocommerce and my urls are customized (there is no /shop/ or /product/) prepending the URL of the product. Thus I need a to deactivate plugins like elementor, contact form 7 and more for “products and post custom post types”. Now its currently not possible with your plugin.

Something like this but also include products—>

My plugin works with the URI, if there is no change in the URI, you cannot target these posts. The reason for this is because in order to deactivate other plugins my plugin needs to work before they even begin to load. That early in the load process WordPress does not allow me to detect post types and other types of pages in the normal way. Also some post types don’t even exist yet, since plugins create them later.

So in order to be able to detect post types the plugin would have create a database table with all posts and their URIs and constantly update it on changes, and always check in that table which URI is for which post type. And this is a complicated and not so good way of doing it. Basically there is no good way of doing that, because of how the WordPress load process works. I may end up do it eventually in this not so good way, but for now I haven’t decided to do this feature.

This is an amazing plugin! I use it all the time. And Nikolay’s support is awesome!