Add Opens in new Tab control into Link Preview
#53566
Conversation
getdave
added
[Type] Enhancement
|
Size Change: +2.22 kB (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
This comment was marked as resolved.
This comment was marked as resolved.
|
Excellent! That's the best solution. It basically stays as it was before and additionally has advanced options. Now yes, that solves the problem. Thank you very much for listening to users and for the work! |
|
There's potential here. The popover moving to the upper left corner is odd; not sure what's going on there. The checkbox also does not save if you edit it within that state. But if you click on the link again, it does. CleanShot.2023-08-11.at.10.17.37.mp4 |
|
And when 
|
|
That is very odd. I hadn't noticed that on my small screen. Will take a look. |
It's actually doing it in your video—moving to the top left. But it's not as noticeable at those dimensions. |
|
Compared to the previous interface, the current one is pejorative. It is no longer clear or simple and introduces additional steps, actions, and waiting time to perform required tasks. We should thoroughly investigate the reasons behind this change. What are the benefits it brings? Furthermore, we should also consider that while we frequently discuss the concept of "open in a new window" it is equally important to implement controls for the "no follow" attribute. This attribute holds significant importance in terms of SEO compliance, aligning with recent Google guidelines pertaining to sponsored links, affiliations, and similar aspects. Additionally, the checkboxes appear to represent a design evolution from the previous toggle switches. Moreover, what advantages does the anchor text field in the advanced section bring? |
|
Thanks for your questions. Usually we'd keep the feedback related to the proposal in the PR but as this relates to wider concerns I'll address some of your queries to enable you to better review this specific solution in context.
Are you referring to the UI proposed in this PR?
Can you go deeper here? It sounds a little subjective. To me the UI itself appears to be very simple when first creating a link (witness lack of other controls). It could therefore reasonably be argued that showing additional controls here would make the interface more complex. What specifically is not clear/simple in the steps shown in this PR?
There is a valid discussion to be had here. What would your proposal be? I assume it would be to show the
The work we are doing is geared towards allowing more controls such as this. However we cannot continue to expand the number of controls shown on the first step indefinitely. This is precisely the background to why we moved the Consider that other contributors may suggest other controls which - from their perspective - are equally important to them and before we know it the UI would be incredibly complex. Therefore as contributors we have to make difficult decisions to deprioritise the majority of controls to avoid overwhelming the user. Our current thinking is that whilst With the auto-saving of the expanded state of this control already merged, this seems like a reasonable compromise solution. Implementing
The checkboxes are an evolution and one that was undertaken in a deliberate manner based on user feedback. The reason checkboxes are used is because they imply a need to submit a change. We had numerous reports of confusion with the previous toggle-based interface where changes to settings would immediately cause the value to be submitted in unexpected ways. This is why we moved to a checkbox and also requiring the user to submit their changes. Obviously if we choose to pursue this PR then that distinction is less clear cut but I think it still works. Do you? If not why.
I didn't follow this. If it's not directly related to the change in this particular PR I would recommend raising a new Issue documenting any problems you've experienced. Many thanks. |
|
Re: incorrect placement of popover. This seems to be because on first render the popover's See graphic below which shows the console logging of first and then second clicks: 
Interesting when you first create a link the popover knows how to position itself correctly relative to the selection so now looking at how we loose that information once the link is created. |
|
Thanks, Dave. Your answers are greatly appreciated. I am very sorry that I discovered the new Link UI issue only after being impacted by it because I would have gladly contributed since its inception. Obviously, the choice between switches or checkboxes works well in any case, and I think you are right to favor what gives greater stability. Regarding the design and concept of the Link UI, I believe there is some reasoning to be done on the matter — reasoning that is not subjective but based on factual issues. The before-and-after comparisons, in my view, are between the old UI and the new UI. The old UI was well-designed because it did its job: inserting a link, possibly searching for an existing page and linking to it, and marking the link with the two most important tags: opening in new tab and adding the nofollow tag. While "open in new tab" is obviously used and abused even by amateur users, the latter is extremely important for anyone who understands the rudiments of SEO. Publishers, bloggers, marketers, and so on need (and it is a fundamental requirement of the Google Guidelines) to be able to add the nofollow tag very frequently — whenever there is a commercial relationship (affiliation or other) and whenever they are linking to a resource they don't fully trust. In the professional context, most links are often "nofollow", and it is also the most time-sensitive context since any additional action (click) requires more effort (and time) from the content creator. This is not a subjective matter; a simple web search or reading the Google guidelines would reveal it. The old UI also allowed the sponsored tag to be included, strictly following the new Google guidelines. However, it currently appears that nofollow and sponsored can work equally well for Google.
Coming to that, I think that's the point. A minimal interface does not equate to an easier to use interface. You're just moving vital controls elsewhere, sweeping the dust under the carpet. This, while aesthetically it looks like a simplification, has actually significantly increased the complexity of the interface.
There's no making up to say what's the best way to handle this, the old UI did it brilliantly! The reasoning made for the design of the old UI is still valid: inserting links and immediately choosing to mark them with "open in a new tab" and "no follow" are the essential controls. It's something that has always existed in WP. |
|
@elgato91 Thanks for your thoughts. To keep this PR's comments on track I'm going to recommend you/we re-post your comment on the Issue which I found which tracks the "No follow" requirement. In terms of UI design I think this discussion can continue on #50891. Thanks again for your feedback and contributing to the project. |
|
My new thinking re: this bug is that we loose the "selection" in the paragraph block when a link is submitted. That means the virtual anchor for the popover doesn't know where to "anchor" itself to. This is in contrast to:
That's why we end up with a popover in the top left corner. I don't yet know how to fix that. Ideally when the link is submitted the Update: 15th AugustMore deep diving here has revealed that the This means that the calculation to find the new anchor point based on the new One "fix" I found is to call gutenberg/packages/rich-text/src/component/use-anchor.js Lines 143 to 145 in a7327a1 The strange thing is why Given that is based on the How this doesn't happen because the event listener is deregistered by the gutenberg/packages/rich-text/src/component/use-anchor.js Lines 147 to 149 in a7327a1 |
True enough. I have seen a lot of people stating this very same point, that external links should be opened in a new tab while internal links should be opened on the same page. I do disagree, however, that opening a link in a new tab necessarily makes for a bad user experience. I believe the opposite. If I come across a link while reading a post, and if I click on it, it doesn't mean I want to close the page that I was reading. It just means I want to reference some more information related to the subject, and I can do it in another tab. |
Oh yes, John Mueller. He says one thing today and another tomorrow. In any case, you are right. I did mention that my response was mostly conjecture, but it was reasonable conjecture. Otherwise why would they have time spend on a page as a metric in Analytics? Why have bounce rate? If someone leaves immediately after clicking on an external link, they are essentially bouncing. In any case, don't know if those metrics are still there in GA4 but they were there in UA. Maybe, but this would an lackluster experience for visitors. If every link you clicked on opened a new tab, you would end up with tens of tabs in your browser window, and you can't progress through them any longer. I don't agree on this one. I believe opening in a new page is the most intuitive and usefully logical progression. If I am reading a how to article, do I want to have it closed because I have clicked on a link that's referenced in the article? I agree it shouldn't be default, but it would be great if there was an option somewhere as an example where I could be given three options 1)open all external links in a new tab or 2) open all internal links in a new tab. I could then choose to either select both or 1. Or none. |
I understand your point of view and I've thought that way too. However, the website visitor can always choose to open a link in a new tab if that is their wish, so in my opinion it is more useful to force only external links to open in a new tab so that the person doesn't leave our website. But if it's better one way or another, for this case I even think it's a little irrelevant. What matters is that the website creator can easily choose how he wants to define the links without having to do a lot of clicking. This PR solves the problem that came up with the new WP. I'm happy about it.
A few years ago I opened a ticket with this suggestion on "Trac". For reasons related to accessibility it was closed. |
|
We are in agreement. The choice should be with the writer. And it needs to be an easy one. In any case, this has been an interesting interaction. Fruitful, at least for me. Yes, this link-in-new-tab issue will mostly be solved, but what about the "this is a sponsored link" option? All these things were easily accessible before the latest WordPress. I don't use it personally but @elgato91 thinks its in common use. They are all being replaced by this link preview. The link preview has no functional use. As mentioned, I spend my days typing posts. Each time I have to click six times I am drawn here and I have to chant in my head while typing responses "this is an open source project, stay polite, these guys are doing you a favor remain polite, these guys...." Lol. I am only half kidding |
|
@TapiwaZvaks I would like to provide a clearer explanation of my consideration on nofollow, for greater clarity in any future considerations. Using "nofollow" to mark affiliate links is just one of the reasons (albeit a common one among professional bloggers) for using the nofollow tag. Actually, it should be used whenever you are linking to a source whose reputation you are not entirely certain about. This is because it offers a "safer" approach from an SEO perspective. Although today there are more granular controls not natively present in WP but easily addable (as those familiar with prevalent SEO plugins are aware, such as "rel=sponsored"), just a judicious use of "nofollow" suffices, according to the most recent Google guidelines. Returning to the core issue, these controls are commonly added by major SEO plugins, so I wouldn't fret if they aren't in core. The real concern lies in the user interface's dynamics, which have shifted and, in doing so, have deviated from their main and original purpose. Consequently, it demands more effort to utilize these controls. |
|
I consider an option "nofollow" important and should be implemented. It's best not to depend on plugins for basic things. But in this case, although important, it doesn't seem to me to be massively used, so I wouldn't be shocked if it stayed in the "Advanced" drawer. |
|
@ricjcs Try checking the code of some serious site, you might discover that "nofollow" is utilized more frequently than you realize... :) The non-use only concerns very amateur users and those who do not respect the SEO guidelines. From newspapers to professional blogs, nofollow usage is massive. In terms of importance and impact on professional user experience, I would consider these two controls to be equally important, carrying the same weight. |
|
This restores a change made in 6.3, right? Should we consider backporting this to a minor release? I'll add the label so it receives the attention to be discussed (not a confirmation that it will be backported). |
ellatrix
added
the
Backport to WP Minor Release
|
Hi @getdave , I wanted to let you know about some major issues and bugs that I've noticed with this feature. I've updated the Gutenberg plugin to 16.5 just now to test the new link preview feature and recorded this screen capture for you: bug.-.link.preview.feature.not.working.as.expected.mp4As you can see, it is not working as expected at all and has the following issues:
I've tested this many times and across different browsers and it's always the same. I am not sure whether you've already been made aware of these issues and bugs. I just wanted to take the time to provide feedback anyway. Also, I'm not familiar with Github and so I don't know if this is the correct place to provide this feedback - apologies if it isn't. Thank you! |
|
@EW0JY I have tested again with a fresh environment using WP 6.3 and Gutenberg 16.5.0 and I cannot replicate that error. |
|
@getdave Thanks for your quick reply! Well, I have no clue as to why it doesn't happen for you. As you can see in that video, the error is definitely occurring for me. I've tested it in incognito in Firefox as well as Chrome. |
|
@EW0JY To help contributors I would recommend:
If the bug still manifests then we'll be a step closer. I appreciate that's additional overhead but it's really the only way to narrow this down. If you can still replicate then it will also help if this is posted as a new Issue as that will cause it to be picked up by Triage teams and thus get more testers involved 🙏 Thanks for your help here. |
|
I was able to "almost" replicate the issue. Things work but they are a bit iffy. When I insert a link using ctrl + v, I am able to click on the checkbox and everything works fine. However, when I manually type in a link as @EW0JY did in the screenshot, things become a bit patchy. Clicking on the checkbox does nothing. However, when I click on the side and then click on the link one more time, I can see that the box is already checked. |
|
@getdave I understand, so I went through all the steps you recommended and did the following: I installed a fresh WP version without any plugins and could confirm that the link feature works as expected. So I cloned my production site and deactivated all plugins, after which the problem also disappeared. Then I reactivated each plugin one by one until the problem reoccurred. I can now definitely confirm that the problem is this: The new link feature is incompatible with the YOAST SEO plugin. That is the only plugin I have to deactivate to make the feature work as expected. I also downgraded to a previous version of the yoast plugin, but even then it didn't work. Since it's such a popular plugin and not feasible for me to stop using it, I hope that is not what you are going to suggest as a "solution". Also, due to its popularity, a ton of people will also be affected by it. Can you please install the yoast plugin, replicate the issue and make the link feature compatible with yoast? Oh, my environment is Windows 10 home, latest Firefox and Chrome versions, WP 6.3 with the latest Twenty-Twentytwo theme and Gutenberg Plugin 16.5. I hope that helps, thank you! P.S.: I've tested a bit more and was able to narrow it down to this toggle within the yoast plugin settings:
When I disable that toggle, your link preview feature works as expected. In my specific case, I think it's a viable workaround as I don't need those "additional settings" enabled - for other people, this may be different. I hope this helps, |
|
I was able to reproduce the same issue. Without the Yoast plugin it works perfectly, with Yoast activated the reported problem happens, I also tested it with Rank Math, the same thing happens. |
getdave
removed
the
Backport to WP Minor Release
|
@draganescu I can't seem to find #81960 when searching for it on Github - could you please link to it? Thanks! |
What?
Adds the ability to toggle the
Opens in new tablink setting from the preview step of the Link UI.Also keeps the Link UI open when toggling the checkbox.This has been deferred until a unrelated bug can be resolved.Why?
User feedback is that toggling this control is extremely common and should be made easier. Exposing it in the preview will enable this whilst not cluttering the initial link creation step.
How?
Add render slot into the bottom of the Link Preview component and expose the
LinkSettingscontrol there exposing only theopensInNewTabsetting.When toggled the
onChangeof the component will be called with only that value present.Testing Instructions
Opens in new tabcheckbox in the preview.Save.Testing Instructions for Keyboard
Screenshots or screencast
Screen.Capture.on.2023-08-11.at.12-58-46.mp4