Created a merge request based on patch provided in #7. Only change I made is that it contained an unset($element['#description']); - I reverted this, because I believe it shouldn't be there (my custom field description was no longer showing).
Sorry - my question was wrong.
Why was my original MR (MR 20) hidden - @afaqraza16 ?
Sorry for digging up this old issue, but I was having the exact same issue. I was overriding some twig files and CSS classes as well.
To give some info to people battling this same issue: the Facets module expects the "block-facets-ajax" and "js-facet-block-id-*" classes to be present.
This is a duplicate of ✨ Drupal 10 compatibility Active . Since that issue has been going on for longer/has had more traction, let's continue efforts in there.
@vladimiraus
I see you closed the original MR. Can you elaborate on why? In the new MR I also see a lot of changes that seem to be unrelated (but I might we wrong of course).
Can we make this somehow configurable?
I'm using this module and I don't want my users to make changes to entities without their changed date being updated.
The changed date being updated is standard behavior - I feel like this option needs an opt-in to be presented to users.
Just posting here to point out that this would be incompatible with what's being discussed in ✨ Allow composite entities to opt out of creating duplicate revisions Active . That would make it possible for a single paragraph revision to belong to multiple parent revisions.
This would make 📌 Store information about a paragraph's parent revision Active impossible as a single paragraph revision could then potentially point to multiple parent revision IDs.
I've tested this patch and it works & it fixed my issue. Thanks for the effort!
I needed it on a Drupal 11.1.x project, and sadly enough the patch in #21 doesn't apply. I had to re-roll it for Drupal 11.1.x. Attaching it (hidden) if someone else needs it (changes are very minimal).
Just wanted to chime in that are database is growing really hard just because of this. We have a lot of paragraphs in use, with very active editors.
I believe this is a duplicate of ✨ Allow composite entities to opt out of creating duplicate revisions Active .
Oh, wow. That did the trick. I feel really stupid now :-)
Thanks @dieterholvoet!
Looks like the use statements we're forgotten in the MR (https://git.drupalcode.org/issue/entity_reference_revisions-3281020/-/tr...).
I tried fixing it, but apparently I don't have push rights to this MR's branch. Can someone give me these?
In the mean while, attaching a patch file here.
I'm not convinced it's a good approach to mark this as a duplicate. It's something completely different (but yes, this fix is a pre-requisite for 🐛 Allow saving pre-existing references to inaccessible items Active ).
We're now waiting on 🐛 Allow saving pre-existing references to inaccessible items Active , while this (pretty trivial) bug fix can go out a lot sooner.
Any chance of moving this forward?
I opened a merge request. This is basically a copy of how core does it concerning previously referenced items.
This MR also contains the changes needed for 🐛 ValidDynamicReferenceConstraintValidator doesn't pass correct entity to selection handler Active , as we need it in order to be able to load the correct unchanged entity.
PS: I'd like to suggest opening up another issue to make use of
EntityStorageInterface::loadMultiple() in the whole of ValidDynamicReferenceConstraintValidator. I'm convinced this can greatly enhance validation performance for dynamic entity reference fields containing a lot of references (to the same target type).
rp7 → changed the visibility of the branch 2909747-allow-saving-pre-existing to hidden.
rp7 → changed the visibility of the branch 2909747-allow-saving-pre-existing to active.
rp7 → changed the visibility of the branch 2909747-allow-saving-pre-existing to hidden.
rp7 → created an issue.
Sorry for going AWOL. This completely fell of my radar.
We can add a hook somewhere, so a third party might do whatever they want, including storing more info somewhere
That sounds like an option. Where do you think this hook should invoked? My first thoughts tell me TrackPluginBase::getTargetEntities().
And with "somewhere" I guess you don't mean in the track_usage table. (but I guess - with custom code - I could add an extra colum in there).
After some thinking, I think the most proper way is to be able to call $external_entity->save() or $external_entity->delete(). This comes very close (if not completely) to Drupal's default way of working with entities - but doing this could (if your external entities are not marked as read-only) send a write to the external API - which is undesired in this scenario (since we only want to call it to make Drupal do its thing on the new/updated/deleted entity).
I was wondering if it's a good idea to introduce something so that we can (temporarily) mark external entities on which save/delete operations are performed, to not push through to the external API. See patch attached. It's based on a similar functionality Drupal core (setSyncing and isSyncing).
With this patch, the code above could be changed to:
$entity->skipExternalStorageMutation();
$entity->save();
$entity->skipExternalStorageMutation(FALSE);
and
$entity->skipExternalStorageMutation();
$entity->delete();
$entity->skipExternalStorageMutation(FALSE);
Any thoughts? How is everyone else tackling this problem space?
Here's my experience on a project we're working on.
We have an external system that notifies us (through a custom API endpoint) about changes on our external content. Once we receive a message (operation, type, ID), after some trial and error we ended up with the following code to invoke entity lifecycle hooks:
if ($action === 'delete') {
$entity::preDelete($entity_storage, [$entity]);
$this->moduleHandler->invokeAll($entity->getEntityTypeId() . '_predelete', [$entity]);
$this->moduleHandler->invokeAll('entity_predelete', [$entity]);
$entity::postDelete($entity_storage, [$entity]);
}
else {
$entity->original = clone $entity;
$entity->preSave($entity_storage);
$this->moduleHandler->invokeAll($entity->getEntityTypeId() . '_presave', [$entity]);
$this->moduleHandler->invokeAll('entity_presave', [$entity]);
$entity->postSave($entity_storage);
}
$hook = $action === 'create' ? 'insert' : $action;
$this->moduleHandler->invokeAll($entity->getEntityTypeId() . '_' . $hook, [$entity]);
$this->moduleHandler->invokeAll('entity_' . $hook, [$entity]);
This has worked more or less OK for quite a while. It does have some gaps, however. Thinking about the entity translation-specific hooks, for example.
rp7 → created an issue.
I'm starting to think that this might be an issue with Scheduled Transitions after all.
If I edit the info.yml file manually from php: 8.3 to php: '8.3' the issue is resolved.
Drupal core uses version_compare() to compare 2 PHP versions. This function expects the versions to be passed in as strings.
Going by documentation at https://www.commonwl.org/user_guide/topics/yaml-guide.html#key-value-pairs and https://symfony.com/doc/current/reference/formats/yaml.html#strings, I believe version numbers (that can be interpreted as a numeric value) should be quoted in strings when in YAML.
I can't find anything documented on this on drupal,org, but it does seem that Drupal.org's packaging script does this as well (for example, check the module version numbers of core modules - they are all wrapped in quotes).
If you happen to agree, I'm willing to provide a MR for this.
Re-rolled against 11.1.x
I believe it's ready - battle-tested for a month or 2 now on a project of mine :)
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.
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 dependency of Dynamic Entity Reference (DER) Active ).
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).
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 → .