🇧🇪Belgium @rp7

rp7 → created an issue.

This patch applies to the current 3.0.x branch.

rp7 → created an issue.

This is a duplicate of 📌 Automated Drupal 11 compatibility fixes for linkit_entity_browser Needs review .

rp7 → created an issue.

I tested the merge request and can confirm that it does remove the AJAX throbber.

Re-rolled to latest 3.x version + tiny fix )error messages that contain HTML weren''t displayed correctly).

Are you by any chance using the views_bulk_operations and administerusersbyrole modules? If so, see 🐛 Undefined array key "id" in content_moderation_action_info_alter Active .

Looks like a duplicate was created @ 🐛 Missing license URL Fixed and the same fix got committed there. This can be closed. Thanks!

@kle (#3)
I don't understand our comment. The code you suggested is nearly identical to what's in the patch or am I missing something?

Looks like this is already fixed in the 2.x version. Thanks for the effort.

Committed. Thanks!

Thank you! Committed.

rp7 → made their first commit to this issue’s fork.

Re-rolled the patch against current 8.x-1.x.

The original patch seemed to incorrectly remove the "visual_inline" layout. Tried to fix that.

FYI, this code was reverted again. Apparently it relied on work being done @ 🐛 Make the moderation control form an entity form so that it validates entities before save Needs work .

It's being added again in ✨ Make compatible with moderation control entity form Active .

Added a fix - primarily based on the work done @ https://www.drupal.org/project/content_moderation_info_block/issues/3263... → .

I see the proposed code also contains changes related to 🐛 State Form Error RTBC .

I suggest we first fix 🐛 State Form Error RTBC before getting this in.

Looks like this same issue was also raised in #3263108: ContentModerationInfoBlockForm - Fatal Error → .

I see what's going on here. Apparently I've been developing this against the patch @ 🐛 Make the moderation control form an entity form so that it validates entities before save Needs work .

I will need to look deeper into a way forward.

Looks like this is a duplicate of 🐛 State Form Error RTBC . Let's progress in there.

Ok, I see what's going on here. Apparently I've been developing this against the patch @ 🐛 Make the moderation control form an entity form so that it validates entities before save Needs work .
I will need to look deeper into a way forward.

I found another issue by the way, but this is something that should be fixed in the Dynamic Entity Reference module.

I upgraded to Linkchecker 2.1.x (with the Dynamic Entity Reference field removed), and was receiving fatal errors about queries trying to write to the entity_id__target_id_int column in the linkcheckerlink table. Appears DER doesn't (always) automatically remove its database triggers. See 📌 Fix IntColumnHandler::delete Active for more info and a potential fix.

@jospeh.olstad

not sure I understand what that is

For example: you have a link field on content type Article. You enable linkchecker for that particular field. On the linkchecker broken links report (view), you also want to display the article's title besides each checked link. For that, in Views, you'll need a relationship from the linkchecker link entity table to the node table. The ability to add this relation to your view is something that the Dynamic Entity Reference module provided out of the box.

For anyone looking to restore this functionality, I constructed this piece of code which seems to do the job:

/**
 * Implements hook_views_data_alter().
 */
function mymodule_views_data_alter(array &$data) {
  if (!empty($data['linkchecker_link']) && empty($data['linkchecker_link']['node__entity_id']['relationship'])) {
    $entity_type = \Drupal::entityTypeManager()->getDefinition('linkcheckerlink');
    $target_entity_type = \Drupal::entityTypeManager()->getDefinition('node');

    $t_args = [
      '@origin_label' => $entity_type->getLabel(),
      '@target_label' => $target_entity_type->getLabel(),
      '@field_name' => 'parent_entity_id',
      '@type' => 'base field',
    ];

    $data['linkchecker_link']['node__entity_id']['relationship'] = [
      'title' => new TranslatableMarkup('@field_name to @target_label entities', $t_args),
      'label' => new TranslatableMarkup('@field_name: @target_label', $t_args),
      'group' => $entity_type->getLabel(),
      'help' => new TranslatableMarkup('References to @target_label entities referenced by @field_name @type on @origin_label entities.', $t_args),
      'id' => 'standard',
      'base' => 'node_field_data',
      'entity type' => $target_entity_type->id(),
      'base field' => $target_entity_type->getKey('id'),
      'relationship field' => 'parent_entity_id',
      'extra' => [
        [
          'left_field' => 'parent_entity_type_id',
          'value' => 'node',
        ],
      ],
    ];
  }
}

Not saying this is something that Linkchecker should offer out of the box (although I think it could come in very handy for some users), just leaving it out here for people running against similar issues.

Patch in #34 gave me JavaScript issues on Drupal 10.4.6. event.target.preventDefault(); was being called where event.target was undefined. Appeared an issue with the order of JavaScript being loaded. Added small adjusment to make sure the JavaScript is loaded after autocomplete is initialized.

I found out about this issue because I'm trying to update the Linkchecker → module we're using on a project. They decided to move away from using the Dynamic Entity Reference module for one of their entity's base fields ( 📌 Remove Dynamic Entity Reference (DER) dependency Needs review ).

When doing the upgrade, I started noticing fatal errors when saving Linkchecker entities because something was trying to write to the target_id_int column, after that column was removed. Appeared that the DER triggers we're still in place. These were not removed, apparently. I created an initial MR that removes triggers when a field storage is removed.

Updated patch in #54 to be compatible with Drupal 10.4.6.
I might take a stab at D11 soon.

Some form keys have changed. Attached patch should fix this on our side.

rp7 → created an issue. See original summary → .

I can confirm #131.

The preprocess-hook workaround being mentioned here doesn't cut it for showing batch results.

Thank you for the efforts made here.

Just FYI: I'm in the process of upgrading the Linkchecker module on my project and running against some issues related to Views. I have a View listing linkchecker links that also displays (per linkchecker link) a few fields of the linkchecker link's related entity (e.g. the entity the link was made in).

Turns out the Dynamic Entity Reference module has built-in functionality (dynamic_entity_reference_field_views_data()) that makes this possible. Looks like this functionality is completely lost now.

Looks like this was fixed in the 2.x version of the module. Please re-open if I'm mistaken.

Merged 2.0.x into the branch.
Since I couldn't change the target branch to 2.0.x, I created a new merge request (https://git.drupalcode.org/project/linkchecker/-/merge_requests/113).

rp7 → changed the visibility of the branch 3203329-support-entities-with to active.

rp7 → changed the visibility of the branch 3203329-support-entities-with to hidden.

rp7 → made their first commit to this issue’s fork.

Just putting my use-case out here: we have a few big content types with a lot of fields and nested paragraph structures. Content comes and goes (unpublish) quite frequently. Before our users unpublish content, they want/need to verify if it's not actively being used (referenced) anywhere. It makes life a lot easier for them to immediately see from which field the other entity is referencing. It's more or less a "killer" feature for them.

rp7 → created an issue. See original summary → .

@sickess29

Previous patch just avoided errors and there was no validation errors shown to user.

That's surprising. This patch has been in use for about a year, in a heavily used project of ours - we didn't get any complaints so far.

We did spot an issue with it with in combination with a custom field widget we wrote. Adjusted the patch a little to make it more robust.

Nevertheless, I'm all up for continuing with the work done in the MR - although I couldn't get it to work in my first tests. Will need more time to investigate.

I've been taking a stab at this, trying to stay within the constraints of the 2.x version of this module. Not the finished product yet (some tests are failing - not yet sure why), but this is my progress so far.

The route I went is creating a new @EntityUsageTrack plugin (paragraph_inherited) that goes through all the paragraphs a (host) entity references and tracks those references on the host entity itself.

We would lose the hierarchy information but I'd say that is not very useful anyway.

Well, actually it is for the editors on the project that I'm working on. They have pages with quite a complex nested paragraph structure. It helps them tremendously to immediately see in which nested paragraph the entity is referenced. This is the reason I expanded the field_name column so that it contains all the fields of the paragraph chain. It adds quite some complexity though, I'll give you that.

Not battle-tested just yet, but our initial internal tests look good. We have custom logic in various places that uses entity usage information, and no longer having to deal with intermediary paragraphs makes things less complex.

Insights & help always welcome.

rp7 → made their first commit to this issue’s fork.

rp7 → created an issue.

rp7 → created an issue.

Not sure if that even matters? The plugin is falsely claiming to base a deletion based on the revision creation time, but in fact it's using the changed time (while there's a creation time available).

FWIW, we have a project where we update old revisions retro-actively, when - for example - we add a new (required) fields to the content type.

Been using this on a quite busy project in production for a few months now, for 3 separate annotatable external entity types. No issues reported so far.

But it now appears to be in conflict with ✨ Translation support in vertical data aggregation Active , which is tailored to a different kind of external API format.

Besides that, test coverage is non-existent yet.

Does this make ✨ Make external entities translatable Needs work obsolete?

(just FYI: we've been using the work in ✨ Make external entities translatable Needs work successfully on a large project for a few months now)

rp7 → created an issue.

Oh boy - this is quite embarrassing :-)

I was looking at an older version of Search API. It appears this functionality has been added quite recently @ ✨ Do not delete items when loading fails Fixed .

Very awesome! Closing this one as this is obviously no longer needed. Sorry for the noise!

rp7 → created an issue.

guignonv → credited rp7 → .

I took a stab at this. Check the issue fork.
Next to the dynamic entity autocomplete form element, it also provides a field widget that uses this form element.
Check the attached recording.

Re-rolled against latest 2.x + fixed an issue when copy/paste something in the autocomplete field (this issue was introduced in patch in #31).

Re-rolled against 2.0.0.

I now see a search_published_contents_only setting was introduced. IMO this should make use of the event this ticket is introducing. Didn't have the time for this yet (nor for creating a test).

Re-rolled against 2.0.0

+1 for this. My config is riddled with "empty" config like this.

People looking for a temporary workaround, this one seems to work for me:

/**
 * Implements hook_field_widget_third_party_settings_form().
 */
function mymodule_ux_field_widget_third_party_settings_form(WidgetInterface $plugin, FieldDefinitionInterface $field_definition, $form_mode, array $form, FormStateInterface $form_state) {
    $element = [];

    // Add a "nested_hide_level" checkbox to the settings form.
    $element['mysetting'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('My setting'),
      '#default_value' => $plugin->getThirdPartySetting('mymodule', 'mysetting'),
      '#required' => FALSE,
      '#element_validate' => ['_mymodule_validate_mysetting'],
    ];

    return $element;
}

/**
 * Validates mysetting.
 */
function _mymodule_validate_mysetting(&$element, FormStateInterface $form_state, &$complete_form) {
  if (empty($element['#value'])) {
    $form_state->unsetValue(array_slice($element['#parents'], 0, -1));
  }
}

Argh, sorry. But I think I cheered a little too early.
It looks like updates are now correctly imported, but a deleted mapping is not.
So if I delete a mapping for a field from the config file, import it & perform drush cex -y - it's added again.
Any idea?

Sorry for the late reply, but it looks like it works. Thanks!

Sorry for posting in this old issue, but I was wondering: could it be that we forgot to update the return type of \Drupal\Core\Entity\EntityChangedInterface::getChangedTime() ?

This is still

/**
  * Gets the timestamp of the last entity change for the current translation.
  *
  * @return int
  *   The timestamp of the last entity save operation.
  */
public function getChangedTime();

While \Drupal\Core\Entity\EntityChangedTrait::getChangedTime() is now documented to be able to return NULL values:

  /**
   * Gets the timestamp of the last entity change for the current translation.
   *
   * @return int|null
   *   The timestamp of the last entity save operation. Some entities allow a
   *   NULL value indicating the changed time is unknown.
   */
  public function getChangedTime() {
    $value = $this->get('changed')->value;
    return isset($value) ? (int) $value : NULL;
  }

I've found the code that's causing this, although it's not clear to me why this code is there in the first place. Removing it fixes the issue & I don't immediately see something that breaks without this code.

Patch attached removes the code. Not a real solution, more of a (temporary) quick-fix to work around this issue.

rp7 → created an issue.

@guignonv
I think that was idd something that creeped into the MR when resolving conflicts. Reverted that change.

Fork works now. I'm hiding the patch. Latest changes can be seen in the MR.

Uploading my current work as a patch for now, since this issue's fork returns a 404 page in GitLab (https://git.drupalcode.org/issue/external_entities-3475248/-/import) - hopefully that fixes itself soon.

This patch removes the need to use the inline entity form module completely for annotations. The external entity type's annotation fields now also appear on the form display configuration page, where you can configure the position and widgets of these fields as if they were regular fields.

This allows us to remove all the quirks/workarounds in this module to be compatible with inline entity form. I see no reason anymore why one would use inline entity forms for annotations.

The patch currently also picks up the feature requested @ ✨ Filter the annotation field Needs work , including an automatic upgrade path for this.

What I currently still need to test/work on is how this works in combination with translations (e.g. the work being done in ✨ Make external entities translatable Needs work ).

Hmm, that's odd.

I started a project from scratch and quickly created an external entity type (through the UI) called my_external_entity_type and the validation error is also present for this one.

I attached a screenshot + the external entity type's config export - hopefully you can reproduce it as well.

rp7 → created an issue.

@guignonv Thanks!
I'm spotting an issue though when upgrading from 2.x:

>  [error]  Cannot add field 'xntt_rest_queries.ephash': field already exists. 
>  [error]  Update failed: external_entities_update_93015 

Probably because when I'm upgrading my project, external_entities_update_9305() is also being run (which installs the xntt_rest_queries table).

See patch attached. Maybe we should add something like this?

Thx! Maybe a new issue would be useful for such a clean-up.

I think you forgot to merge this, though (:

I tried switching the issue fork branch to 3.x but can't get it to work. Might be because the initial ticket version was 2.x?
Anyway, I'm closing this issue & re-creating it for 3.x @ ✨ Make external entities translatable Needs work . Sorry for the mess.

rp7 → created an issue.

rp7 → changed the visibility of the branch 3474891-make-external-entities to hidden.

use Psr\Log\LoggerInterface;

It's already in the file, see line #18.

I think you can ask yourself: why is there even a getLogger() method, while the class already has a logger() method.

rp7 → created an issue.

Not a real solution, but here's a quick workaround for whoever needs it (we aren't using the REST storage client, so the unique index is not really important for us anyway).

rp7 → created an issue.

I upgraded my project (using several custom storage clients) from 2.x to 3.x. Here are some remarks:

• The update hooks transforming the config to be compatible with 3.x worked flawlessly!
• Most of the things I had to do is already documented in https://git.drupalcode.org/project/external_entities/-/blob/3.0.x/DEVELO... .
• In order to alter some filters, I had some custom hooks I invoked from my custom storage clients. I was able to replace these successfully with the TRANSLITERATE_DRUPAL_FILTERS event.
• I had some custom logic in my storage clients related to sorting parameters sent to the external source. I couldn't find a way to replace these, so I created ✨ Allow to alter sorts through event subscriber Needs review .
• I faced some other issues, for which I created several tickets. ( 🐛 ID is not assigned to newly saved external entities Needs review , 🐛 JsonPath::getMappedSourceFieldName() incompatible with various JSONPath notations Needs review , 🐛 Incompatibility with Monolog Needs review )

It went better than expected. Nice work!
I did see some stuff in code I have doubts about/maybe would do differently. If it's OK by you, and once I find the time, I'll create a separate issue to list these & have a place to discuss them.

rp7 → created an issue.