Gutenberg: rel="noopener noreferrer" not immediately added to the markup

[afercia]

When inserting a link, Gutenberg automatically adds a rel="noopener noreferrer" attribute, see related https://github.com/WordPress/gutenberg/pull/6316 and https://github.com/WordPress/gutenberg/pull/6028

However, the added attribute is not immediately visible in the editor markup. To reproduce:

• add a paragraph
• add some text with a link, set the option "Open in New Window" in the Link Settings.
• switch the editor to "Code Editor"
• the rel attribute is not present, markup example:

<p>This is a <a href="http://build.wordpress-develop.test/hello-world/" target="_blank">target blank</a> link.</p>

• click the Preview button
• verify in the front-end the link does have a rel="noopener noreferrer" attribute

While the attribute is correctly added in the front-end, it's not immediately visible in the editor markup. This could be potentially confusing for users.

To make it appear also in the editor markup:

• save as draft
• refresh the page
• switch to Code Editor and verify the rel attribute is there

[aduth]

This sounds like it could potentially be a bug with Code Editor / Visual Editor content sync.

Related: #9512

[gregbia]

I am having the same issue

[shindevijaykr]

this is still an issue to me. what has been fixed?

[hellerbenjamin]

I am experiencing this issue on some custom blocks as well. Has anyone found a good way to mitigate in the meantime? It seems to have started since upgrading from 4.9.9 to 5.1.1.

[luistinygod]

I am experiencing this issue on some custom blocks as well. Has anyone found a good way to mitigate in the meantime? It seems to have started since upgrading from 4.9.9 to 5.1.1.

Gutenberg automatically adds a rel="noopener noreferrer" attribute when an anchor has target="_blank". In custom blocks this causes the block to be marked as invalid after saving the post. #bug

I'm experiencing the same issue but I found a workaround:

function my_links_control( $rel, $link ) {
    return false;
}
add_filter( 'wp_targeted_link_rel', 'my_links_control', 10, 2 );

This filter is available since version 5.1.0

[holtjohnson]

I am running into issues with custom blocks having validation issues after saving the post like @luistinygod is describing. I was quite confused trying to figure out what was causing the additional rel="noreferrer" to show up and cause validation issues.

Gutenberg automatically adds a rel="noopener noreferrer" attribute when an anchor has target="_blank". In custom blocks this causes the block to be marked as invalid after saving the post. #bug

Thanks for the fix @luistinygod!

Also, @afercia would you mind moving changing this to a [bug]? This is unexpected behavior and causes validation errors. This needs to be fixed, not improved. I hope it will get the attention it needs if it's properly labeled as a bug.

[luistinygod]

@holtjohnson, in the end I'm not using the hotfix I proposed on my reply. I opted to add the attribute rel to the custom block definition, avoiding the conflict:

save: function( props ) {
        let atts = props.attributes;
        return (
          ...
                el( 'a', { href: atts.link, title: atts.title, target: '_blank', rel: 'noopener noreferrer' }, [
               ...
            )
        );
    }

I think if Gutenberg adds this rel attribute to the render then it should have a soft approach when is validating the custom block, by not causing an error.

IMHO, use the wp_targeted_link_rel workaround as a last resort fix, with a conditional if clause in order to only target the links of your custom block. WordPress automation in this case is for security reasons.

[holtjohnson]

Thanks for your additional remarks @luistinygod!

I like the functionality and agree with noopener being used by default. However, for some clients and projects I need the referrer so I can't include noreferrer. For all my custom blocks I honestly want noopener, but not noreferrer.

Ideally for me, noopener and noreferrer could be included by default without causing issues with validation and have the option to disable only noreferrer on blocks or sites where they need referrers. This would work for the majority of my clients.

[portent-andy]

I'm running into this issue as well, but am seeing that if the target attribute is defined at all, whether it is target="" or target="_blank" or target="_self", Gutenberg is automatically adding rel="noopener noreferrer" to the anchor element, thus causing validation errors.

I have a field that lets a user select if a link should be opened in a new tab/window, and so I was defining the target attribute as either empty or "_blank", but will have to manipulate it to work around this.

[spacedmonkey]

Related: #14934

[youknowriad]

I don't think I'm able to reproduce this. Can you confirm @afercia ?

[ehti]

@youknowriad it's not happening for me either for text links as of now.

But, it is still happening on image links.

1. Add a new image using the Image block
2. Click on the image, then add a link to it and enable "Open in new tab".
3. Choose the image again -> Edit as HTML.
   There will be no rel="noopener noreferrer".

Check the post on the frontend, or save/update and refresh the editor. You will find it there.