Skip to content

VIP errors

Errors are items that if not fixed will likely either not work because of platform incompatibility issues or open your site to serious performance and security issues. It is strongly recommended to resolve errors as soon as possible, preferably before they are committed to an environment on the VIP Platform.

Cache constraints

There are multiple layers of caching on the VIP Platform (e.g., page cache, object cache, caching of WP REST API requests) which can cause some operations to not work as expected.

Filesystem operations

On the VIP Platform, web servers run in read-only mode. File operations are only allowed in the /tmp/ directory and media uploads via the VIP Platform File System.

Inserting HTML directly into DOM with JavaScript

To avoid XSS, refrain from inserting HTML directly into the document.  Instead, DOM nodes should be programmatically created and appended to the DOM. Avoid .html(), .innerHTML(), and other related functions. Instead, use functions such as .append(), .prepend(),.before(), .after().  Read more information about JavaScript security recommendations.

Manipulating the timezone server-side

Functions such as date_default_timezone_set() conflict with stats and other systems and are not allowed. Instead, developers should use WordPress’s internal timezone support to obtain a local time.

Order by rand

MySQL queries that use ORDER BY RAND() are expensive and slow on large datasets. A more performant alternative would be a custom function that retrieves 100 posts and picks one at random, or using vip_get_random_posts() which performs a similar function.

Settings alteration

Using ini_set() for alternating PHP settings (as well as other functions with the ability to change the configuration at runtime of scripts, such as error_reporting()) is strongly discouraged on the VIP Platform. Allowed error reporting in production can lead to Full Path Disclosure.

Validation, sanitization, and escaping

When writing code for the VIP Platform environment, use validating, sanitizing, and escaping vigilantly to securely handle data incoming to WordPress, and to present it to the end user.

$_GET, $_POST, $_REQUEST, $_SERVER and other data from untrusted sources (including values from the database such as post meta and options) need to be validated and sanitized as early as possible (e.g. when assigning a $_POST value to a local variable) and escaped as late as possible on output.

Nonces should be used to validate all form submissions.

Capability checks need to validate that users can take the requested actions.

The save / update handler for new admin pages, new sections or existing core admin pages must:

  • Do a nonce check.
  • Use a nonce added into the new page or section output. For existing core admin pages, use the existing _wpnonce.
  • Check for user capability.

It is best to do the output escaping as late as possible, ideally as it is being outputted. This makes it possible to ensure that data is properly escaped and there is no need to remember if the variable was previously validated.

In this example, the value of $title was escaped, but it occurrs earlier in the code and requires effort to confirm that the escaping took place:

$title = esc_html( $instance['title'] );

// Logic that sets up the widget

echo $before_title . $title . $after_title;

In this example, the code reads more clearly that $title is escaped:

$title = $instance['title'];

// Logic that sets up the widget

echo $before_title . esc_html( $title ) . $after_title;

Last updated: September 12, 2022