Jonathan Desrosiers 7:00 pm on January 23, 2019
Tags: ,   

Miscellaneous Developer Focused Changes in 5.1

In WordPress 5.1, a handful of small developer-focused changes were made that deserve to be called out. Let’s take a look!

File Path Value For WP_DEBUG_LOG

WP_DEBUG_LOG is a constant that tells WordPress to enable or disable error logging. Its default value is false (no error logging). But, if it’s defined as true (or 1) in the wp-config.php file, site errors will be logged in the wp-content/debug.log file.

Starting in WordPress 5.1, WP_DEBUG_LOG will also accept a file path as a value allowing a custom error log to be defined. For example:

define( 'WP_DEBUG_LOG', '/srv/path/to/custom/log/location/errors.log' );

Here are a few things to keep in mind:

  • The directory must already exist and be writable by the web server’s user.
  • The file does not need to exist. It will be created once the first error occurs as long as the previous condition is met.

Reminder: Any values set to WP_DEBUG_LOG and WP_DEBUG_DISPLAY will be ignored unless WP_DEBUG is set to true.

For more information, see #18391.

Test Suite: New Test Config File Constant

When running PHPUnit tests, the WordPress test suite requires a wp-tests-config.php file to be present in order to run correctly. This file provides information similar to that provided by the wp-config.php file. This includes database information, site domain and title, etc. (see the wp-tests-config-sample.php file for more information). However, the test suite bootstrap file requires this file to be in one of two locations: the test directory (tests/phpunit), or the root of the develop repository.

Starting in WordPress 5.1, the WP_TESTS_CONFIG_FILE_PATH constant can now be added to the phpunit.xml configuration file to define a custom location for the wp-tests-config.php file.

<phpunit ...
	<php>
		<const name="WP_TESTS_CONFIG_FILE_PATH" value="/path/to/wp-tests-config.php" />
	</php>
</phpunit>

For more information, see #39734.

New PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Action HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.

In WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. today, the plugins_loaded, network_plugins_loaded, and muplugins_loaded action hooks exist, but these hooks are only run after all plugins of their respective types have been loaded. There is no easy way to execute arbitrary code between each plugin being loaded or only after plugin X is loaded.

This makes it difficult for developers to conduct performance monitoring and debugging during this stage of the loading process. In WordPress 5.1, the following action hooks will be added:

  • plugin_loaded
  • network_plugin_loaded
  • mu_plugin_loaded

These hooks will fire after every plugin is loaded. Each action hook will pass one argument, the full path of the main plugin file.

Because these hooks are fired after every individual plugin is loaded, they are not recommended as a replacement for plugins_loaded. Using them in this manner will cause issues with performance.

For more information, see #41346.

Short Circuit FilterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for wp_unique_post_slug()

When a post is created or updated, wp_unique_post_slug() is used to ensure that the post slug (post_name field) is unique to that post. By default, the function will add a numeric suffix to the desired post_name value and increment until a unique value is created (desired-slug-2, desired-slug-3, etc.).

In some scenarios (when post titles are the same and no post_name values are provided, for example), this can result in a performance bottleneck because a new query is performed every time the suffix is incremented until a unique value is created.

To help with this scenario, the pre_wp_unique_post_slug filter has been added in WordPress 5.1. If a non-null value is returned, the function will return that value and skip the default logic in the function. The new filter also opens the door for a handful of other use cases, such as always replacing certain terms in post names (changing wp to wordpress, for example).

For more information, see #21112.

Additional Developer Goodies

  • wp_debug_backtrace_summary() (which returns a list of functions called to get to the current point in the code) will now correctly capture hook names for do_action_ref_array() and apply_filters_ref_array() calls (see #43488). Previously, only do_action() and apply_filters() were captured.
  • $wpdb->queries logs the elapsed time for each query but lacks the starting time. This has been added in 5.1 (see #43315).
  • The WP_Error class now has a has_errors() method, which returns a boolean value indicating if an instance contains errors. This adds consistency to code that has previously checked for errors in a variety of ways, such as if ( $error->get_error_code() ) and if ( empty( $error->errors ) ) (see #42742).
  • A large number of inline documentation updates have been made to ensure accuracy proper formatting.

#5-1, #dev-notes