Documentation: how to deactivate plugins on specific pages
Getting started
The aim of FDP is to give you the possibility to load plugins only where you need them.
You can deactivate the plugins depending on:
- The single post (blog post, page, or every queryable custom post type) => Singles settings
- The post type => Post Types settings.
- The archive => Archives settings.
- The term archive => Term Archives settings.
- The device => Device settings.
- Search results page => Search settings.
- Cron jobs => Cron Jobs settingss
- The URL => Custom URLs settings
- The page in the backend => Backend and Backend URLs settings
- The actions that run in the background (Ajax actions) => Actions settings
- The user (only PRO version) => Users settings.
Suggested workflow
FDP will unload the plugins based on the settings listed before (Singles, Post Types…).
The settings Singles, Post Types, and Custom URLs may overlap.
When a certain page loads on the frontend, FDP will first check the Custom URLs settings. If the URL of the page matches a custom URL, FDP will not check the Singles and Post Types settings.
If the URL doesn’t match any custom URL, it will check the settings of Singles or Post Types.
It seems this is the hardest part of the process for most first-time users of FDP, so pay attention.
When you deactivate plugins in the Post Types settings, you are asking to deactivate those plugins by post type. If for example, you deactivate some plugins on the post type “Pages”, every time a static page loads, FDP should deactivate the plugins that you deactivated for the post type “Pages”.
And this is what it always does if you didn’t ask anything different in the Singles settings for that specific page.
You can override the Post Types settings with the Singles settings for some specific pages that need a different set of plugins.
Let’s do an example to clarify how it works. Let’s imagine this scenario:
- You deactivate some plugins in the Post Types settings for the post types “Pages”.
- You deactivate different plugins in the Singles settings for the page “Contact Us”. For example, you may deactivate the same plugins as in the Post Types settings, but the plugin for the contact form is active.
In this case, when you load a static page on the frontend, FDP will deactivate the plugins according to the Post Types settings, but if the page is “Contact Us” it will do it according to the Singles settings taking the list of plugins from the row related to “Contact Us”.
It’s important that in the Singles settings the row related to “Contact Us” is active (switch on), in another case the priority is given to the Post Types settings.
We suggest first deactivating the plugins in the Singles settings taking into account all the pages that need a different set of plugins. Then, use the Post Types settings for all the remaining pages.
Overview of the options to selectively deactivate plugins.
Here you have an overview of the options to selectively deactivate plugins. Click on each tab to learn more about the related settings page.
On the Singles section you can decide the plugins you want to deactivate on each post (blog post, page, or every queryable custom post type).
Under the Singles menu item, you have a submenu including all the post types registered on your website that are publicly queryable.
On the page “1:1 VIP Day” we will load only Freesoul Builder, Freesoul Custom, and NextGEN Gallery., no other plugin.
Because the row is active, the Singles settings will override the Post Types settings
The idea is to use the Post Types settings for most of the pages and the Singles settings only for a few pages that need different plugins.
In the Post Types section you can decide which plugins activate depending on the post type.
According to the settings shown above, in this case, we are asking to Freesoul Deactivate Plugins:
- On each page and blog post load only Basic Security, Freesoul Builder, and Freesoul Custom, no other plugin.
- For each lesson load Basic Security, Freesoul Builder, and LIfter LMS, nothing else
- And so on…
Then we will use the SIngles settings if we want a different set of active plugins on some specific pages.
When you load an archive page, Freesoul Deactivate Plugins will disable plugins according with the Archives settings.
In this example, every time you load a Portfolios archive page, Freesoul Deactivate Plugins will keep active Freesoul Builder and disable all other plugins.
On the Episodes Archive page, Freesoul Deactivate Plugins will keep active only Freesoul Builder and Freesoul Podcasts and disable all other plugins.
On Course Archive pages if we keep only Freesoul Builder and Buddypress as shown in the picture, that page will not work, because that archive is created by the plugin Lifterlms.
Be careful when you disable your plugins, with wrong settings you may disable important plugins. Freesoul Deactivate Plugins is a tool, the result of this tool depends on how you use it.
The PRO users have the auto-suggestion of the unused plugins, but if you have the free version you need to know which plugin you can disable without having problems.
When you load a Terms Archive page, Freesol Deactivate Plugins will disable plugins according to the Terms Archives settings.
In this example shown in the picture, we keep active only Freesoul Builder on the blog post category archive pages.
In the navigation, you have a link to the term archive settings for each term.
Freesoul Deactivate Plugins gives you the possibility to disable specific plugins when the page is loaded by a mobile or desktop device (desktop only for PRO users).
In the example above the plugin Change Class In Viewport will not run when the site is visited by a mobile device.
The other plugins will be managed by the other settings.
Freesoul Deactivate Plugins considers tablets and mobile phones both as mobile devices.
Be very careful when you use those options, you risk two issues:
- You have a caching plugin that doesn’t distinguish between mobile and desktop. When the first user visits the page with a mobile device, the page is saved in the server cache. Then other users visit the same page with a desktop, but they see the mobile version.
- You disable plugins on the mobile version, but you see ugly orphan shortcodes. If e.g. you disable Revolution Slider on mobile you will see something that looks like [revslider alias=”example-alias”] instead of the original slider.
To avoid the first issue you should use a caching plugin that distinguishes between mobile and desktop, as e.g. W3 Total Cache or WP Fastest Cache (the free version of WP Fastest Cache distinguishes between desktop and mobile, but it doesn’t save the mobile cache, the premium version does it).
To avoid the second issue, you can install Specific Content For Mobile, then you will see the mobile versions in the Single Settings and disable specific mobile versions and not only for all mobile devices. And you will be able to customize the mobile versions, removing the content that would generate the orphan shortcodes.
Another way to solve the second issue is writing custom code in functions.php of your child theme or in a functional plugin, Remember that if you need to create a functional plugin you can do it in Freesoul Deactivate Plugins => Tools => Create Custom Plugin. Read here for more details.
You can use the constant “EOS_{PLUGIN-SLUG}_ACTIVE” to check if a plugin is globally active but disabled only on mobile devices.
Replace {PLUGIN-SLUG} with the slug of the plugin you want to check. The slug is the name of the plugin main folder but with all capital letters.
Let’s suppose you disable REVSLIDER on mobile
In this case, you can write this code:
if( wp_is_mobile() ){ if( defined( 'EOS_REVSLIDER_ACTIVE' ) && EOS_REVSLIDER_ACTIVE ){ //Whatever you need to fire add_shortcode( 'rev_slider','__return_false' ); //e.g if you need to remove orphan shortcodes on mobile } }
We are saying: if it’s a mobile and Revolution Slider is globally active but disabled on mobile, then return nothing as the output of the shortcode “rev_slider”.
Of course, we need to know the name of the shortcode.
The constant that in this example is EOS_REVSLIDER_ACTIVE will be suggested in the mobile settings page.
In the Search Settings section you can decide the plugins you want to keep active when the Search Results Page is shown.
In the example above we keep active only Freesoul Builder and Buddypress on the search results pages.
It’s up to you to understand what plugins you need on the search results page. This will depend on the theme you are using. Usually, this page shows only the posts excerpts.
With the custom URL Settings you can disable plugins based on the page URL.
Use the star “*” as replacement of groups of characters.
E.g. http://localhost/freesoul_development*example/ will fetch URLs as http://localhost/freesoul_development/an-example/, http://localhost/freesoul_development/another-example/…
You can use these options to disable plugins by URL query arguments. E.g. *?example-paramameter=true* will fetch URLS as http://localhost/freesoul_development?example-paramameter=true, http://localhost/freesoul_development/page-example/?example-paramameter=true…
Under the menu item Backend you will find the links to the settings pages:
- Backend Singles
- Backend URLs
Disable plugins in the backend.
Backend Singles gives you the possibility to disable the plugins that you don’t need on some backend pages.
Click on the plus icon to click the actions panel. Clicking the icon that is highlighted in the picture FDP will suggest to you all the plugins that are not used on that page. The auto-suggestion of unused plugins in the backend s available also in the free version.
For PRO users it will be possible to have an automatic suggestion for all the backend pages without the need to click every time on the icon for each page.
Before saving click on the lens icon to see the preview of the page. If it’s all ok, save the changes.
Disabling unused plugins on the backend pages can make a big difference in terms of performance for the backend, but of course, where you disable a specific plugin, WordPress will not be able to add the admin menu items introduced by that plugin.
Freesoul Deactivate Plugins can build the entire admin menu and print it also on the pages where not all the plugins are active, without missing any admin menu item.
You can choose between showing the rebuilt menu in the admin top bar or via JavaScript after the backend page is fully loaded. This last feature is still in the beta version, but you can already try it.
Watch the following video to see how you can optimize the backend with FDP.
Disable plugins in the Backend with Custom URLs.
In the Backend URLs settings page, you can disable the unused plugins for all the backend pages that match the custom URLs that you set.
Use the star “*” as a replacement for groups of characters.
E.g. https://your-domain.com/wp-admin*example/ will match URLs as https://your-domain.com/wp-admin/an-example/, https://your-domain.com/wp-admin/another-example/…
You can use these options to disable plugins by URL query arguments. E.g. *?example-paramameter=true* will match URLs as https://your-domain.com/wp-admin?example-paramameter=true, https://your-domain.com/wp-admin/page-example/?example-paramameter=true…
Disable plugins in the Backend Everywhere (PRO)
On the Backend Everywhere settings page, you can disable the unused plugins for all the backend pages. The plugins that you disable here will not run in the backend.
If you have some plugins that should never run in the backend, use this option.
Under Freesoul Deactivate Plugins => Actions, you will find the settings pages where you can disable specific plugins during specific ajax actions.
You will find only the actions of some popular plugins.
In the picture, you see the actions managed by WooCommerce.
In this example, we disable all plugins during the actions managed by WooCommerce, but we keep Freesoul Custom during the checkout ajax request.
If you are a developer you can add to the available settings any action managed by any plugin. Read here to learn how to do it.
You can even create an add-on to integrate Freesoul Deactivate Plugins with a third plugin to optimize the performance of the Ajax actions of that plugin.
If you are a PRO user you will be able to disable plugins on whatever Ajax action without the need to write any code.
The PRO version provides a recorder that you can use to register whatever Ajax action.
You will find it in Freesoul Deactivate Plugins => Actions => Custom Actions.
To add a new action:
- Type an action name in the input field
- Start the recording
- Do the action (e.g. a form submission, or theme options saving…)
- Stop the recording.
- Disable the plugins you don’t need for that action.
In this example we keep only Freesoul Builder during the form submission, we need nothing else.
In Freesoul Deactivate Plugins => Users, you will be able to disable specific plugins depending on the user who is logged-in.
This feature is available only for PRO users.
To add a set of conditions to match specific users click on “Add row”.
On each row, you will see some action icons. Here you have a short description for each icon.
Drag row to change the priority | |
Edit conditions | |
Delete row | |
Hide plugins without really disabling them. The matched users will not see the hidden plugins anywhere in the backend, but their code will still run. |
When you edit the conditions a window as shown in the picture will pop-ups.
You can disable plugins by:
- Role
- Capability
- Username
- Language (defined in the user profile)
- Registration date
- Presence of order of the user in the shop (only WooCommerce)
You can negate any condition by clicking on the button “NOT”.
You can decide for example that for all the users who are not administrators the plugins All In One WP Migration, All In One WP Migration Unlimited Extension, All Pages In Customize, Export WIthout Shortcodes, and Rename Plugins Folder will not exist.
In other situations, you may need to don’t load a specific plugin if the user has already bought something in your shop (e.g. plugins for Ads).
You can build also complex conditions by adding and dragging rows to assign the priorities.