Platform specifications

#Caches

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 wp-login.php, wp-signup.php, wp-cron.php and 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):

• attachment_id
• author
• author_email
• author_exclude
• context
• exclude
• feed
• hide_empty
• karma
• id
• include
• media_type
• meme_type
• menu_order
• offset
• order
• orderby
• p
• page
• page_id
• parent
• parent_exclude
• per_page
• post
• robots
• s
• search
• slug
• status
• type
• wpmp_switcher
• wptouch_switch

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, Development menu.

#PHP environment

Your website’s code is executed in an isolated LXC containter, and it has limitations when it comes to memory and execution time.

#Memory limits

By default, the memory is limited to 128MB per request.

#Execution timeouts

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:

• /wp-admin/admin-ajax.php
• /index.php
• /wp-login.php

This is because we only allow WordPress code to be executed.

#PHP sessions

The PHP sessions are not supported by our platform. If you need to store session data, you should use transients, or you can try the still undocumented WordPress sessions.

#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 E_USER_ERROR.
• WARNING: warnings are logged as well. This extends ERROR level with E_WARNING, E_CORE_WARNING, E_COMPILE_WARNING, E_USER_WARNING.
• NOTICE: this logs everything, including E_USER_NOTICE, E_NOTICE, E_DEPRECATED, E_USER_DEPRECATED, E_STRICT.
• DEBUG: this enables WP_DEBUG and 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: HIT, MISS, EXPIRED, BYPASS
  • time taken to generate the page
  • number of queries needed to generate this page
  • request type: desktop or mobile
  • cached item TTL
  • time until cache refresh of this item

#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 www.example.com/ads/banner-720.html.

This, of course, forbids any URLs starting with /root/ like www.example.com/root/.

#Wrong JavaScript and CSS URLs

In order to provide secure dashboard access and to separate the WordPress dashboard from the public site, we are using a separate domain, plssl.com. If you get wrong URLs for plugin styles or JavaScript, you are most likely not following the Determining Plugin and Content Directories guide.

#Large options

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 Development panel.