Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
afercia opened this Issue Sep 10, 2018 · 8 comments

Comments

Projects
None yet
7 participants
@afercia
Copy link
Contributor

commented Sep 10, 2018

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 comment has been minimized.

Copy link
Member

commented Sep 10, 2018

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

Related: #9512

@johngodley johngodley referenced this issue Sep 21, 2018

Closed

Pass ‘rel’ tag to richtext links #10095

0 of 4 tasks complete
@gregbia

This comment has been minimized.

Copy link

commented Feb 27, 2019

I am having the same issue

@shindevijaykr

This comment has been minimized.

Copy link

commented Feb 28, 2019

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

@hellerbenjamin

This comment has been minimized.

Copy link

commented Mar 20, 2019

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

This comment has been minimized.

Copy link

commented Mar 21, 2019

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

This comment has been minimized.

Copy link

commented Mar 25, 2019

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

This comment has been minimized.

Copy link

commented Mar 25, 2019

@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

This comment has been minimized.

Copy link

commented Mar 25, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.