Stop adding rel=noreferrer to links that open in a new tab

[wpjames]

I am on WP version 5.5.3 and I have added the following code to my child theme functions.php.

function my_targeted_link_rel($rel_values) {
 	return 'noopener';
}
add_filter('wp_targeted_link_rel', 'my_targeted_link_rel',999);

However, Gutenberg is still adding noreferrer when I create a new link that opens in a new tab. Where is this coming from?

I don't think it's necessary to hard code rel attributes into the link module. Just let wp_targeted_link_rel add the necessary rel attributes when the post is saved/updated.

[SergeyBiryukov]

It's worth noting that WordPress core has removed noreferrer from wp_targeted_link_rel() and other uses in version 5.6, see https://core.trac.wordpress.org/changeset/49215 and https://core.trac.wordpress.org/ticket/49558 for more details.

The same change should probably be implemented in Gutenberg too.

[talldan]

However, Gutenberg is still adding noreferrer when I create a new link that opens in a new tab. Where is this coming from?

@wpjames The block editor adds the 'noreferrer noopener' values for any links, but it doesn't use the value from wp_targeted_link_rel.

Potentially it could do, though it may cause issues with block validation, so it might not be as simple as hooking the editor into wp_targeted_link_rel.

Probably a good first step would be removing noreferrer from the editor's hardcoded value.

[pablinos]

Probably a good first step would be removing noreferrer from the editor's hardcoded value.

Wouldn't that also invalidate blocks? Are you thinking that we pick a new value and stick to it rather than having it change based on a global setting? I think we'd still have to create migrations, but the rendered output would be consistent.

Is there a way we can cope with block output changing based on a global setting like that? If someone changes the default thumbnail image size, for example, I could see that affecting block output. I realise this would break the concept of the save function being pure. Perhaps it's a special type of attribute, where the rendered content can be compared with a default value and presumed to be valid if they match.

[adamsilverstein]

I tested stopping adding noreferrer in #26968. Tested with a few basic blocks with external links (needs way more testing):

• Existing external links still included noreferrer.
• New links did not include noreferrer (only noopener).
• I did not encounter any block validation issues.

I encounter a linting error when trying to commit the changes, we will need to remove or exclude this linting check if we want to make this change:

error  Using target="_blank" without rel="noreferrer" is a security risk: see https://html.spec.whatwg.org/multipage/links.html#link-type-noopener  react/jsx-no-target-blank

[talldan]

I encounter a linting error when trying to commit the changes, we will need to remove or exclude this linting check if we want to make this change:

@adamsilverstein Looks like we can use the allowReferrer option on this rule:
https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-target-blank.md#rule-options

I think an option would have to be added to the config here:
https://github.com/WordPress/gutenberg/blob/master/packages/eslint-plugin/configs/react.js#L9-L33

Wouldn't that also invalidate blocks?

Yep, testing #26968 it looks like the file block needs a deprecation.

The button and image block only use noreferrer noopener as a default value. Button and image blocks already in posts will keep the value noreferrer noopener, while newly added blocks will only have noopener. I think this is probably ok. What do others think?

The file block hardcodes noreferrer noopener into its save output so needs a deprecation. Other blocks are dynamic so won't have validation issues.

[isaumya]

Hi @talldan,
Any update on the matter? Also, I don't think it would be a good idea to keep the old links with noreferer noopener and then the new links will only have noopener.

The reason behind this is if there is no migration to automatically change the old links from noreferer noopener to just noopener then people will still use codes like:

add_filter( 'the_content', static function($content) { 
  $replace = array(" noreferrer" => "" ,"noreferrer " => "");
  $new_content = strtr($content, $replace);
  return $new_content;
 }, 99 );

To get rid of the noreferrer from the links and then this new fix will have no meaning as people will already be using a slow code that checks and update the content. The goal would be to make sure people don't have to use codes like these even for the existing links in the site.

[talldan]

@isaumya No update from me. I'm not assigned to this issue.

[isaumya]

Sorry. Hey, @adamsilverstein any update on this issue?

[Hastibe]

Is there a solution to this, yet? Having "noreferrer" automatically being added to links that open in new tabs is problematic.

[tomtolkien]

Is there any update on this issue? It's making using WordPress blocks for affiliate marketing very problematic.

Also, the code mentioned earlier no longer provides a workaround for the issue.

add_filter( 'the_content', static function($content) { 
  $replace = array(" noreferrer" => "" ,"noreferrer " => "");
  $new_content = strtr($content, $replace);
  return $new_content;
 }, 99 );

[isaumya]

Also, the code mentioned earlier no longer provides a workaround for the issue.

I am still using that code and it's working without any issue whatsoever. Here is a screenshot:

And this is still working like charm for me. I will keep using this until these bugs are fixed in Gutenberg.

[vitalytennant]

via ticket 54410

Hello,

Thank you for your response.

Code doesn't work.

//Removes noreferrer from new or updated posts
function my_targeted_link_rel($rel_values) {
return 'noopener';
}
add_filter('wp_targeted_link_rel', 'my_targeted_link_rel',999);

Aforementioned github reference does not address rel=”noopener”

There needs to be a permanent solution, because anyone can add rel=”noreferrer noopener” if they'd like, not the other way around.

This can be further elaborated via https://core.trac.wordpress.org/ticket/59333#ticket

"This impacts the entire wordpress opensource, and should be addressed respectively, and enhanced with either WP plugin, and/or the next WP update."

Everyone (without going into intricacies of everything) has links on their wordpress websites, this impacts everyone.

[adamsilverstein]

Just a couple of things remaining for this which I noted in a comment on #26968