Plugin incompatibilities
All WordPress sites on the VIP Platform are provisioned with robust, built-in performance features such as:
- Page caching that runs on a global network of edge cache servers.
- JavaScript and CSS files are concatenated in order to reduce the number of requests that occur on a single page load. CSS files are minified as well as concatenated.
- Gzip compression for all HTML, CSS, JS, and image files.
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:
- Backups: Backups for an environment’s SQL database and media files occur automatically at a platform-level.
- Exports: Download database backups and download media backups at any time from the VIP Dashboard.
- Imports: Import SQL database files and import media files to a VIP Platform environment at any time with VIP-CLI.
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:
- Converted and served as next-gen formats to compatible browsers, including
*.webp
files. - Served with
srcset
attributes. - Able to be dynamically resized, cropped and processed.
- Cached at the edge.
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:
- Contact Form 7 (versions earlier than 5.8.1)
- Gravity Forms
- Ninja Tables
- TablePress
- Ultimate Tables
- WordPress Multilingual Plugin (WPML): The plugin’s incompatible requirement for write access can be avoided by instead generating language files locally and committing them to the GitHub
/languages
directory. - wpData Tables
- WPForms
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.
- Disable custom fields editing in the WordPress Admin dashboard with the filter:
add_filter( 'acf/settings/show_admin', '__return_false' );
- Register fields via PHP.
- In ACF version 6.2.7 and later, the ACF
the_field()
function applieswp_kses()
to the field value before rendering to remove unsafe scripts or HTML, but still renders HTML saved in field values. If using an earlier version of ACF—or if the field should not contain HTML or is being used in an attribute or URL—useget_field()
with the appropriate escaping function (i.e.esc_html()
,esc_attr()
oresc_url()
) instead. - Apply HTML escaping wherever HTML is rendered by ACF.
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 withwp_get_attachment_image_src( $my_image_field['ID'], 'large' )[0] );
. - Similarly,
update_field('image', $image_url, $post_id);
will not work, andupdate_field('image', $attachment_id, $post_id);
should be used instead.
Divi
The Divi theme has two known incompatibilities with WPVIP’s infrastructure. Customers have the option to try the suggestions below to resolve the incompatibilities, with the limitation that these suggestions are not kept up to date with every Divi version release. It is the customer’s responsibility to test all setting changes and code modifications on a non-production environment before adding those changes or code to a production environment.
Dynamic CSS
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.
Writing files
Cache functionality in the Divi theme attempts to write files within /wp-content/
, which is disallowed by the read-only VIP File System. To prevent related errors from being generated on sites where the Divi theme is enabled, Divi’s cache functionality is disabled by VIP MU plugins.
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_header
,print_content
, andget_footer
components can contribute up to 90% of total transaction time due to a large number of smaller components all making calls toElementor\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.
- Content rendering in
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).
Incompatible SVG retrieval operation
Elementor uses the PHP function realpath()
to process the path to an SVG file in the WordPress Media Library. Because the VIP File System uses an object store, it lacks a true directory structure. Directory-related operations like realpath()
will not work as expected.
Last updated: August 20, 2024