target="_blank" being stripped from Profile Bio and Category Description

[lovewpmu]

Many apologies if this is a duplicate. I have searched but did not find it yet posted.

I noticed that target="_blank" is being stripped from my "a href" tags my profile "Biographical Info" field even though the "a href" with the URL and closing tag still remain. It happens every time I save my profile.

This was independently verified.

It is a regular wordpress install running 2.9.1 (not wordpressmu, etc.).

My original thread can be found here:
​http://wordpress.org/support/topic/355388?replies=1

[miqrogroove]

The target attribute is still valid as of XHTML 1.0 Transitional, but you will probably have to use onclick instead. Probably neither are allowed to non-administrators.

[lovewpmu]

there is no reason why someone who is filling out their bio with links to the relevant online info should need to code in javascript. in fact, most people using wordpress -- ie. the common user -- probably cannot. i believe the links on the HTML generated for posts, _blank is used for the "Open in New Window" option.

this should be standardized and completely independent from whether one is or is not an administrator.

[miqrogroove]

It does seem to be using the same filters for admins. That's a bit surprising.

[miqrogroove]

It's set up as a default filter for pre_user_description so you could override that with a plugin.

You might have a case for enabling unfiltered bios for administrators, but beyond that I think the "it's allowed in posts" argument isn't going to fly. WordPress explicitly filters bios the same way as comments instead of posts.

[bsutcliffe]

This also occurs in category descriptions. If I add a link to one of my category descriptions and specify target="_blank", the target reference gets stripped out when saving. Unlike bios, this filter definitely should not be applied.

[sjefen6]

Images, lists and class specifications are also being stripped away from category descriptions. What is the reasoning for being so strict with category descriptions?

[nofearinc]

sample target addition to $allowedtags

[nofearinc]

Adding the target to the anchor array of $allowedtags would solve that globally in kses.php after the default filters are applied in default-filters.php, but I guess there might be a security risk with adding a frame target to external location? I've uploaded a sample proof of concept above.

Not sure if there is a way to globally allow a given value for an attribute in $allowedtags.

[nacin]

This is "intentional" but we may be able to fix this now. kses can now make changes based on a particular filter. Otherwise changing $allowedtags would open this up for comments.

[harmr]

+1 for enabling href/target by default for $allowedtags

[blogitsolutions]

+1 for enabling _blank (ticket is now 8 years old)

[stefahn]

+1 for letting us open links in the author bio in a new tab.

[ctrlaltdelete]

Awesome.

[arvindwp]

Not yet resolved? facing same issue. Author social bio should not cause visitor to mve away from website. Any fix?

[nofearinc]

Just tested my 2013 patch above and it still works here. Once applied, you can save target="_blank" to your bio and it no longer gets stripped.

[stefahn]

Who will merge this patch into master?

## Description

This PR ensures that target="_blank" is preserved in the Biographical Info and Category Description fields to maintain the intended link behavior.

## Changes Made

• Add target attribute for anchor tag in $allowedtags in wp-includes/kses.php.

## Trac ticket: https://core.trac.wordpress.org/ticket/12056

This change will affect the behaviour of all kses_* functions. I am not sure if that is desired.

@martinkrcho You are right; changing the $allowedtags would indeed affect the behaviour of all kses_* functions, which might not be ideal. I will look for an alternative solution.

@martinkrcho Could you please take a look at the PR and let me know if the new changes are satisfactory?

@nirajgiriXD I prefer this approach to the previous one. It affects only a limited number of filters.

Would you be able to provide unit tests or provide instructions for manual testing (in the Trac ticket)?

@martinkrcho I've added the testing instructions along with some screenshots to the PR description.

[nirajgirixd]

I've submitted a ​PR to resolve this issue, and it has already been approved. Could someone please review it and merge it into the trunk? If any further changes are needed, please feel free to suggest them.

cc: @nacin, @spacedmonkey, @johnbillion

[spacedmonkey]

@nirajgirixd any change like this would need a unit test to validate the change doesn’t break anything. Hopefully we can get this change in the next release of WordPress.

[nirajgirixd]

@spacedmonkey Thank you for the feedback.

## Preserve target="_blank" in Biographical Info and Category Description

### Description
This pull request ensures that the target="_blank" attribute is preserved when adding links in the Biographical Info and Category Description fields. Previously, this attribute was being stripped by the kses sanitization process.

Additionally, new unit tests have been added to verify the preservation of the target="_blank" attribute in these specific contexts.

### Changes Made

• Added the target attribute to the allowed tags in the user_description and pre_term_description contexts in wp_kses_allowed_html().
• Added the following new unit tests:
  • test_target_attribute_preserved_in_user_description()
  • test_target_attribute_preserved_in_term_description()
  • test_target_attribute_preserved_in_user_description_with_other_attributes()
  • test_target_attribute_preserved_in_term_description_with_other_attributes()

[audrasjb]

Thanks for the PR! Self assigning for final review.

Closed in favor of ​https://github.com/WordPress/wordpress-develop/pull/7792

closed in favor of ​https://github.com/WordPress/wordpress-develop/pull/7792

[gaellebesson]

Testing PullRequest 7792

[gaellebesson]

Hello, this is my first contribution to WordPress Core from the Whodunit Contributor Day :)

Test Report

This report validates that the indicated patch addresses the issue.

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

Environment

• OS: macOS
• Web Server: WordPress Playground
• PHP: Playground Default
• WordPress: current version
• Browser: Chrome
• Theme: Twenty Twenty-Five
• Active Plugins: None

Actual Results

• I pasted the following code into the biographical field

  <a href="" target="_blank">Lien externe </a>
  

• The "target Blank" was preserved

• ✅ Issue resolved with patch.

Additional Notes

• See the screenshot above

[nuryko]

Test PR 7792

[nuryko]

Test Report

Hi !
Here another test from the Whodunit Contributor Day !

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

Environment

• OS: macOS
• Web Server: WordPress Playground
• PHP: Playground default
• WordPress: current version
• Browser: Arc 1.72.1 (Chromium)
• Theme: Twenty Twenty-Five
• Active Plugins: None

Actual Results

• Pasted in category description :

  <a href=“” target=“_blank”>This is a test</a>
  

• target=“_blank” preserved

• ✅ Issue resolved with patch.

Additional Notes

• See the screenshot above

I just checked the implementation and tests

LGTM 🎉

[maximemeganck]

Before testing the PR 7792

[maximemeganck]

After testing the PR 7792

[audrasjb]

Looks like we're good to go.

[ranafge]

Test Report

---

This report validates that the indicated patch addresses the issue.

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

Environment
OS: macOS
Web Server: WordPress Playground
PHP: Playground Default
WordPress: current version
Browser: Chrome
Theme: Twenty Twenty-Five
Active Plugins: None

Actual Results

---

I pasted the following code into the biographical field

<a href="" target="_blank">Lien externe </a>

The "target Blank" was preserved

---

✅ Issue resolved with patch.

---

[azaozz]

If I'm not mistaken links with target=_blank are ​not particularly good for accessibility reasons (can be disorienting for screen reader users). For that reason they should be used very sparingly, only when absolutely necessary. Should there be a warning about that for the new places they are allowed? Also, can't remember if rel=noopener is still needed for some browsers, think there was a ticket about that.

Marking this for a quick review by the accessibility team.

[audrasjb]

Hello @azaozz,

This is not about explicitly encouraging people to use such an attribute (like the block editor does within its UI without informing people that it can be a poor user experience) but mostly about allowing it in the code provided by authors (they provide directly the HTML code, here). On a bio profile field, it can make sense to allow it (see comments above).

Concerning the browser implementation:

Note: Setting target="_blank" on <a>, <area> and <form> elements implicitly provides the same rel behavior as setting rel="noopener" which does not set window.opener.

Source: ​https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/noopener

Therefore I think we are definitely good to go with the current changeset.

[audrasjb]

Let's keep the accessibility workflow keyword for now, but I'm not convinced it is directly an accessibility issue. Or if it is, let's start adding a link to target:blank best practices all over the Block Editor :)

[azaozz]

Replying to audrasjb:

This is not about explicitly encouraging people to use

Right, but target=_blank is not in the default KSES filters. I.e. there is some effort to discourage people from using it. Afaik the reason seems to be that a lot of people tend to use this incorrectly seemingly because of some old/marginal/incompetent SEO advice?

Therefore I think we are definitely good to go with the current changeset.

Right, adding of noopener was removed from WP some time ago.

Let's keep the accessibility workflow keyword for now

Sure, thought it would be nice to ping the Accessibility team for a quick opinion.

[joedolson]

Overall, I'd prefer not to allow target=_blank any more than absolutely necessary; it mostly introduced accessibility problems. However, when it comes to content creation, the reality is that we have no way of knowing how that content will be used - it's hypothetically possible it could be in a context where opening in a new tab is important.

I don't see any particularly good reason to change this, but I don't have a particularly good reason to block it on the accessibility front, either.

Removing the accessibility focus, as this doesn't impact the accessibility of anything produced directly in WordPress, only the user's content output.

[audrasjb]

Thanks for the feedback @joedolson :)

[rinkalpagdar]

Test Report

Description

This report validates whether the indicated patch works as expected.

PR tested: ​https://github.com/WordPress/wordpress-develop/pull/7792

Environment

• WordPress: 6.8-alpha-59274-src
• PHP: 8.2.25
• Server: nginx/1.27.2
• Database: mysqli (Server: 8.0.40 / Client: mysqlnd 8.2.25)
• Browser: Chrome 131.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

[azaozz]

Replying to joedolson:

I don't see any particularly good reason to change this, but I don't have a particularly good reason to block it on the accessibility front, either.

Thanks for having a look! Yea perhaps I'm overthinking this; it is up to the author/site owner to decide what they want to do and why, so there's no good reason to block it.

@martinkrcho, Thanks for the suggestion! I’ve updated the tests to use data providers accordingly.

[mikinc860]

Test Report

This report validates whether the indicated patch works as expected.
Tested Patch: ​https://github.com/WordPress/wordpress-develop/pull/7792

Environment

OS: Windows 11
Web Server: WordPress Playground
PHP: Playground Default
WordPress: current version
Browser: Chrome
Theme: Twenty Seventeen
Active Plugins: None

Actual Results

✅ Issue resolved with a patch.

[audrasjb]

In 59677:

Formatting: Preserve target="_blank" in Biographical Info and Category Description.

This changeset ensures the target="_blank" attribute is preserved when adding links in the Biographical Info and Category Description fields. Previously, this attribute was being stripped by the KSES sanitization process.

Additionally, new unit tests have been added to verify the preservation of the target="_blank" attribute in these specific contexts.

Props lovewpmu, miqrogroove, bsutcliffe, sjefen6, nofearinc, nacin, harmr, blogitsolutions, stefahn, nirajgirixd, martinkrcho, spacedmonkey, sukhendu2002, audrasjb, gaellebesson, nuryko, guillaumeturpin, maximemeganck, ranafge, azaozz, joedolson, rinkalpagdar, mikinc860.
Fixes #12056.

committed in https://core.trac.wordpress.org/changeset/59677