Skip to content

Backgrounds

How-to Guides

Technical References

Code Review /

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. We strongly recommend they be fixed before being committed to VIP Go. Here’s a partial list of what can be an Error:

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 files service. For more information, please consult our page on VIP Go Files Service.

Cache constraints

There are many layers of caching on VIP Go. This means that certain operations may not work as expected. You can learn about the Varnish-powered full page cache as well as the object and database caching by reviewing the caching category of our Technical References. We also have documentation on controlling the VIP Go page cache and on caching for WordPress REST API requests.

Validation, sanitization, and escaping

When writing code for the VIP Go environment, you’ll need to be extra cautious of how you handle data coming into WordPress and how it’s presented to the end user. Please review our documentation on validating, sanitizing, and escaping.

$_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.
  • Must use a nonce added into the new page or section output. For existing core admin pages, use the existing _wpnonce.
  • Must check for user capability.

It’s best to do the output escaping as late as possible, ideally as it’s being outputted, as opposed to further up in your script. This way you can always be sure that your data is properly escaped and you don’t need to remember if the variable has been previously validated.

Here are two examples. In order to keep this straightforward, we’ve kept them simple. Imagine a scenario with much more code between the place where $title is defined and where it’s used. The first example is more clear that $title is escaped.

$title = $instance['title'];

// Logic that sets up the widget

echo $before_title . esc_html( $title ) . $after_title;
$title = esc_html( $instance['title'] );

// Logic that sets up the widget

echo $before_title . $title . $after_title;

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.  This means avoiding .html(), .innerHTML(), and other related functions, and instead using .append(), .prepend(),.before(), .after(), and so on.  You can find more information on our JavaScript security recommendations page.

Manipulating the timezone server-side

Using date_default_timezone_set() or something similar isn’t allowed because it conflicts with stats and other systems. Developers instead should use WordPress’s internal timezone support.

Settings alteration

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

Last updated: April 09, 2021