There are 2 caches: one for the CDN, and one for the website’s HTML. The items in the CDN cache do not expire automatically and must be manually purged from the Presslabs Dashboard.
The cached pages have different expiration times based on their freshness. They have by default the following expiry times:
- articles and pages newer than 2 days: 30 minutes (0.5 x base)
- articles and pages newer than 30 days: 1 hour (1 x base)
- articles and pages newer than 365 days: 4 hours (4 x base)
- older articles and pages: 1 day (24 x base)
- all other content: 1 hour
The multipliers cannot be changed, but the base TTL (which is 3600 seconds) can be increased by requesting this to our support team.
Please note that the taxonomy archives, the date archives, and the front page are invalidated on each post or page publication, or update. When comments are made, deleted, approved, or marked as spam, that particular article is refreshed as well.
Another important note is that an item can be refreshed only every 15 seconds. So, if you repeatedly click the
update button too soon, the content will not be refreshed.
Later edit: Starting with April 2016 we’re caching all the GET requests, for any resources (even PHP, excluding some key paths like
xmlrpc.php). In order to make a request more cache-friendly and reliable we’re stripping down all the parameters which are not standard. In other words non-standard parameters are not passed to the backend (where php gets executed). This is the list of parameters which we cache and pass to the backend (WP API specific arguments and WP Query Vars from WordPress Query Vars – Codex):
Besides this list, all filter parameters like
filter[*] are also passed to the backend and cached.
Additionally, you can add custom non-strippable parameters from our dashboard,
Your website’s code is executed in an isolated LXC containter, and it has limitations when it comes to memory and execution time.
By default, the memory is limited to 128MB per request.
The timeouts follow the these rules:
- website public pages – 30 seconds
- wp-admin – 30 seconds, and it can be increased up to 60 seconds with a support ticket
- wp-cron – 30 seconds, and it can be increased using
set_time_limit(). There is a 15 minutes hard limit, though.
Random script execution
Also note that direct access to
.php URLs is forbidden with a few exceptions:
This is because we only allow WordPress code to be executed.
PHP debugging and reporting levels
When a PHP error occurs, a visitor is presented with a page containing a
request_id. You can use that to search the error log in the Presslabs Dashboard. You can also log warning and notices by changing the
Log level from the
Development section of the dashboard. There are four log levels:
ERROR: only fatal errors are logged. This means all PHP fatal errors and
WARNING: warnings are logged as well. This extends
NOTICE: this logs everything, including
DEBUG: this enables
WP_DEBUGand changes the way errors are displayed by including the stack trace. Note that displaying the stack trace can expose sensitive information, so use it carefully on production websites.
Presslabs specific headers
Presslabs responses contain 2 headers:
X-Request-ID: It’s a unique ID associated with each request. This can be used for tracking down errors.
X-Presslabs-Stats: Contains various stats about the request, separated by semicolon.
- cache status:
- time taken to generate the page
- number of queries needed to generate this page
- request type:
- cached item TTL
- time until cache refresh of this item
- cache status:
Caveats and workarounds
Static content at web root
In the site’s git repository there is a
/wp-content/root folder. All static content in this folder is served from the site’s root. For example, if there is a file
/wp-content/root/ads/banner-720.html, that file will be served from the website at the following address
This, of course, forbids any URLs starting with
In order to provide secure dashboard access and to separate the WordPress dashboard from the public site, we are using a separate domain,
We are using Memcached as a persistent backend for WordPress’s object cache. There is a limitation of 1MB on a cached value size. Saving larger options can cause your options to be saved incorrectly in Memcached. For this reason, all options larger than 64KB are getting logged and can be looked up into the
Error log console in the