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.
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.
To avoid XSS, refrain from inserting HTML directly into the document. Instead, DOM nodes should be programmatically created and appended to the DOM. Avoid
.innerHTML(), and other related functions. Instead, use functions such as
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.
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.
$_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
- 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;