Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to extend the link popup overlay #11599

Open
mircian opened this issue Nov 7, 2018 · 20 comments
Open

No way to extend the link popup overlay #11599

mircian opened this issue Nov 7, 2018 · 20 comments
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience Needs Dev Ready for, and needs developer efforts [Package] Format library /packages/format-library [Type] Enhancement A suggestion for improvement.
Milestone

Comments

@mircian
Copy link

mircian commented Nov 7, 2018

Describe the bug
There is no way for plugin authors to extend the link popup overlay options presented (regression from TinyMCE). This is a particularly important regression, as WordPress Core removed several options from the link editor in recent years to streamline the editing process, relying on a plugins to restore these features using the hooks available.

Additionally the classic editor, plugin authors can extend the link options presented in the overlay to add custom attributes and other link settings, such as this one. While WordPress shouldn't necessarily consider expanding the link options it provides with Gutenberg, it should allow plugins to extend those link options to support new options and provide backwards compatibility for WordPress Core removed features.

This would likely require filters be added to gutenberg/packages/format-library/src/link/inline.js.

@chriscct7
Copy link
Member

This limitation of Gutenberg also will prevent a lot of plugins from being able to update to support it and as mentioned causes a regression for those using plugins to support the old WordPress attribute behaviors.

There are a lot of really common attributes that various plugins add to links via the existing editor's link options including the ability to toggle on the download attribute for download links, nofollow on links, and so forth.

Gutenberg should provide parity in hooks here, for display of additional settings, the application of those attributes on changes, and saving of them. Basically there's just hooks needed, with a dedicated slot for plugins to add their settings onto.

Related tickets, many of which would be solved directly by the resolution of this ticket or indirectly by allowing for plugins to be easily made for them include: #10226, #4499, #4597, #11484, #2474, #11471, #11440, #10225, #8711, and #6392

@designsimply designsimply added Needs Technical Feedback Needs testing from a developer perspective. [Type] Enhancement A suggestion for improvement. [Feature] Extensibility The ability to extend blocks or the editing experience Needs Decision Needs a decision to be actionable or relevant and removed Needs Technical Feedback Needs testing from a developer perspective. labels Nov 7, 2018
@pipdig
Copy link

pipdig commented Nov 11, 2018

+1 for this. We regularly ask clients for feedback on their Gutenberg experience and ~90% of the responses mention a lack of nofollow or ability to add a rel attribute to links easily.

"I'm finding Gutenburg ok actually. It took me a bit of time to get the hang of it though the idea of blocks is something I worked with when I was on Squarespace. One thing I've realised though is my 'rel-nofollow' plugin won't work with it which is a nuisance and I'm not sure of a solution. I can't code so wouldn't be messing with HTML. Apart from that I'm fine with it."

We've been trying to raise this issue for months now but there hasn't been any traction. If there was a standardized way to extend the link popup we could quickly solve issues such as #4597 and #4499 as well as others mentioned by chriscct7 above.

@blogtutor
Copy link

+1 from me too. Most of my clients use affiliate links, and they need the ability to make links "nofollow" in order to stay compliant with Google policy. (Most of my clients would be unwilling or unable to edit the HTML manually to add the rel='nofollow' tag). This alone is reason enough for them to avoid using Gutenberg.

@ghost
Copy link

ghost commented Dec 2, 2018

I agree and there are other relevant reasons such as the need to include aria-label or title attributes for accessibility of screen readers or what if you simply wanted to be able to easily add a class name to a link.

@syedbalkhi
Copy link

Just switched to the Gutenberg Editor on my blog, and this is an extremely important feature that's missing. Sure there's a way to do a short-term JS hack, but I feel that this needs to be done in Gutenberg core.

@budgetsavvybride
Copy link

Totally agree with and echo the above comments that this feature is 100% necessary and it baffles me that it isn't included in the core features of Gutenberg. The ability to add nofollow to button links is a necessary feature to include as well.

@chriscct7
Copy link
Member

With https://webmasters.googleblog.com/2019/09/evolving-nofollow-new-ways-to-identify.html, even more reason for this, as plugins could add these types of options easily

@thatdevgirl
Copy link

I would like to add a +1 to adding at least an aria-label attribute to the link creation UI for accessibility purposes. It would be very useful in cases where the same link text (i.e. the dreaded "Read more") is on the same page multiple times going to different locations.

@noisysocks noisysocks removed the Needs Decision Needs a decision to be actionable or relevant label Nov 24, 2020
@noisysocks
Copy link
Member

This was also requested here: https://core.trac.wordpress.org/ticket/41047

I think it's a good idea. Perhaps we can look at adding a slot here cc. @gziolo.

@noisysocks noisysocks added this to the WordPress 5.x milestone Nov 24, 2020
@gziolo
Copy link
Member

gziolo commented Nov 26, 2020

There was an attempt from @xyfi to address it in #13190.

I don't know what's the current status of this component as it's quite complex and it was refactored several times.

Looking at the code, this where the popup is rendered, whatever type of extensibility it would take, it would require passing onChangeLink so changes could be applied to the link:

<Popover
key={ mountingKey }
anchorRef={ anchorRef }
focusOnMount={ addingLink ? 'firstElement' : false }
onClose={ stopAddingLink }
position="bottom center"
>
<LinkControl
value={ linkValue }
onChange={ onChangeLink }
forceIsEditingLink={ addingLink }
/>
</Popover>
);
}

There is also this question, whether it's fine to add those extensions next to LinkControl component or integrate with its API. This component is very complex, see: https://github.com/WordPress/gutenberg/tree/master/packages/block-editor/src/components/link-control

Given that all that would need to change the formatting control registered registerFormatType, it's hard to tell what would be the best way to approach it. @ellatrix, do you have any thoughts on how to best approach it? I assume that we would need to come up with something general, as folks might want to have an option to inject HTML attributes inside other HTML tags applied with the rest of the existing formatting controls.

@noisysocks noisysocks added the Needs Dev Ready for, and needs developer efforts label Dec 8, 2020
@JPBelley
Copy link

JPBelley commented Feb 2, 2021

Would like to add a +1, there's a lot of important attributes that can be added to the a tag

comzeradd added a commit to greenpeace/planet4-plugin-gutenberg-blocks that referenced this issue Jun 10, 2021
Ref: https://jira.greenpeace.org/browse/PLANET-6172

---

Most of the blocks have a title and a description. This changes removes
formatting options from title and adds them on description. For now this
is just bold and italic. Links are still [not supported properly from
WP](WordPress/gutenberg#11599).

Used `allowedFormats` everywhere, instead of `formattingControls`, for
consistency but also because `formattingControls` is [being
deprecated](https://github.com/WordPress/gutenberg/blob/641f1c70af8ffd466b4adf20b29e7a4a839fc1e8/packages/block-editor/CHANGELOG.md#new-features-2).

Additionally we add these rules on specific blocks:

**Accordion**

Headline: Disallow
Text: Allow

**Carousel Header**

Disallow everywhere

**Columns**

Column Header: Disallow
Column Description: Allow

**Cookies**

Cookie name: Disallow
Cookie description: Allow
comzeradd added a commit to greenpeace/planet4-plugin-gutenberg-blocks that referenced this issue Jun 10, 2021
…elds

Ref: https://jira.greenpeace.org/browse/PLANET-6172

---

Most of the blocks have a title and a description. This changes removes
formatting options from title and adds them on description. For now this
is just bold and italic. Links are still [not supported properly from
WP](WordPress/gutenberg#11599).

Used `allowedFormats` everywhere, instead of `formattingControls`, for
consistency but also because `formattingControls` is [being
deprecated](https://github.com/WordPress/gutenberg/blob/641f1c70af8ffd466b4adf20b29e7a4a839fc1e8/packages/block-editor/CHANGELOG.md#new-features-2).

Additionally we add these rules on specific blocks:

**Accordion**

Headline: Disallow
Text: Allow

**Carousel Header**

Disallow everywhere

**Columns**

Column Header: Disallow
Column Description: Allow

**Cookies**

Cookie name: Disallow
Cookie description: Allow
comzeradd added a commit to greenpeace/planet4-plugin-gutenberg-blocks that referenced this issue Jun 10, 2021
…elds

Ref: https://jira.greenpeace.org/browse/PLANET-6172

---

Most of the blocks have a title and a description. This changes removes
formatting options from title and adds them on description. For now this
is just bold and italic. Links are still [not supported properly from
WP](WordPress/gutenberg#11599).

Used `allowedFormats` everywhere, instead of `formattingControls`, for
consistency but also because `formattingControls` is [being
deprecated](https://github.com/WordPress/gutenberg/blob/641f1c70af8ffd466b4adf20b29e7a4a839fc1e8/packages/block-editor/CHANGELOG.md#new-features-2).

Additionally we add these rules on specific blocks:

**Accordion**

Headline: Disallow
Text: Allow

**Carousel Header**

Disallow everywhere

**Columns**

Column Header: Disallow
Column Description: Allow

**Cookies**

Cookie name: Disallow
Cookie description: Allow
@mbolis
Copy link

mbolis commented Jul 28, 2023

+1 this too.
It's been years now, what's the status of this issue?

@james-s-k
Copy link

Just floating this one to the top as it is really affecting the accessibility score on Google PageSpeed Insights.

We need something so that links have a discernible name please.

Thanks

@sammyaxe
Copy link

def needed

@gravnetic
Copy link

gravnetic commented Oct 24, 2023

I am working on moving a classic site to the block editor and there are many quality of life publishing options missing.

This issue is required in my opinion. The link dialog currently requires adding the link and than going back, clicking on it to open the option to add a external designation. It doesn't make sense that a link experience would weight toward internal links.

Hard Fail IMHO.

@Twansparant
Copy link

5 years later and this is still not possible? I really need to add aria-labels to my content links…

@bugnumber9
Copy link

It's really frustrating not to have this in 2024... Custom attributes is one of the most used features.

@veerap000
Copy link

+1 for extendibility, opens a tons of possibilities

@gr1zix
Copy link

gr1zix commented Feb 27, 2024

+1. Would be great if you added at least Slots to extend existing components. Thanks

@DenisDoroshchuk
Copy link

+1 I just need to default to opening all links in a new window. Is there an approximate timeline for the implementation of this feature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Extensibility The ability to extend blocks or the editing experience Needs Dev Ready for, and needs developer efforts [Package] Format library /packages/format-library [Type] Enhancement A suggestion for improvement.
Projects
Development

No branches or pull requests