Link Control: Add more controls.

[paaljoachim]

Is your feature request related to a problem? Please describe.

Many have been asking for an easier way to have additional link options.

Add easy way to modify links and add toggle options.
#17556

Add nofollow option for links
#13542

Make link selection consistent
#17293

and there are probably other associated issues.

Describe the solution you'd like

Here is one way to do so. Adding a more icon to bring in additional link options.

Added icon.

Hover icon.

Opening additional options.

I am not sure which options should be added to the more screen, but I believe it would be helpful for many that it does exist. Perhaps only adding a way for plugins to add the more option or having it directly added to Gutenberg Core.

[arnaudbroes]

We did this with AIOSEO (both toggle controls and a text field) but honestly it was a real pain to do. It would be great if the Gutenberg team added any way for plugin developers to extend the existing options with their own.

[paaljoachim]

I'll also let Dave and Marcus know about this issue...
@getdave and @mkaz
As I do think it can solve a few issues in regarding link controls.

[karmatosed]

I think it would be important to think what the reason for adding more link options is and if they are even needed. I don't believe by default more options are helpful myself. I also don't think hiding if they are useful makes sense. In this case I would suggest examining what is needed over creating another hidden area to expose options. My recommendation would be to start from the point of why is something needed?

[phpbits]

I think it would be important to think what the reason for adding more link options is and if they are even needed. I don't believe by default more options are helpful myself. I also don't think hiding if they are useful makes sense. In this case I would suggest examining what is needed over creating another hidden area to expose options. My recommendation would be to start from the point of why is something needed?

Agreed! Classic editor doesn't have these options and always been plugin territory. We've discussed this before and as I recalled we agreed on having filter/hook on the link control for developers to extend; and be able to add these features easily.

[phpbits]

We did this with AIOSEO (both toggle controls and a text field) but honestly it was a real pain to do. It would be great if the Gutenberg team added any way for plugin developers to extend the existing options with their own.

💯. To be able to make this work there's a need to create separate format and rely on custom URL popover.

@arnaudbroes Looks like you are using the one I've created for EditorsKit plugin. Would really appreciate if you can support EditorsKit ;) Thanks!

[richtabor]

Think of this more of a way for third-party plugins to add link controls here, such as a "No follow" toggle, or "Sponsored" toggle (or whatever a plugin may want to add). I'd say that if there were no additional controls added to the filter, nothing changes from how the link controls look today.

BUT, if there are additional controls added to a future filter, then the "More link controls" arrow could add those additional controls.

Sorta the best of both worlds by letting folks essentially configure their experience. I believe adding more top-level controls here would just further complicate the interface - especially if those controls are no where near the primary action (no follow for example).

[getdave]

Firstly thanks for raising this @paaljoachim. Much appreciated.

I recalled we agreed on having filter/hook on the link control for developers to extend; and be able to add these features easily.

When I originally worked on this component this was the approach we were going to take. However, I seem to recall we (I) ran out of "space" to accommodate in the PR. Apologies for this.

Could we not try the following:

1. Add the hook to afford extensibility. No harm and solves many issues.
2. Do some user research (not sure how) to see if there are any extremely common controls that would be appropriate to add as defaults. Who would do this and how are beyond my scope of expertise and knowledge.

For me, the issue is that we can't service every requirement in Core without ending up with a completely cluttered link UI. That is something we should avoid. Plugins are a good fit for many of these options IMHO.

...then the "More link controls" arrow could add those additional controls.

Yes, that would be a good approach. The component is geared up for this already. And the settings are easy to extend once we have the filters in place.

[richtabor]

Here's an updated Figma Prototype and modified mockup.

[arnaudbroes]

@arnaudbroes Looks like you are using the one I've created for EditorsKit plugin. Would really appreciate if you can support EditorsKit ;) Thanks!

That's correct, it's inspired on your great work, although we made quite a bit of changes. We also added support for the new component that was included in WP v3.4.0. Feel free to have a look at it!

[arnaudbroes]

I don't believe by default more options are helpful myself.

A"nofollow" option is quite useful though. I might be mistaken but I believe an earlier iteration of the previous default editor in WordPress had an option to add this. That's why I'm personally not fully convinced that this should be plugin territory.

I also don't think hiding if they are useful makes sense. In this case I would suggest examining what is needed over creating another hidden area to expose options.

Fully agree on this. If they're added, they shouldn't be hidden. I do understand that we want to strike a balance between extra options and UI clutter.

[arnaudbroes]

Here's an updated Figma Prototype and modified mockup.

What concerns me here is that this might not* be very intuitive for the average user if they're hidden by default, although you could argue these options are meant for more "advanced" editors.

[richtabor]

What concerns me here is that this might not* be very intuitive for the average user if they're hidden by default, although you could argue these options are meant for more "advanced" editors.

I'm not sure the everyday WordPress user would understand what a no-follow link does, though it would be nice to test for discoverability.

I'm just so hesitant on continuously adding to the current UI – its already difficult to navigate.

[jdevalk]

Relates to #16609 as well, which was closed, but which caused both AIOSEO, and Editor Kit, and us at Yoast, to build something which is really really ugly and not what we wanted to do. I'm all for calling this plugin territory as I don't think we'd implement it the same way even between those plugins, but it should be possible to do at least. So, mostly, I want this to be filterable / slot fillable.

[karmatosed]

Looping back to this, am I right that the path forward would be to have it as hooks and then consider from there if core has an interface for it (or not)? That said, this should change to hooks specifically and have a dev flag I feel, so going to do that and move it on from design feedback as the interface isn't something to be considered right now.

[maartenhunink]

Being able to add additional attributes to a link would be very useful. For some of the websites I work on this would enable me to create more advanced links. I assume this feature request is waiting for somebody to pick it up?

[paaljoachim]

Hey @shaunandrews I am going to loop you into this issue as well. As you are exploring the link control UI.
#28755

[TeamDNK]

We also need the ability to add custom attributes to the element. Toggle buttons may too limited for cases that require more than a boolean return. The block filters seem to be a great approach to extend the popover so that developers are able to add elements to it or filter the entire popover.

[wpmarmite]

In Elementor, the link component looks like this:

I don't believe that core needs to go this far as it could disturb everyday users.

However, plugin developers should be able to enhance this component (with a dedicated filter) to add link options to their users (nofollow, sponsored, add a custom class, id, or even an aria-label attribute).

[erik-visser]

Very interesting read. And I get the dilemma. I would like to add an additional argument for it that I didn't see in the comments. It's also good for IndieWeb purposes and using web standards for contextualizing links. And I think it should be in the interest of Wordpress to give a user the option to use those standards. If it should be part of the core, I don't know but adding yet another plugin to the growing collection isn't always the best option either. Thanks for all your great work people!

[frogdesk]

NEED classes!!!

#38878
#13368

[getdave]

My view is that Gutenberg should offer a sensible set of common default settings. Would this suffice?

• Open in new tab
• No follow
• CSS classes

[richtabor]

CSS classes

I'm not certain on this, but I would like more context of the use-case of adding support for this.

[pfefferle]

I think besides the styling possibilities (using CSS classes), the rel and class attribute is important to add Microformats!

See:

• https://gmpg.org/xfn/ (rel-attribute)
• https://microformats.org/wiki/h-entry#Proposed_Additions

Which is important for the IndieWeb movement: https://indieweb.org/

[T4ngml]

It's now been YEARS I pray for my redactors to be able to apply specific designs for internal and external links.

Let's get back to basics.

If we folllow the rules, only external links should, potentially, be open in new tabs.
And the very vast majority of links we might want to set as no follow is external links. Not to say we'd like to make them all no follow, but that's off topic...

Beyond that, there are some cases, where, advanced content editors sometime need to step away from these rules:

• For SEO purposes, I sometime want to add many links in a content. But finaly realize it's actually a bit too much for the reader, so sometimes want some of them not noticable
• For SEO purposes, I can also, sometimes, want to play with the no follow and new tab behaviors.

I feel like, a non-techy option, could basically be to add some logic, which applies specific classes to both internal, and external links. So that some global CSS rules could make internal and external links visually differentiable without the user's intervention... Or remain not noticable when no specific CSS styling rules are set for this.

This could be provided via:

• an "advanced options" toggle in the Inser-/edit link pop-in
• an option in WordPress settings to make them available in the pop-in
• just leave it to plugins.

What's certain though, is that in the meatime:

• non-HTML skillful users aren't able to provide a consistent styling for their links. The most zealous among them will manually apply manually, repeatedly, religiously, a set of many visual transformations, with neither hover nor responsive capabilities.
• Advanced users keep yelling at Gutenberg everytime it destroys the tiny perfect job they meticulously adjusted in the HTML editor. Then try to step back with Ctrl+Z, or versions, then yell even more
• Medium skilled developers keep delivering and maintain monkey patches, to style the content the way the user want it... with unsatifsfying results.

[frogdesk]

I just can't even fathom why you think it was a good idea to remove the ability to add classes to links in the first place.

This is used for all kinds of things, including modals, plugins that add roles or other attributes based on classes, and simply for styling purposes. Links NEED to be able to have classes, there are several issues FULL of people begging for this functionality to be returned.

[Pairfum-London]

This is how Yoast implemented this:

From a user's perspective this is easy to use.

[jeremyfelt]

Answering @richtabor's prompt specifically re: additional CSS classes

I'm not certain on this, but I would like more context of the use-case of adding support for this.

First, I agree with @pfefferle's IndieWeb point. The most immediate (most easily described? 🤔) way for people to start getting familiar with IndieWeb is by adding microformat class names directly to elements.

The block editor generally makes this a nice experience because you can assign classes like h-card, e-content, etc... to almost any container without waiting for a theme developer to fully implement microformats.

To properly markup replies, likes, bookmarks, etc... a person must be able to add u-in-reply-to, u-like-of, u-bookmark-of to the anchors linking to others' content. This is not currently possible, or a very unstable experience when switching between code/visual.

Second—and actually the real reason I'm here even though I think the IndieWeb example is more compelling...

I'm working on integrating a plugin written by a SaaS company that implements a membership login flow with their JavaScript. That JavaScript looks for specific class names on anchors.

I've created the markup for this as a template part so that the site owner can update the text surrounding those anchors, but when I open it in the template editor, I get a block validation error because there are class names on the anchor that the template editor can't handle.

I'll likely need to create a couple custom blocks for server rendered content so that I can be confident those class names will remain when this content is edited. This is probably more reliable than shimming things with JavaScript so that class names are added to those anchors before the 3rd party script runs. Even though I'm happy I have an approach to solve the problem, both of those options seem like an unnecessary amount of work for ensuring a class name is on an anchor.

Probably related: #10235, which could make it easier to implement all of this as a custom inline block.

[frogdesk]

We will be switching away from WordPress for future clients because of this.

[getdave]

As I have said previously, I believe we should look to add this feature. Once in the Plugin it can always been rejected if enough people feel strongly that it shouldn't be included.

Please bear in mind that @richtabor is entirely right to question the use case for adding new features to the editor. Doing this is an important way to ensure only features that are truly needed are included to avoid a bloated UI.

Nonetheless I appreciate the strength of feeling expressed by commenters here as well as the clear use cases.

If there isn't already let's open a dedicated Issue for adding CSS classes to the Link Control. This one is too broad.

[tomdevisser]

Is any dev actively working on this, and if not, what needs to be done? It shouldn't be that hard to add a nofollow toggle here right? I can try to add it tomorrow and submit a PR. Would at least fix part of this issue.

[getdave]

Is any dev actively working on this, and if not, what needs to be done? It shouldn't be that hard to add a nofollow toggle here right? I can try to add it tomorrow and submit a PR. Would at least fix part of this issue.

I'm not aware of anyone actively working on adding more controls at this point. However, I have been working to revise the UI/UX to prepare the ground for adding more controls as one of the main objections in the past is that it would add too much noise to the UI.

Now I've added a settings "drawer" it will be easier to add more controls such as you suggest.

I was planning on circling back to this once WP 6.2 is launched as currently it's an extremely busy period for contributors.

It shouldn't be that hard to add a nofollow toggle here right?

It would be great to receive a PR from you. Thank you! This is however more than simply adding the toggle. You will then need to ensure that the resulting data is persisted in every instance where the toggle is used.

[tomdevisser]

It would be great to receive a PR from you. Thank you! This is however more than simply adding the toggle. You will then need to ensure that the resulting data is persisted in every instance where the toggle is used.

@getdave True, might underestimate it, but I'll take a shot. Will let you know if it's out of my league at the time being. Thanks!

[tomdevisser]

First PR is up now. Not complete, but we're getting closer. Let's move this discussion to the PR #48722

nofollow.mov

[richtabor]

I'm leading a proposal to clean-up the experience of editing links in #50890 which will make further link settings (i.e. potential no-follow and css class functionality) much more feasible. Would appreciate a look.

[adamwoodnz]

I'm leading a proposal to clean-up the experience of editing links in #50890 which will make further link settings (i.e. potential no-follow and css class functionality) much more feasible. Would appreciate a look.

Noting that #50890 didn't address adding CSS class to links unfortunately. This remains a requested feature in the support forums.

[richtabor]

Noting that #50890 didn't address adding CSS class to links unfortunately.

Correct, that UX provides an affordance for adding additional controls. :)

[frogdesk]

Is there some kind of misconception that this is a requested feature? Incorrect, this is a breaking regression that should be considered an urgent bug fix. There was a working function to add classes to links previously and it was removed, completely breaking existing workflows.