List of discouraged or problematic WordPress plugins, themes, and functionality Print

The following is a list of themes and plugins for WordPress for which we actively discourage either their use as a whole, or a particular function of the plugin, on our hosting. The reason will be described after the name of the plugin or theme, and typically ranges from unnecessarily running dynamic code (requiring a PHP process when it shouldn't be necessary), to regularly gets hacked. These issues can amount to incompatibility with our hosting. For any of these which are listed due to performance problems, if you require that functionality, an alternative solution is to move to a VPS where your site will get the resources it requires to run the intensive functionality described. 

If we have blocked a plugin, or more likely a particular action of a plugin, visitors will receive a 403 "Forbidden" (via ModSec) or 405 "Method Not Allowed" or 406 "Not Acceptable" (via nginx rule) error when that action occurs and you will see this in the logs.

Discouraged Themes, Plugins, Configurations:

Plugin or Plugin Configuration:

• WP Reset: this plugin duplicates your tables within your database to create its snapshots. This forces your database size to double for every snapshot you create to the point where the database server needs to constantly load the database into and out of system memory, causing slow-downs server-wide. If you care about performance, do not use this plugin. It is banned on our shared servers.
• Google Analytics by ShareThis [link]: On nearly every page load it uses a dynamic call to /?ga_action=googleanalytics_get_script which requires loading a PHP process simply to serve the Google Analytics Javascript embed. This is not necessary. No known way to disable this behaviour.
• WordFence Live Traffic & Auto-Scanning: WordFence is a decent security plugin as a whole but has, over the years, added features that will slow down your website and our servers. Setting the configuration for Live Traffic to "Security Only" and disabling automatic scans will improve the performance of your website. We provide weekly malware scans free with our shared hosting (and those with a VPS that opt for the Imunify360 security layer) within Plesk, so WordFence's scans unnecessarily eat up CPU resources. Our scans run external to your PHP processing so they don't take up a process slot.
• BackupBuddy, Updraft Plus, etc: Backup functionality is not something that's designed to be operated out of a live website environment on shared servers. Read more on our backup policies to learn how to configure your web hosting account to handle your backups for you, either at the Plesk level, or on a per-app level.
• Revolution Slider: While we don't actively block this plugin as it is very commonly used, it has had a large quantity of vulnerabilities over the years and is strongly discouraged. There are many other slider plugins like LayerSlider that you may use instead. Our preferred WordPress page builder, Beaver Builder, includes sliders that have no known vulnerabilities and haven't in the years we've been using them.
• Cookie Notice: This plugin is fine as long as you do not enable the "Reloading" option (Enable to reload the page after the notice is accepted) found in the plugin's settings (Settings > Cookie Notice in WP). This is because it forces an entire page reload for every single visitor to the site and the reload has a query parameter, requiring every page load to occur non-cached.
• GeoIP Detection: This plugin is fine as long as you do not enable the option called: "Disable caching a page that contains a shortcode or API call to geo-dependent functions." as this will likely disable all caching on the site which is bad for performance. We only allow that option be enabled if you have a VPS.
• Elementor Pro WooCommerce Mini Cart: Be sure that the option under Settings > Integration > WooCommerce > Mini Cart is set to Disabled, otherwise frequent website visits will result in heavily degraded performance as dynamic processes are launched to request cart contents on every single page load.
• Elementor Improved CSS Rendering Feature: The feature found at Elementor > Settings > Features (tab) > "Improved CSS Loading" will cause a 'race condition' with caching plugins resulting in intermittent display issues. If you're already using a caching plugin (and in particular one that optimizes CSS automatically), disable this feature in Elementor.
• Popup Builder: As of March 2020, this plugin has been found to have multiple vulnerabilities due to poor coding practices and is therefore discouraged for this reason. From a poor performance perspective, this plugin uses dynamic AJAX calls to WordPress on every single page view in order to track views. This degrades performance on busy websites, and so we've blocked solely these counter requests at the ModSecurity level. Other than view counts not increasing in the plugin admin, you will see no adverse effects as a result of this, and if you were to migrate to a VPS of your own, this rule can be removed upon request.
• WP-Discuz: This plugin's tooltips and documentation indicates that the "Comment Thread Displaying" section's "Comment List Loading Type" setting will give you better performance if it's set to AJAX loading, however this is incorrect. It is considerably better for performance to use either of the other two options: "Load with Page" or "Display [view comments] button".
• WordPress Popular Posts: On high traffic sites the following configuration *must* be set to ensure high performance, as seen with the following configuration values. Note that if you do not set these values and you have sufficient traffic, you will require a VPS with significant resources for it to function.
  • Log Limit: Keep data for 180 days or less
  • Ajaxify Widget: Disabled
  • Data Caching: Enabled
  • Refresh Cache every: 60 minutes or less frequent. Optimally 3+ hours
  • Data Sampling: Enabled
• WooCommerce Free Shipping Bar (by VillaThemes): When enabled on some sites this plugin doubled all dynamic processing time and dramatically slowed down the site it was installed upon (t-reb). It's strongly recommended to not use this plugin at this time. Last tested on version 1.1.4.1 Premium.
• MediaVine Trellis: This plugin creates CSS that is not in a file and is only dynamically loaded at the URI /sw. Each request requires PHP processing to complete. We have found no way to turn that off, so it must be blocked via .htaccess or nginx rules.
• W3 Total Cache Minification: Despite this plugin being focused on performance, for some reason they use dynamic URLs for their minified content rather than simply outputting the minified files to disk and allowing the web server engine to serve them directly. This creates two problems: (1) it affects performance, and (2) our performance optimized 404 detection system is incompatible with their rewrites. Because we can't condone the use of dynamic processing for static resources, we strongly recommend disabling minification in W3TC and instead use Autoptimize for this functionality. That said there is a workaround for problem (2): Under Performance > Minify you must uncheck the option to "Rewrite URL structure." This will still use dynamic processing for static resources (again, not recommended), but at least the static resources will load without a 404.
• Gravity Forms version 2.5.5.x: this version of Gravity Forms can slow down your WordPress admin by anywhere from 5x to 20x. There appears to be a spinlock situation created by the code with CPU at 100% for 5-30 seconds at a time on each request, however we have not found the specific cause for this. Deactivating the plugin or upgrading to version 2.5.7.5 or newer will fix this. The updated version causes only negligible slowdown (approximately 20% slower than without it). You may wish to switch to an alternate form plugin to avoid even that 20% performance hit.
• WP Statistics: there's nothing inherently wrong with this plugin in that it *needs* to make numerous dynamic PHP calls in order to handle traffic stats counting. However these numerous calls can exhaust resources and database queries available on shared hosting, and be detrimental to performance. If you wish to avoid these dynamic calls you will need to use a stats system that records the data externally, like Google Analytics.
• PixelYourSite: if the option "Use Ajax when conversion API is enabled" is checked for any type of pixel (but known to be for Facebook Pixels in particular), this will generate a dynamic PHP request to admin-ajax.php for every single page load of your site and under medium to heavy traffic this will result in outages for your site. The solution is to disable this option (which may make your tracking numbers inaccurate; this is unconfirmed). Tip: the JavaScript provided to install tracking pixels on your website, such as the Facebook Pixel tracking code that is provided by Facebook, does not have this same problem as the PixelYourSite plugin does because it generates dynamic processing on Facebook's servers rather than your website's server. Switching to the code provided directly by the company whose tracking pixel you are installing will ensure better performance.
• WooCommerce Product Filters (WOOF) + Docket Cache: When completing searches on the front-end with WooCommerce Product Filters, if you also have Docket Cache's Object Cache enabled, CPU usage spikes with every search. To fix this, go to Docket Cache's Overview tab, and on the right side Disable the Object Cache Drop-In
• WooCommerce Product Filters (WOOF) Dynamic Recount + Text Search Module: If, under the plugin's settings, you have both Text Search (Or Husky Search) enabled as well as the option called "Dynamic recount" (TIP: Enabling "Hide empty terms" will automatically enabled Dynamic recount"), this will cause text searches to take 2-3x longer to respond than without Dynamic Recount. This may be less problematic if you have very few taxonomy filters or few terms in those taxonomies. Example: on a site with thousands of taxonomy terms and products, this took searches from 2-4s to anywhere from 12s - 30s.
• Myworks QuickBooks Sync: this plugin loads resources on every single page of your site on both front-end and back-end even though it doesn't need to; it really should only need to hook into the final order page of the checkout process. On one site we found this plugin alone attributed for up to 4s of extraneous PHP wait/processing time for all admin pages and uncached front-end pages. 
  Quickbooks Sync Workaround: Go to "Settings" in MyWorks Sync, then go to "Miscellaneous". Activate the "Queue Sync" feature. Save your settings. It will now only sync data with QBO when your WP Cron runs, which is a background task. This means it no longer takes up active processing on every page load, making the front and back end of your site faster. 
• ActiveCampaign for WooCommerce: We've encountered numerous bugs with this plugin that have solutions in their support forum, but which the devs have refused (after months) to implement. In some cases the bugs have been serious compatibility issues, in others they've resulted in logging to the database that created table sizes of multiple GB, resulting in performance issues on the site. Their support forum is riddled with unanswered requests for help and when you submit a support request to them, they do not reply. This plugin may well not only break parts of your site but also slow it down. A possible alternative that we have yet to test: https://activewoo.com/
• WooCommerce "Enable Tracking" Option: Disable it. This is a built in function of WooCommerce that loads an additional Javascript file and in some cases can result in as much as 700ms or more tacked on to each WooCommerce page on your website's loading time. This appears to occur because of the time it takes to send statistical data about your store to Woo devs. The option is found under WooCommerce > Settings > Advanced > WooCommerce.com > Usage Tracking
• Divi Builder Plugin: The Divi builder plugin limits all of WordPress to 256M memory for unknown reasons. When Divi Builder is disabled we find sites considerably faster and no longer exhibiting errors that could be a result of breaching that artificial 256M memory limit. We don't have a workaround for this - the only solution is to disable Divi Builder.
• Loginizer Plugin: slows all uncached page loading down by 3-4 seconds on average. Get rid of it!
• WP101 Video Tutorials plugin: found to be very slow Dec 2024. Deactivating it improved performance by ~2s per page load

Theme or Theme Configuration:

• [Any Theme] WooCommerce Cart Items in Header/Footer: If your theme has an option to include your WooCommerce cart on all pages and you have a lot of traffic to your site, disable that option immediately. Using that option ensures that every single page load will create a dynamic request to query the contents of the cart. This works without any problem on sites with less traffic, but sites with significant traffic will begin to see dramatic slow-downs from this option being enabled. (Note: very high traffic eCommerce sites should probably be hosted on a VPS, which negates the need to disable this functionality as you will have the dedicated resources to provide it). If your theme does not have the option to disable it, a nearly as effective workaround is to add this to your theme's functions.php or using the Snippets plugin: wp_dequeue_script('wc-cart-fragments');
• [Any Theme] Custom 404 Page: Many themes (including Astra and Genesis) utilize a 404.php file that, for some stupid reason loads the entirety of site design simply to show custom 404 page content. If the page header or theme framework is particularly heavy, this means that every single time a 404 is encountered, heavy content is dynamically rendered and a PHP process is needed, taking up much CPU resources. To resolve this, copy the 404.php file to your child theme and enter the following on the very first line. This will ensure the PHP process that handles this is super lightweight: <?php http_response_code(404); die('404 Not Found'); //required for performance ?>
• [Genesis Theme] Custom CSS: Defaults to using dynamically generated CSS via URL, making requests for it look like this: GET /?custom-css=57f2db73cc
  Each of these requests requires a PHP process rather than simply loading from disk. The best solution for this is to not use Genesis's Custom CSS function in the WordPress customizer and only use the child theme's stylesheet. The next best solution is to instruct your caching plugin to always cache the request parameter "custom-css". This will still launch a PHP process, but it'll be much more lightweight.
• [Salient Theme] Custom CSS: With its default configuration, this theme conflicts with caching plugins by constantly forcing refreshes of minified files. To avoid this problem in the Salient theme settings, go to General Settings > CSS/Script Related and enable the option to "Move Dynamic/Custom CSS Into External Stylesheet".

Admin Notes

• modsec blocks are only in global server config in Plesk
• nginx blocks are typically per-domain and applied via "apache and nginx settings" in Plesk. They look like the following:

if ( $args ~ "service=git-upload-pack" ) { return 406; }

if ( $uri = "/sw" ) { return 406; }