Developer Focused Privacy Updates in 5.2

WordPress 5.2 brings several improvements for developers working with Privacy Policy pages and data exports.

New Privacy Policy Page Helpers

Four new features have been added to make customizing and designing the Privacy Policy page easier:

  • A new function, is_privacy_policy(), can be used in conditionals to identify whether the current $wp_query is for the Privacy Policy page.
  • A new theme template file, privacy-policy.php, is used for rendering the page assigned as the Privacy Policy.
  • .privacy-policy has been added as a body class and is inserted when the currently rendered page is the Privacy Policy page.
  • .menu-item-privacy-policy has been added as a menu item class to specify the menu link that points to the Privacy Policy page.

Backwards Compatibility

The only backwards compatibility concern with using these new helpers is with the is_privacy_policy() function, which would trigger a Call to undefined function fatal error.

Themes and plugins that would like to support the is_privacy_policy() function in older versions of WordPress can use the following shim:

if ( ! function_exists( 'is_privacy_policy' ) ) {
    function is_privacy_policy() {
        return get_option( 'wp_page_for_privacy_policy' ) && is_page( get_option( 'wp_page_for_privacy_policy' ) );
    }
}

For more information, see #44005.

Loosened Tag Restrictions in User Data Exports

User Data exports no longer use a hardcoded list of allowed tags, limited to just <a> and <br>. They will now use the default list of allowed tags in wp_kses().

Furthermore, the code facilitating the export now passes a personal_data_export context to wp_kses(), so that the allowed tags and attributes can be filtered using the wp_kses_allowed_html 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. and checking for the personal_data_export context.

Here’s a filter example that adds support for the <sub> and <sup> tags to the personal data export:

function prefix_allowed_html_filter( $allowedtags, $context ) {
	// Only target personal data export.
	if ( 'personal_data_export' !== $context ) {
		return $allowedtags;
	}

	// Add support for the sub tag.
	if ( ! isset( $allowedtags['sub'] ) ) {
		$allowedtags['sub'] = array();
	}

	// Add support for the sup tag.
	if ( ! isset( $allowedtags['sup'] ) ) {
		$allowedtags['sup'] = array();
	}

	return $allowedtags;
}
add_filter( 'wp_kses_allowed_html', 'prefix_allowed_html_filter', 2, 10);

For more information, check out the documentation for the wp_kses_allowed_html filter.

See: #44044

#5-2, #core-privacy, #dev-notes, #privacy, #themes