I’m struggling with setting up a link control for a Gutenberg-Block. What I want to achieve is a social-icon which links to the corresponding platform, such as Facebook, insta and so on.
My markup looks like that:
<a href="#"><svg /> </a>
My setup looks like the following. First I’ve tried only to use the link-control which doesn’t gave me any output. Then I’ve tried to maybe fetch that output with an expression, which results either in a blank output or in a javascript [Object object] message. Which let’s me assume that the link-control holds more information than only the link.
As a workaround I’ve ended up using a blank input control and referenced it to use as “Attribute”, but that’s not the prettiest solution!
Is there anything I did wrong? Did anyone faced a similar issue?
One more thing regarding links: Is there any possibility to prevent Gutenberg from open that links when clicking on those icons? For example I’ve set up a fixed target=“_blank” on those icons and whenever I click them inside the editor to change something the link gets opened!
Short update: I’ve managed now to make it work. Don’t know what exactly the problem was. However there is still one more thing regarding the target attribute.
I’ve set a static target=“_blank” to my social-icons. But whenever that target is present it sends the block in recovery mode at page load. I’ve also tried to use it with controls for toggling between target _self and target _blank, but in any case the block goes in recovery mode then.
Maybe Gutenberg doesn’t like that target attribute on blocks? I’ve found that discussion here on Github (target="_blank" is causing bug on "Attempt Block Recovery" · Issue #41677 · WordPress/gutenberg · GitHub). Didn’t dive too deep into Gutenberg-React code yet, but what I think to know is that there is a render and a save function available and I have to put it into the save function, but I’m not sure if Pinegrow let’s me do that?! So how would I open a link in a new tab (preferable without that behaviour that it opens the link inside of gutenberg on click), does anyone have an idea!?
@Wolfgang.Hartl for links with _blank, WP adds rel=“noopener”. This happens after the save code is generated by the block code. As a result, save code and code stored in the post don’t match and WP displays the Block recovery notice.
One solution is to add rel="nooppener" to links with _blank in HTML project.
For dynamic target attributes (for example with Toggle), PG adds the rel if the value of the target is _blank.
Here is the code snippet with SVG icon that works ok in my tests:
The latest PG Live 6.7.2 addresses the issues mentioned in this topic. See details below and please report any issues into their respective forum topics. Note, these features are considered Beta for now.
I’m pretty sure there was another topic related to that question, but for some reason I can’t find it anymore!
The above now works pretty fine (as a short feedback), but whenever I click a link inside the block-editor it opens that Links. I think the Block-Editor normally replaces any links with another HTML-Tag or replaces the href, not sure about that, but there is some kind of prevention. Any Idea why it wouldn’t work?
I think the first forum post (which I can’t find anymore) solved that problem when using javascript-Blocks. This Block now is a PHP-Block, maybe that’s the source of the problem? I think you pushed a fix regarding to javascript-Blocks preventing links from being clicked, but maybe that fix doesn’t work for PHP-Blocks?
I’m using the “default” link-controls from the Block-Editor btw!
Hey @matjaz, that approach doesn’t seem to work any longer. I’ve just tried it on a new project (using the latest PG-Desktop Version), and my block get’s back to recovery mode again every time I use target=“_blank”.
I could add with a second toggle rel=“noopener”, but whenever I don’t use target=“_blank” the other blocks get an empty “rel” attribute which also results in a recovery mode. So in any case I have blocks in recovery mode all the time. Could you maybe check that from your end again if that still works? For some reason it doesn’t work on my end here!
Would be also glad to know if the problem described above (regarding the PHP-Blocks) can be reproduced by anyone else!!
It’s a bit annoying for my customer to always click not directly on the button but a little bit around to edit the link. As that one with the PHP-Blocks was used for a job-portal it is used very frequently…
Sorry forgot to mention, when I use rel="noopener" as a fix attribute on my “link wrapper” block it works in both cases. But I’m not sure if it is semantically correct to use a rel attribute on an internal link! too?!
@Wolfgang.Hartl just implemented this for PHP blocks as well. There, the href is set to javascript:void() in the editor.
In my tests on WP 6.1 the Toggle control for target=“_blank” still works ok. PG automatically adds rel=“noopener” and the block is ok.
What do you see in the console when WP puts blocks in recovery mode? There should be a red message with both mismatched versions of the rendered and saved code.
Hmm really weird. I’m not at the PC right now, i remember there was a (yellow) warning comparing two arrays. But I’m gonna send you a screenshot tomorrow
Hey @matjaz that’s the promised screenshot of the error.
It seems to have problems with a normal link now, just removed the fixed rel="noopener" attribute within pinegrow and added a link to the site. After refreshing the site the block is in recovery mode. However, when I use my “open in new tab” toggle it works again. Does it maybe help if I send you a copy of the project / local installation?! (referring to the topic with the splide.js loaded on every page you can maybe see whats going on there too - but i first have to double check if it doesn’t get enqueued anywhere by accident?!)
@Wolfgang.Hartl looks like the issue comes from having the target=_self on the link. WP seams to add the rel=noopener to that as well. PG only does that if the target is set to _blank.
Should we change the logic so that noopener is auto added whenever target is set?
Hmmm good question. I mean if WP adds the rel attribute by default i don’t see a problem to also do so.
The only thing I have in mind is that i thought, that rel attributes are only used for external links. But on my research i didn’t find any negative impact to have them on internal links too, so I guess it would be ok to auto add them as you mentioned!
As a proud citizen of the Republic of Austria and the associated responsibility towards beer, I have to say that “hold my beer” is usually punished with imprisonment! Always hold your beer tight or someone else will drink it!
