Skip to content

Plugin incompatibilities

All WordPress sites on the VIP Platform are provisioned with robust, built-in performance features such as:

Adding third-party plugins that provide additional versions of these features is not only unnecessary, but may result in negative impacts on a site’s performance.

When considering a plugin to add to a site, verify that the plugin is not adding a version of a feature already provided by the platform. In addition, before adding any plugin to a site, complete the steps to evaluate a third-party plugin and its potential compatibility with the platform.

Backup, export, and import plugins

Plugins that are intended to create SQL database and media backups, imports, and exports will not work as expected.

Tooling on the VIP Platform already exists for:

Incompatibilities with the VIP Platform infrastructure have been observed in the following plugins that perform backups, exports, and imports:

Caching plugins

The features offered by caching plugins are already built-in and handled more efficiently by the VIP Platform’s page cache. Third-party caching plugins are not designed to work with the VIP Platform’s globally distributed edge cache servers and auto-scaling server architecture.

Caching plugins can also be incompatible due to

  • Attempts to write files to a cache directory: The VIP File System is read-only.
  • Interactions with an .htaccess file: The .htaccess file only exists on Apache servers; VIP runs on NGINX.

Incompatibilities with the VIP Platform’s caching layers have been observed in the following plugins:

Image optimization plugins

Images uploaded to a site are stored on the VIP File System. The VIP File System automatically serves images that are:

Incompatibilities with the VIP File System have been observed in the following image optimization plugins:

Security plugins

Multiple security measures are supplied by VIP MU plugins for all WordPress sites, including protections for wp-login.php and xmlrpc.php.

All web servers run in read-only mode. This helps to protect applications on the platform against many common forms of attack (e.g. vulnerabilities that allow the installation of backdoor shells and other malicious files).

Incompatibilities with the VIP Platform’s security infrastructure have been observed in the following plugins:

SQL query-intensive plugins

Some plugins generate inefficient SQL queries or can trigger SQL-intensive cron tasks when they are not designed for an enterprise-scale site. Inefficient SQL queries can be compounded if a WordPress site hosts a significant volume of content, if the site is on a large multisite network, if a substantial number of users are registered, or if the application code depends on inefficient meta queries.

On the VIP Platform, cron processes are run in a separate container from application requests, but both share the same MySQL resources. A large volume of simultaneous SQL queries can overload the primary or replica databases, which can lead to an increase in responses with a 503 HTTP status code. Because of this, all SQL queries and cron tasks should be as performant as possible to prevent negatively impacting the site’s responsiveness, especially during planned, or unplanned, high-traffic events.

Plugins that require write permissions

The /tmp directory is the only writeable path on an application’s web servers. Plugins that attempt to write to any other directory will not work as expected.

Media files that are uploaded or imported to a VIP Platform WordPress environment are not stored in a filesystem local to the site’s web server. Media files are stored on the VIP File System, which is a read-only external object store.

Plugin operations that expect media files to be stored locally, and to have write permissions within uploads/, will not work as expected. An alternative plugin should be considered. Otherwise, modifications might be needed for the plugin’s code to be able to work with uploaded files.

Required write permissions have been observed in the following plugins:

Plugins that attempt to create intermediate images

Plugins that attempt to create separate, additional versions of an image file (i.e. intermediate images) will not work as expected. These plugins can often be identified by operations that are intended to create versions of a file with an image size added at the end file name (e.g. my-image-300x300.jpg). The 300×300 dimension included in the file name indicates that the plugin expects to have write access, but the File System is read-only.

Site and page builders

Site and page builder plugins—and add-on plugins associated with them—are generally not designed to run on a WordPress site at an enterprise scale. For example, some features in page builders are built with the assumption that there is full write access to an application’s file system. An application’s read-only web containers—and the storage of media files in the external VIP File System object store—can cause some page builder’s attempts to dynamically generate files—such as intermediate images, PHP, and CSS—to fail or cause excess (and expensive) HTTP requests.

Customers may need to modify a page builder’s code to be compatible with VIP’s infrastructure. Be aware that this option may require reapplying modifications whenever the plugins are upgraded to newer versions.

As an alternative to site or page builders, VIP encourages customers to research the many features and capabilities of the Block Editor and Full Site Editing (FSE). The Block Editor and FSE are built into WordPress core, are highly customizable, and can be fully supported by the VIP Support team.

Advanced Custom Fields

Several security issues exist in the Advanced Custom Fields (ACF) codebase. For WordPress sites with the ACF plugin enabled, it is strongly recommended that several additional steps are taken to improve security, and prevent unexpected issues with performance and functionality.

Because intermediate image sizes are not created as separate files on the VIP File System, fields that interact with images must interact with images based on image ID to retrieve the correct URL.

  • Directly accessing a preferred file size for an image URL with get_field('image')['sizes']['large']; will not work. Instead, access the image by ID and request the size with wp_get_attachment_image_src( $my_image_field['ID'], 'large' )[0] );.
  • Similarly, update_field('image', $image_url, $post_id); will not work, and update_field('image', $attachment_id, $post_id); should be used instead.

Divi

Features related to Dynamic loading (e.g. “Dynamic CSS”) in the Divi page builder theme will not work as expected on the VIP Platform. Enabling these features can also cause degraded site performance. To prevent these issues, navigate to General -> Performance in the WordPress Admin Divi settings screen and disable all features related to dynamic loading.

Code in the Divi theme also attempts to write files within /wp-content/, which is disallowed by the read-only VIP File System. Customers can opt to modify the theme’s code to be compatible with VIP’s infrastructure, with the caveat that the code will need to be amended each time the theme is updated to the latest release version.

  1. Disable the Divi custom file cache layer and its asset and module caching features by defining these constants in vip-config.php:
vip-config/vip-config.php
define( 'ET_DISABLE_FILE_BASED_CACHE', true );
define( 'ET_BUILDER_CACHE_ASSETS', false );
define( 'ET_BUILDER_CACHE_MODULES', false);
  1. Add this example code to the end of the child theme’s functions.php:
functions.php
/**
 * Define the custom CACHE DIR for Divi theme on VIP
 */
function vip_define_custom_upload_dir_for_divi() {
    $get_wp_vip_upload_dir = wp_get_upload_dir();
    define('ET_CORE_CACHE_DIR', $get_wp_vip_upload_dir['basedir'] . 'et-cache' );
    define('ET_CORE_CACHE_DIR_URL', $get_wp_vip_upload_dir['baseurl'] . 'et-cache' );
}
 
add_action( 'after_setup_theme', 'vip_define_custom_upload_dir_for_divi', 1 );
 
/**
 * Add filter to apply WP_Filesystem credentials.
 */
 
add_filter( 'et_cache_wpfs_credentials', function() {
    return request_filesystem_credentials( site_url() );
});

Elementor

Several features built into the Elementor site builder—as well as features in some Elementor plugins and extensions—have been observed as contributing factors to degraded site performance during high traffic events.

  • Memcache-related performance issues: A significant number of options are autoloaded in alloptions. This results in excessive amounts of time spent processing Memcache calls and can lead to degraded performance
  • Resource-intensive rendering:
    • Content rendering in get_headerprint_content, and get_footer components can contribute up to 90% of total transaction time due to a large number of smaller components all making calls to Elementor\Element_Base::print_element.
    • The page builder functionality utilizes sections, and each section is comprised of a large number of deeply nested components. Elementor lacks a caching mechanism for the output rendered by these components. This results in a large volume of component output needing to be re-rendered by the origin server for every page request.

The above performance issues become exponentially consequential if they occur on a site that requires some areas to be served uncached in order to handle authenticated requests (e.g. WooCommerce).

Last updated: February 21, 2024

Relevant to

  • WordPress