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 · 13 comments
Open

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

afercia opened this issue Sep 10, 2018 · 13 comments

Comments

@afercia
Copy link
Contributor

@afercia afercia 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
Copy link
Member

@aduth aduth commented Sep 10, 2018

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

Related: #9512

@gregbia
Copy link

@gregbia gregbia commented Feb 27, 2019

I am having the same issue

@shindevijaykr
Copy link

@shindevijaykr shindevijaykr commented Feb 28, 2019

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

@hellerbenjamin
Copy link

@hellerbenjamin hellerbenjamin 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
Copy link

@luistinygod luistinygod 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
Copy link

@holtjohnson holtjohnson 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 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
Copy link

@luistinygod luistinygod 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
Copy link

@holtjohnson holtjohnson 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.

@portent-andy
Copy link

@portent-andy portent-andy commented May 1, 2019

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
Copy link
Member

@spacedmonkey spacedmonkey commented May 2, 2019

Related: #14934

@youknowriad
Copy link
Contributor

@youknowriad youknowriad commented Oct 29, 2019

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

@ehti
Copy link

@ehti ehti commented Mar 24, 2020

@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.

dirkjf added a commit to greenpeace/planet4-gpnl-plugin-gutenberg-blocks that referenced this issue Nov 5, 2020
This is a workaround for a wordpress bug. See: WordPress/gutenberg#9731 for more information.
@cngodles
Copy link

@cngodles cngodles commented Jan 26, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet