Problem/Motivation
The module is not aware of the difference between default and other revisions (typically most recent revisions). Consider this scenario:
Steps to reproduce
1. Node 1 exists and does not reference any taxonomy terms.
2. Editor creates a forward draft of the node and references Taxonomy Term A.
3. Taxonomy term A is deleted. Entity Reference Purger never finds the dangling reference because it's not on the default revision of the node.
4. The forward draft is published. Now the dangling reference causes all the problems that this module was designed to fix.
The same problem happens when reverting to an older revision which still contains the reference.
Proposed resolution
Find occurrences in both the default revision, and other revisions that are not also the default. Make adjustments to both without blowing away the other.
Remaining tasks
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | entity-reference-purger-3348323-6.patch | 10.06 KB | johnle |
| #5 | entity-reference-purger-3348323-5.patch | 7.2 KB | rajiv.singh |
| #4 | entity-reference-purger-3348323-4.patch | 4.79 KB | rajiv.singh |
Issue fork entity_reference_purger-3348323
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
dalinComment #4
rajiv.singh commentedFixing translation + workflow issue
Comment #5
rajiv.singh commentedFixed code redundancy in #4 patch
Comment #6
johnle commentedGreat job on the patch! Here are some bugs that I've updated to resolve from the previous patch
* Sometimes the revisions are not all deleted when a term is removed. I've just re-order the revision so that the main revision is deleted last that way it would not stop the revision from being deleted.
* SetSyncing still update the modified date to the most recent dates of the active revision on all languages, causing an issue with the content nove allowing to save with a message that it has been modified by another user. To fix this, used the code from the https://www.drupal.org/project/preserve_changed to keep the modified dates untouched if we are not creating a revision.
* Minor coding standard fixes and comments.
Comment #7
dalinThis should be `entity_reference_purger_field_info_alter()`
What happens if both entity_reference_purger and preserve_changes modules are installed? Should ERP just require PC as a dependency?
Should be `processEntities()`
Here too
This comment doesn't quite make sense. Maybe:
The current revision can't be deleted until the rest have, so move it to the end of the array.
This duplicated code should be moved into a protected method.
Comment #8
johnle commented@dalin
Thanks for the code review, I'll get all recommended change in place, one thing I am kinda struggling on is when adding a dependencies to preserve_change module, I've ran into the following issue:
* When applying a composer patch, it did not install the require preserve_change change module, likely due to it running the composer install on the module first, and then later on patching it with the composer changes.
* Adding the dependencies in the .info.yml file, seem to give conflict. I've tried the suggestion of adding an additional line break, but still no luck.
I think for the time being it might be easier to add the changedItem alter to the module, but use maybe a different key instead so it doesn't conflict with the preserve_change module properties key, what do you think?
Comment #9
dalin@johnle
> When applying a composer patch, it did not install the require preserve_change change module, likely due to it running the composer install on the module first, and then later on patching it with the composer changes.
Yes, that's a limitation with Composer Patches that can't be avoided.
https://docs.cweagans.net/composer-patches/troubleshooting/non-patchable...
But I wonder if you could get around that by using an issue fork (see the info at the top of this page) rather than a .patch file.
Comment #10
johnle commentedThanks, I will try pushing the changes to once https://git.drupalcode.org/ is stable again.
Comment #12
johnle commentedOk I was able to get this working that resolve the 2 issues above
Added this above the drupal.org patckagelist
with:
And ran:
It seem to installed the require dependencies. I'll need to retest this again with the replacement of the dependencies and the queuing bug that was reported from the patch from my team.
Comment #13
scott_euser commentedUpdating issue summary to match the code which gets all revisions rather than just 'forward' revisions. Since the MR already covers the scenario of reverting to an older revision as well.