Privacy: get_the_privacy_policy_link() should strip HTML tags and return plain text

[wildworks]

Post titles can contain HTML elements. On the other hand, the get_the_privacy_policy_link() function escapes HTML. As a result, unnatural links may be generated. We should probably remove the HTML instead of escaping it.

[wildworks]

Login page. Text containing escaped HTML is displayed as a link.

[hbhalodia]

@wildworks, Can we update the description? there is a typo in function get_the_policy_policy_link() should be => get_the_privacy_policy_link().

[hbhalodia]

Hi @wildworks, I attempted to reproduce the issue locally. What I observed is that the < character is already converted to &lt; (and similarly > to &gt;) when stored. Because of this, using wp_strip_all_tags() would not have any effect, as the database itself contains the encoded entities rather than actual HTML tags.

If I understand the concern correctly, for a title such as Privacy <strong>Policy</strong>, the expected output would be Privacy Policy, with the <strong> tag removed and only the plain text displayed.

In order to achieve this, we may first needs to convert back to HTML entity and then use wp_strip_all_tags function to remove any HTML tags.

Let me know if I understand the issue correctly?

Thanks,

[wildworks]

@hbhalodia Thank you for your interest in this ticket. I think your guess is correct. Adding unit tests would be great too.

[westonruter]

Note that the block editor doesn't allow you to add markup to the post title. You can, however, add markup via the quick edit on the post list table. So I don't think that decoding the entities is correct.

I also think perhaps wp_kses_post() should be used instead of esc_html().

Trac ticket: https://core.trac.wordpress.org/ticket/64748

• Used wp_kses_post() instead of esc_html()

Before	After

## Use of AI Tools

[ozgursar]

Patch Testing Report

Patch Tested: ​https://github.com/WordPress/wordpress-develop/pull/11088

Environment

• WordPress: 7.0-beta2-61752-src
• PHP: 8.2.29
• Server: nginx/1.29.4
• Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Steps taken

1. On the pages list, use Quick Edit to change Privacy Policy page's title to <strong><em>Privacy Policy</em></strong> and Publish.
2. View the Login page. Escaped HTML tags are visible.
3. Apply the patch
4. View the Login page again. HTML tags are applied to the link.
5. ✅ Patch is solving the problem

Expected result

• If the HTML formatting is intentional and expected then it should render as a part of page title. wp_kses_post() provides this flexibility.

Screenshots/Screencast with results

Before

After

[noruzzaman]

Test Report

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/11088

Environment

• WordPress: 7.0-beta2-20260226.234351
• PHP: 7.4.33
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
• Browser: Chrome 145.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.4
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.1

Actual Results

1. ✅ Issue resolved with patch.

Before	After

[westonruter]

As commented on the PR:

Here is another set of instances where this same issue will.occur: ​https://github.com/search?q=repo%3AWordPress%2Fwordpress-develop+%2Fesc_html%5C%28+get_the_title%5C%28%2F&type=code

This doesn't catch cases where get_the_title() is stored in a variable and then later echoed.

I think it would sense to change the scope of the ticket to address this issue for all these cases.

An AI search should be able to find more instances, such as for the privacy policy link on the login screen.

Should we consider removing esc_html() across all related instances?

Yes

[sabernhardt]

This is not a good change to make during beta, especially if the ticket involves more links.

The Privacy Policy page title was added to the link with esc_html() in #44192 / [43506].

I see three options to avoid unwanted or possibly dangerous HTML:

1. Keep the esc_html() escaping, and anyone who wants HTML can use the 'the_privacy_policy_link' hook to make specific elements display (which has been possible since WordPress 4.9.8, more than 7 years ago).
2. Switch to wp_strip_all_tags(), assuming that no HTML elements belong within the privacy link when using the core function (in places such as the login screen or theme footer). This could help when the element was pasted unintentionally. However, someone who wants HTML would still need to use the filter, in a new way.
3. Use wp_kses() with a small set of allowed elements, not wp_kses_post(). Possibilities include br, em, and strong, but I would prefer to have specific examples of how they are appropriate before adding support for each of them.

[westonruter]

Replying to sabernhardt:

3. Use wp_kses() with a small set of allowed elements, not wp_kses_post(). Possibilities include br, em, and strong, but I would prefer to have specific examples of how they are appropriate before adding support for each of them.

I like this option, to allow a small list of formatting tags which are expected to be used in titles.

Also, I see that markup provided in post_title does not get rendered in the post list table. If I provide Read the <code>SCRIPT</code> in a post title, I see that as-is in the post list table, but on the frontend I see it rendered as “Read the SCRIPT”. While that may be the existing behavior, it's probably not ideal and some formatting should be used. Nevertheless, the block editor doesn't currently facilitate formatting of text in the title, while the classic editor did. You can still use the quick edit interface on post list table to provide markup, however. See ​Gutenberg#20320 for the feature request.