This page offers answers to common questions about default platform settings, WordPress settings, and server configuration settings. You can use this as a quick reference for many settings and how they are configured or changed.
WordPress Memory Limit
The default WordPress Memory Limit is 40MB for a single site, or 64MB for a Multisite network.
These values can be increased to a maximum of 512MB by inserting the following lines under the “WP Engine Settings” section in your wp-config.php file:
define( 'WP_MEMORY_LIMIT', '512M' );
If you want to define a separate higher or lower memory for the WordPress admin area of the site, can add the following line after the one above:
define( 'WP_MAX_MEMORY_LIMIT', '512M' );
WooCommerce recommends setting this value to at least 128MB. You are free to define whichever memory value works best for your site, as long as it does not exceed 512MB.
Maximum File Upload Size
The default maximum upload file size for sites is 50MB (or 1MB for multisite networks). You can check what the site is currently registering for the max file upload size from the
Max File Upload Size on Multisite
In addition to reaching out to Support, you will also need to update the network upload size if you are using a WordPress multisite.
- Login to your WordPress admin dashboard
- Click My Sites
- Select Network Admin
- Click Settings
- Locate Max upload file size
- ** The size here is in KB, not MB
PHP Image Resize Limit
WP Engine limits the size of images that can resized using PHP. This size limit is 8000px by 8000px, or 40MP. We’ve put this limit in place to protect server memory and stability, and therefore it cannot be increased.
Plugins that resize images using PHP, such as Smush or ImageMagick, may run into errors if the image is too large. For example you may see the error,
width or height exceeds limit. If you are seeing such an error, resize the image below the limitations prior to attempting the upload again.
PHP Execution Restricted
WP Engine servers block the execution of
.php files from within the
wp-content/uploads/ directory. This directory is intended only for media, it is best practice to not execute PHP from these folders.
WordPress Post Revisions, or autosaves, store a record of each saved draft or published update for a post. This system allows a user to see the last few changes and to restore a page or post to a previous version.
While great in theory, revisions cause the database to grow exponentially and a large database can directly impact site performance.
Every WP Engine site has WordPress revisions disabled by default. It’s our recommendation to keep revisions disabled to assure optimal site performance and to use a separate editor for managing content prior to publishing.
Revisions can only be enabled by contacting Support. Revisions cannot be enabled in the
php.ini files, as this will be overwritten at the server level.
If you migrated a site with existing revisions that you would like to preserve, reach out to Support to have revisions enabled.
- Support can help you enable 3 revisions for your posts to start. Revisions should not exceed 5.
- Old revisions will be automatically removed after 60 days.
NOTE: Enabling revisions is not a retroactive change. Only revisions generated after the feature has been enabled will be stored moving forward.
If you would like to clean up your database and delete any existing database revisions, the following query can be run from phpMyAdmin.
DELETE FROM wp_posts WHERE post_type = “revision”;
WP Engine allows general WordPress emails such as password resets to be sent through WordPress below a certain reasonable quantity. However, for sending a large number of emails, such as a newsletter or email blast, we impose a limit and require the use of an email API or an SMTP plugin.
As Port 25 is blocked for all services, we highly recommend using an email service that sends email via API, or an alternative port (such as port 2525).
All WP Engine servers have TLS 1.2 and 1.3 enabled by default.
TLS 1.0 and 1.1 will be deprecated on March 31st. As TLS 1.0/1.1 deprecation is happening across the industry, we will not be offering the option for customers to defer or opt into a version lower than TLS 1.2. For a majority of customers, an update to TLS 1.2+ should not cause any noticeable impact.
GZIP and Brotli Compression
If the browser requesting the file supports Brotli compression, the file will be served compressed with Brotli. If the requesting browser does not support Brotli the file will be served compressed with GZIP.
The following file types are automatically compressed by WP Engine with Brotli:
The following file types are automatically compressed by WP Engine with GZIP:
Max Execution Time
max_execution_time for scripts is set to 60 seconds.
This setting can only be decreased, and cannot be increased. If you are performing a task which will take over 60 seconds to complete, the task should be broken into smaller segments and run in batches.
Max Input Vars
max_input_vars setting is 10000, indicating no more than 10,000 variables can be attached to any request.
This setting cannot be adjusted, as this is set at a platform level and higher values will have negative performance implications.
If you want to ensure extra security on your site through the use of headers, many are already added by default. If the header you’d like is not enabled automatically, they can be added through the Web Rules page in your User Portal.
HTTP Strict Transport Security (HSTS) is a security policy allowing web servers to declare that browsers (or other complying user agents) should only interact using secure HTTPS connections. Setting this up on WP Engine can be done by adding a header to the Web Rules area of the User Portal.
This rule is the simplest HSTS header that can be added, indicating that once a browser has read the header it should remember it for 63072000 seconds (2 years).
add_header Strict-Transport-Security "max-age=63072000";
When added as a header rule it will look like the following:
HSTS headers come with two additional directives:
includeSubdomains. Adding both of these additional directives would look like this:
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
Below are all the default directives you will typically need to pass a security header test. These headers can be modified as-needed.
A few notes about the directives:
includeSubdomainsaffects all subdomains, even ones on other hosts. This is due to the browser registering the HSTS header with the directive and will apply it to all relevant subdomains
preloaddirective allows a site to be to be registered at https://hstspreload.org/, which adds the domain to the Chrome HSTS preload list that is hard coded in to browsers. Other browsers also use this list.
- If there is an error with the verification on this service, make sure that no domain-level redirects are set in the User Portal. For example, non-www to www or vice versa. Any redirects from the root domain must be removed completely.
- Removal from the
preloadlist can be a lengthy process:
Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.
Misc Security Headers
The following security headers can also be added through the Web Rules page of the User Portal. We’ve included examples of the most common header options, but many can be modified to suit your specific needs.
Ensures the correct content is delivered for the specific browser. This is particularly relevant when caching or proxy layers are at play, as older browsers may not understand more modern compression or file types. The following is the recommended rule configuration.
proxy_set_header Vary "Accept-Encoding";
Protects (typically older) browsers from cross-site scripting attacks. The following is the recommended configuration rule.
add_header X-XSS-Protection "1; mode=block";
Allows opt-in and opt-out standardization for features on a website, particularly when APIs or third-party apps are used. The following is a usable example but it can be modified if necessary.
add_header Feature-Policy "geolocation 'none';midi 'none';notifications 'none';push 'none';sync-xhr 'none';microphone 'none';camera 'none';magnetometer 'none';gyroscope 'none';speaker 'self';vibrate 'none';fullscreen 'self';payment 'none';";
Identifies the address of the webpage associated with a requested resource. The following is a usable example but can be modified for different needs.
add_header Referrer-Policy "origin" always;
add_header X-Content-Type-Options "nosniff" always;
Determines whether or not a page can be loaded as a
<object>. The following tells the page that it can only be displayed as one of these types on a page with the same origin. This rule can be modified to allow other URIs if needed.
add_header X-Frame-Options "SAMEORIGIN" always;
WP Engine has a specific set of platform-wide server modules which cannot be modified, removed, or added. To see a full list of modules, versions, and default settings, you can create a PHP Info file.
Disabled Functions and Modules
Our system administrators have already pre-configured server settings to best suit the needs of the majority of our clients. Some functions cannot be modified from site to site or in the php.ini file as they are configured at a server level.
Here are some functions that have been disabled and therefore are not able to be altered:
|Module||Is it installed?|
Most plugins are allowed on the WP Engine platform, however a handful of plugins we specifically disallow, as they will cause issues with either security or performance.
Although they are not disallowed, some plugins are still incompatible with the WP Engine platform. This is most impactful for plugins and themes utilizing ionCube. The ionCube Loader module is not available on WP Engine due to the significant performance issues it causes.
PHP Versions are regularly released and deprecated. To see which versions are currently available on the WP Engine farm and how to change versions, check out our PHP Upgrade Guide.
WP Engine uses MySQL 5.6 and MySQL 5.7. New Digital Experiences will be placed on MySQL 5.7. To learn which MySQL version you are on, please contact Support.
WP Engine does not use the
mod_security Web Application Firewall (WAF) with Apache. Instead, we use a proprietary traffic detection and blocking system among other enterprise-grade security measures. This firewall will automatically block IPs or User Agents based on a predetermined set of rules.
If you’d like to manually block an IP, User Agent or country on this firewall, reach out to our Support team for assistance.
There are several site and server-wide configuration files in place for each environment. Some files are accessible and able to be modified, while others are not.
|Configuration file||Is it editable?|
|php.ini file||No. Server-wide PHP settings are unable to be changed.|
|.htaccess file||No. WP Engine has deprecated the .htaccess file.|
|wp-config.php file||Yes. This file can be edited, but there are many WP Engine-specific settings in this file which should not be changed. For the best results, put custom entries in the “WP Engine Settings” section at the bottom.|
|nginx.conf file||No. Server or site-specific Nginx settings are not able to be adjusted. If there is a specific Nginx setting you wish to adjust, please contact Support to see if there are any internal changes which may be made|
WP Engine MU Plugins
There are certain must-use plugins that you may see added to your WordPress website by WP Engine. These are added for specific reasons, such as security or functionality.
While we don’t recommend it, some of these plugins can be disabled. If you’d like to remove a WP Engine MU plugin, reach out to our Support team.
WP Engine Common
wpengine-common plugin provides most of the WP Engine platform functionality. Platform features provided by this plugin can be seen in your wp-admin dashboard under the WP Engine menu icon.
This plugin cannot be disabled, however the menu icon can be hidden with custom coding.
WP Engine Seamless Login
wpe-wp-sign-on-plugin plugin files are added for the WP Engine “Seamless Login” feature. This feature gives you the ability to securely log in to the wp-admin of a website directly from the User Portal.
To learn more about this functionality see the Seamless Login guide.
WP Engine Security Auditor
wpengine-security-auditor plugin performs two main functions:
- Log security-relevant events to the Apache error log. Examples of logged events are login, role changes, and plugin upgrades.
- Periodically calculate and log checksums for plugins, themes, and WP core files.
We do not recommend disabling this plugin as it adds security features. However, if you find too many events are being logged it can be disabled by adding the following feature flag to your
Force Strong Passwords
force-strong-passwords is added to force all users with access to the wp-admin are of your site to use strong passwords. Strong passwords are only required for Administrator, Editor, and Author roles. It is not required for “weaker” roles like Subscriber and Contributor. Our system to force a strong password only requires users to set a strong password when resetting the password from the wp-login.php page.
This plugin should never be disabled as it can create a serious security vulnerability in your website.
NEXT STEP: Learn more about .htaccess alternatives