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

[afercia]

When inserting a link, Gutenberg automatically adds a rel="noopener noreferrer" attribute, see related #6316 and #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 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.

[cngodles]

Still a frustrating error for me. I made a block that creates a custom link button, which has large and medium sized text within. Basically, not something you can make with regular blocks. Every time I would save and reload, I would come back to the page with a dozen validation warnings (Having placed a dozen blocks on the page). I think the problem could be solved in three different ways.

1. Is there was a way to soft validate these as @luistinygod suggested? Likely difficult, if the validation is a pure 1:1 HTML comparison.
2. If the rel attribute was added automatically during save and not on page load, pre-validation which is seems to do.
3. If there was a published way to determine the logic for a link for a given URL, so that we could write out of the rel attribute properly within the save method. Something where you feed a URL into a function and it returns the same attribute the backend is returning. I tried logic that determines if the user opens it in a new tab, however users can set external links that don't open in a new tab.

Currently, my only way to go is to disable the feature using the wp_targeted_link_rel filter.

[tyrann0us]

Hi @youknowriad,
any chance to have another look at this issue? We are facing the exact same issue: Having to also add the rel attribute when adding the target attribute. Not a big deal, but annoying still.

The solutions suggested by @cngodles and others seem to be useful; would be great to see them incorporated. Thanks!

[youknowriad]

@tyrann0us I've opened #39319 to add the "rel" automatically in the image block like it's done in other blocks. That said, this is not going to avoid the invalidation issues for third-party blocks, the only solution for that is to do what @luistinygod suggest here #9731 (comment)

Basically, everytime a block adds a target="_blank" to the markup, it should also add the rel="noopener noreferrer" because that's a good practice that WordPress enforces through a server side filter.