Link settings extensibility

[abotteram]

Description

Adds the possibility to expand the inline link settings via Slot/Fill and alter the link's attributes.

To achieve this I had to refactor the logic that determined the link's attributes because the only possibility was to change the link to an external link.

While working on this I found out that the aria-label logic is broken. The label will always be (opens in new window).

How has this been tested?

Add the NoFollowToggleWrapper somewhere in your code and make sure the component is always rendered. I simply copied it into packages/format-library/src/inline.js.

class NoFollowToggle extends Component {
	isChecked() {
		const { rel } = this.props.attributes;

		if ( ! rel ) {
			return false;
		}

		return rel.split( ' ' ).includes( 'nofollow' );
	}

	toggle() {
		const { setLinkAttributes, attributes } = this.props;

		const rel = attributes.rel;

		if ( this.isChecked() ) {
			if ( ! rel ) {
				return;
			}

			const newRel = rel.split( ' ' ).filter( ( relItem ) => {
				return relItem !== 'nofollow';
			} ).join( ' ' );

			setLinkAttributes( {
				...attributes,
				rel: newRel,
			} );
			return;
		}

		if ( ! rel ) {
			setLinkAttributes( {
				...attributes,
				rel: 'nofollow',
			} );
		} else {
			setLinkAttributes( {
				...attributes,
				rel: [ rel, 'nofollow' ].join( ' ' ),
			} );
		}
	}

	render() {
		return (
			<ToggleControl
				label={ 'No Follow' }
				checked={ this.isChecked() }
				onChange={ this.toggle.bind( this ) }
			/>
		);
	}
}

function NoFollowToggleWrapper() {
	return (
		<Fill name="LinkSettings">
			{ ( props ) => {
				return <NoFollowToggle { ...props } />;
			} }
		</Fill>
	);
}

Screenshots

Types of changes

New feature.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[Chrico]

Howdy,

any news here about the state or if something is missing? Is there already a scheudule when this will be included into Gutenberg? Currently there are a lot of options which could be possible be added to the LinkSettings to support e.G. custom data-attributes for tracking or even kind of theming to open modals.

[Soean]

@xyfi Can you add the No Follow example to the docs?

[designsimply]

Noting a related discussion from the #core-editor meeting in WP Slack today: https://wordpress.slack.com/archives/C02QB2JS7/p1547046547434300

[mcsf]

While working on this I found out that the aria-label logic is broken. The label will always be (opens in new window).

See #12325

[GlennMartin1]

+1 to have this feature ASAP.

Any ETA? 5.1?

[mapk]

I'd like to point to #10128 in an effort to keep the styling and interaction consistent. This is what that interaction looks like.

[gziolo]

I'd like to point to #10128 in an effort to keep the styling and interaction consistent. This is what that interaction looks like.

This makes me wonder whether we should include more options it in the core by default without adding the overhead of slots and fills. Maybe we should add more options under 3 dots menu based on this PR and Button block. In particular, in the case of the Button block, these Link Settings sections feel super disconnected from the UI. We should think about the flow when someone has to use the keyboard to set link rel after providing url. I think it would be super annoying to tab as much to edit related settings.

[chriscct7]

This makes me wonder whether we should include more options it in the core by default without adding the overhead of slots and fills.

There are a lot of options that could/should be there. Some of those are documented on #11599

For example:

• nofollow links
• open in new tab option
• download attribute (for download links)
• ability for plugins to add additional items as relevant (for example if you had a plugin that let you add tags like rel="friend" and things like that

I agree that core should likely add the first 3 as defaults, but a slot definitely seems like the way to solve this for the long term, and notably the lack of extensibility in this space is a huge regression from classic editor to Gutenberg

[Chrico]

For me this is the wrong point to add this specific feature. It should be abstracted into a "general thing", which is re-used accross all Components which can have HTML-attributes [1].

This gernalized implementation should allow to add/remove key/value pairs (value could be maybe even a "selection of predefined allowed values"). Also blacklisting "core"-attributes (not changeable) - like on the Link-Component the href - should be possible.

---

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes

[TwisterMc]

FYI: There's a plugin called EditorsKit that you can install and get nofollow functionality today. Not sure how they're doing it, but you can try it today.

[mcsf]

The Link UI has evolved a lot since this PR was in active development. What is the status of the PR?

[draganescu]

@xyfi considering that now the linking mechanism evolved into using LinkControl I will close this PR, since given the comments there is not a definitive path ahead and also even if it were the component to update is a completely new one. Thanks for the work it still remains valuable. I would consider opening an issue about how this extensibility should work? ( cc @Chrico )