Gutenberg: rel="noopener noreferrer" is automatically added to my block, breaking validation

[jakeparis]

Describe the bug
Since WordPress 5.1, in my custom slideshow block, all my link tags are getting an added attribute rel="noopener noreferrer" at editor-load, causing it to fail block validation.

Expected behavior
My block should validate just as it has in WP 5.0

Actual behavior
When the editor attempts to load my post's saved representation, it adds the attributes to the link tags first, then validates. The block then fails to validate because the rel attribute isn't in the saved block's representation.

[fabiankaegy]

I also experienced this problem.

I understand that this is a valid security concern and that it's very important to add these. But having that break the validation of custom blocks doesn't seem to be the best user experience.

[jakeparis]

I filed a bug about this on Trac. The issue is that when WordPress sees a target attribute on a link, it adds the rel attribute, but the block editor no longer validates it.

The actual bug (in my case) is that my block had a data-target="" attribute, but the regex WP core is using to add the rel attribute is picking that up in error.

But I still think it's a bug in the block editor that it no longer validates because of the rel attribute added behind the scenes.

[Horttcore]

I got this problem very often with custom blocks, the reasons are very different from block to block.

[maximebj]

Here is how we fixed it :

On my custom Button I have an attribute isBlank that allow me to add a target blank. I just added the same check for the rel attribute :

<a
            href={ url }
            target={isBlank && '_blank'} // Initial test
            rel={isBlank && 'noopener noreferrer'}  // Add this to fix
            className={ classnames( 'button', `button--${buttonClass}` ) }
            data-type={ buttonClass }
>

But yeah, this new feature broke retrocompatibility.

[TwisterMc]

@maximebj , your code worked great. However, what do you mean by "this new feature broke retrocompatibility."

[maximebj]

When developping a custom block, if you change the save markup, the parser will not understand and display an error blocks.min.js?ver=6.2.5:2 Block validation: Block validation failed for...
It's the same thing here. If you use a link, the rel attribute will be automatically added and the block parser will fire the error.

So it worked well, and when the team pushed the new feature, error appeared. WP should not break anything when adding a new feature (a mantra for a long time ago).

[loratov]

I need the ability to add different options to the rel attribute in my custom blocks while setting the target attribute as well but this feature prevents me from doing so. It keeps overriding whatever I set in the rel attribute.

[llemurya]

I have the same problem, block validation error, I want to set the relattribute for my block but the Gutenberg inject the rel if the target is _blankand broke the markup match between the save method and content from post body. @youknowriad is any hook that can filter the second parameter from deepFilterHTML function, to remove the phrasingContentReducercallback that add relattribute. Thanks a lot.

[rodrigodagostino]

Has anybody found a workaround for this? :S I thought I was doing something wrong until I realised that WP was forcing that into the save portion of my block.

[StefanXhunga]

Hi All,
thank you for your contribution.