WP_Queryobject runs five queries by default, including calculating pagination and priming the term and meta caches. Each of the following arguments will remove a query:
'no_found_rows' => true: useful when pagination is not needed.
'update_post_meta_cache' => false: useful when post meta will not be utilized.
'update_post_term_cache' => false: useful when taxonomy terms will not be utilized.
'fields' => 'ids': useful when only the post IDs are needed (less typical).
posts_per_page => -1.
get_posts()unless you have good reason.
WP_Query, but calling
get_posts()directly bypasses a number of filters by default. Not sure whether you need these things or not? You probably don’t.
no_found_rows => trueto
SQL_CALC_FOUND_ROWSon the SQL query, drastically speeding up your query.
SQL_CALC_FOUND_ROWScalculates the total number of rows in your query which is required to know the total amount of “pages” for pagination.
cache_results => falseto
WP_Queryis usually not a good idea.
cache_results => true(which is true by default if you have caching enabled and an object cache setup),
WP_Querywill cache the posts found among other things. It makes sense to use
cache_results => falsein rare situations (possibly WP-CLI commands).
WP_Query, apart from some slight nuances, are quite similar. Both have the same performance cost (minus the implication of skipping filters): the query performed.
WP_Queryobject with the parameters you specify.
query_posts()isn’t meant to be used by plugins or themes. Due to replacing and possibly re-running the main query,
query_posts()is not performant and certainly not an acceptable way of changing the main query.
in_array(), to improve the performance slightly, you should always set the third parameter to
trueto force use of strict comparison.
wp_optionstable with an excessive amount of data. See the “Appropriate Data Storage” section for details.
WP_Queryother than the main query should be cached.
$_COOKIEor other values that are unique to a particular user.
wp-admin/admin-ajax.php. However, WordPress does not cache queries within the administration panel for obvious reasons. Therefore, if you send requests to an admin-ajax.php endpoint, you are bootstrapping WordPress and running un-cached queries. Used properly, this is totally fine. However, this can take down a website if used on the frontend.
prefix_get_posts_from_other_blog()can be called to get posts from a third-party and will handle caching internally.
wp_optionstable. Popular caching plugins such as Memcached place a 1MB limit on individual values stored in cache. A large options table can easily exceed this limit, severely slowing each page load.
add_option(). If your option is not going to get used often, it shouldn’t be autoloaded. As of WordPress 4.2,
update_option()supports configuring autoloading directly by passing an optional
$autoloadargument. Using this third parameter is preferable to using a combination of
add_option()to disable autoloading for existing options.
namespaceidentifier at the top of included files:
usedeclarations should be used for classes outside a file’s namespace. By declaring the full namespace of a class we want to use once at the top of the file, we can refer to it by just its class name, making code easier to read. It also documents a file’s dependencies for future developers.
XWPis (most likely) unique;
themeis not. A simple way to ensure uniqueness is to prefix a declaration with a unique prefix.
public. Anything intended to be private should actually be specified as
protected. There should be no
privatefields or properties without well-documented and agreed-upon rationale.
phpdirectory. All plugin code should be encapsulated in classes, and so each file in this directory should follow the pattern
Foo_Bar) according to WordPress naming conventions.
__constructmethod. Doing so tightly couples the hooks to the instantiation of the class and is less flexible than registering the hooks via a separate method. Unit testing becomes much more difficult as well.
pagepost type. The Theme should register support for this feature using
$_POST['user_id']is validated using
absint()which ensures an integer >= 0. Without validation (or sanitization),
$_POST['user_id']could be used maliciously to inject harmful code or data into the database.
update_option()is storing in the database, the value must be sanitized (or validated). The example uses the
sanitize_text_field()function, which is appropriate for sanitizing general text fields.
sprintf()and essentially calls
mysqli_real_escape_string()on each argument.
mysqli_real_escape_string()escapes characters like
"which prevents many SQL injection attacks.
sprintf(), we are ensuring the argument is forced to be an integer. You might be wondering why
absint()was used since it seems redundant. It’s better to over sanitize than to miss something accidentally.
$wpdb->insert()creates a new row in the database.
$post_contentis being passed into the
post_contentcolumn. The third argument lets us specify a format for our values
sprintf()style. Forcing the value to be a string using the
%sspecifier prevents many SQL injection attacks. However,
wp_kses_post()still needs to be called on
esc_js()should never really be used. To escape strings for JS another function should be used instead, called
wp_json_encode()includes the string-delimiting quotes for you.
esc_attr()to ensure output only contains characters appropriate for an attribute:
wp_kses_*functions can be used:
wp_kses_*functions should be used sparingly as they have bad performance due to a large number of regular expression matching attempts. If you find yourself using
wp_kses_*, it’s worth evaluating what you are doing as a whole.
wp_kses_*on the frontend, output should be cached for as long as possible.
ID1. To do that, you might visit this URL:
https://example.com/wp-admin/post.php?post=1&action=trash&_wpnonce=b192fc4204, the same nonce will not be valid in
printf()formatting codes inside the string to be translated and pass the translated version of that string to
sprintf()to fill in the values.
wp-dev-libwill look for a
phpcs.ruleset.xmlto use for the
pre-commithook and Travis CI build. Please also be aware of the PHP_CodeSniffer-bundled tool
phpcbf(PHP Code Beautifier and Fixer) which also automatically fixes many WordPress Coding Standard violations.
@seetag to explicitly list out the method that is being tested. For instance, given a plugin
Foothat has a class
Barin a file
phpunit.xmlalso includes a
filterconfiguration for restricting the list of PHP files to just those in the plugin when running the code coverage report which can be generated via:
get_template_part()function as a basic template engine. Make your template file consist mostly of HTML, with
<?php ?>tags just where you need to escape and output. The resulting file will be as readable as a heredoc/nowdoc block, but can still perform late escaping within the template itself.