search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.49k stars 4.19k forks source link

Link Control: Add more controls. #23011

Open paaljoachim opened 4 years ago

paaljoachim commented 4 years ago

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. Screen Shot 2020-06-08 at 23 57 45

Hover icon. Screen Shot 2020-06-08 at 23 57 57

Opening additional options. Screen Shot 2020-06-08 at 23 58 09

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Here's an updated Figma Prototype and modified mockup.

Screen Shot 2020-06-09 at 11 47 00 AM
arnaudbroes commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Hey @shaunandrews I am going to loop you into this issue as well. As you are exploring the link control UI. https://github.com/WordPress/gutenberg/pull/28755

TeamDNK commented 3 years ago

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.

altivero commented 2 years ago

Add media link as per the following mock-up in #8322. Perhaps even an option to search for media already in the library.

paaljoachim commented 2 years ago

There has been a lot of discussion in this closed issue lately: Insert Link: consider adding an "Additional CSS Class" field to the link inserter https://github.com/WordPress/gutenberg/issues/13368

It sounds like we also need to add a Link CSS Class similar to what is done for the link control settings with images.

paaljoachim commented 2 years ago

Here is a modified link control settings initially created by @richtabor Where I also added the Link CSS Class field.

Screenshot 2022-02-22 at 13 49 27

Screenshot 2022-02-22 at 13 49 16

wpmarmite commented 2 years ago

In Elementor, the link component looks like this:

Capture d’écran 2022-09-20 à 15 42 05

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 commented 1 year ago

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 commented 1 year ago

NEED classes!!!

https://github.com/WordPress/gutenberg/issues/38878 https://github.com/WordPress/gutenberg/issues/13368

getdave commented 1 year ago

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

richtabor commented 1 year ago

CSS classes

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

pfefferle commented 1 year ago

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

See:

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

T4ngml commented 1 year ago

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:

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:

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

frogdesk commented 1 year ago

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 commented 1 year ago

This is how Yoast implemented this: image

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

jeremyfelt commented 1 year ago

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 commented 1 year ago

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

getdave commented 1 year ago

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 commented 1 year ago

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.

Screenshot 2023-03-02 at 11 37 39 PM
getdave commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

https://user-images.githubusercontent.com/118618474/222710020-770b2066-8629-40ef-8f6c-a59044f1281f.mov

richtabor commented 1 year ago

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

adamwoodnz commented 1 year ago

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 https://github.com/WordPress/gutenberg/issues/50890 didn't address adding CSS class to links unfortunately. This remains a requested feature in the support forums.

richtabor commented 1 year ago

Noting that https://github.com/WordPress/gutenberg/issues/50890 didn't address adding CSS class to links unfortunately.

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

frogdesk commented 1 year ago

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.