Expose target type, selection handler and selection settings in LinkWidget

How about something like that?
Link Field setting forms.

Link Field widget.

Now we need the selection handler and its settings.

Where in the link field settings form? We have to use ajax for that.

I haven't tested it after saving the field but selection handler is now loaded using ajax.

Updated Link field widget as well.

+++ b/core/modules/link/src/Plugin/Field/FieldType/LinkItem.php
@@ -104,6 +108,100 @@ public function fieldSettingsForm(array $form, FormStateInterface $form_state) {
+        '#required' => TRUE,

We have to toggle this and target_bundles required to FALSE when $element['selection'] is hidden to submit the form in chrome. See https://code.google.com/p/chromium/issues/detail?id=45804 and http://stackoverflow.com/a/12486761.

Here is a workaround for #8.

Just simple re-roll.

Replace Utility/String with Utility/SafeMarkup

Is there anything left to do on this issue? I was thinking about implementing a new link field with this functionality but would gladly help to get it into core as son as possible instead.

I think this would have to happen in 8.1 since it changes the UI.

Needs Tests as well.

I'll look into this when i get the time. I'll probably create a separate module with a new field in the meantime for my own needs and then attempt to port this functionality back into core if no one else has done it already.

Just cross-posting a solution to this problem from 2423093 which isn't ready for core, but supports multiple entity types.

It relies on a patch, plus a sandbox for half-working mutli-entity autocomplete options: https://www.drupal.org/sandbox/sam/2881047.

Needs quite a bit of tidy-up, but a workable solution if anyone needs it.

I have hundreds of generated nodes which clog up the suggestions, making the autocomplete useless (can't ever choose any internal link because the 10 shown are always one of the generated ones). Would be nice to have the option to limit on content type.

The selection handler settings allow you limit by bundle.

Are you saying that's currently in core?

Nope, sorry. Only that it's currently supported by both patches in this issue.

Re-rolling patch from #15.

I'm not sure how the patch ever worked, since

$uri = 'entity:'. self::getFieldSetting('target_type') .'/' . $entity_id;

is using a static call to getFieldSetting, which isn't a static function.

@ryanissamson
You can call self::methodName() to call the current classes implementation of a method. [php.net]

Was unable to apply this against 8.6.2. There was a missing dangling comma inside `src/Plugin/Field/FieldType/LinkItem.php` around line 36.

This patch applies cleanly to 8.6.2.

I also fixed as issue where existing link fields would crash since there was no `handler` specified on the field settings. Looking through others it seems the string `default` was an acceptable value to default to if there was no handler specified.

Seems the self::getFieldSetting('target_type') does actually throw an exception on PHP 7.2.

Error: Using $this when not in object context in Drupal\Core\Field\WidgetBase::getFieldSetting()

#37 causes crashes for existing fields because the parameter is not yet set:

Missing required #target_type parameter.

This new patch adds a fallback on node.

patch #42 Failed to apply re-roll the patch

Rerolled #45

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I tried to reroll the #49 patch for 9.5.9 but the field settings form was not working correctly: settings were not saved and AJAX requests did nothing.
I reworked the patch and now everything seems to work on my setup.
Unfortunately, I had to duplicate some methods from EntityReferenceItem.

(I tried to generate an interdiff but it fails for some reason.)

#53 was causing errors with existing fields, it should be better now.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Tried to fix failures in #54.

Just noticed it triggers an exception in the widget when the target_type setting is empty.
I updated the patch to fix that.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

LinkWidget tries to call getFieldSetting statically and it can't work.

Fixed a notice when handler_settings is NULL.

Was previously tagged for tests which I believe are still needed.

And with the schema change an upgrade path may be needed.

But also there seemed to be some failures.

#60 was using the new node handler by default instead of keeping the old behavior.
The new handler should be opt-in.

Reroll for Drupal 10.2.5.