Active
Project:
Automatic Entity Label
Version:
8.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
5 Mar 2019 at 18:17 UTC
Updated:
22 Nov 2022 at 15:56 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
AndyThornton commentedI am having the same issue (well, similar, I am uninstalling a module that has a content type that has an auto label). Despite the exported config looking right, I can see my DB entry (in config table) has no mention of the dependency.
UPDATE: sorry, that is incorrect - it is only empty after i removed my module.
Comment #3
super_romeo commentedSame thing.
Comment #4
colanComment #5
ramya balasubramanian commentedHi guys,
I am not facing this issue. I have created a new cck and added 2 sample contents. Then while deleting the cck, I am getting the warning message like 'Autoentity is used by 2 pieces of content on your site and you may not remove until you have removed all the content.
After deleting those sample nodes, I can able to delete the content type where I am getting these module dependencies and deleted successfully.
Please see the screenshot for the reference
Comment #6
geek-merlinComment #7
dqdIs this maybe parallel to the issue with garbage collection of paragraphs and entity revisions orphaned in db? Please test flushing caches and cron runs multiple times to confirm that this issue remains.
@#5 The reporter is referring to the configuration left-over not to a content type called "Autoentity" which belongs to your individual project but not to this module, from what I see in your screenshots.
Can anyone test if configuration will be back on entity type if entity type with same (machine-)name has been recreated?
Since D9 is around the corner there will be no backport to 8.2 but surely a fix for 8.3 and for 9.x - So regarding https://www.drupal.org/node/45111#major I set it back to "Normal" for now.
Comment #8
geek-merlinFixed my still not accurate title.
Comment #9
dqd@geek-merlin: thanks for keeping track here!
Comment #10
geek-merlinOK i vgrepped through the code and the dependency definition in \Drupal\auto_entitylabel\Form\AutoEntityLabelForm::submitForm looks (unnecesserily complicated but) correct:
It has assumptions that may fail for nonstandard entity types though... If this is the case, we have to get the bundle config entity and use \Drupal\Core\Config\Entity\ConfigEntityBase::getConfigDependencyName
Comment #11
geek-merlinFTR: If someone wants to clean this up in the next major version (for 3 we are in beta already), look into menu_ui how it's done, and make AEL settings a ThirdPartySetting of the bundle.
Comment #12
geek-merlinOn a quick check on simplytest.me i CAN reproduce this for node type page:
* Add AEL to node type page
* Trigger "delete node type page"
* On the confirm page on admin/structure/types/manage/page/delete, under "config deletions",...
expected: I see AEL config
actual: I do NOT see AEL config
ALSO: If i re-add a node type page, the stale AEL config is still there.
Comment #13
geek-merlinI looked into config/sync of one of my old projects (ael 2.x) and found imho correct dependencies for nodes and media:
AND i found stale AEL config (proof of this issue) with such dependencies.
Very strange...
Comment #14
geek-merlinSo this is confirmed. Strange, but stale config does not do harm so only minor or normal prio.
Comment #15
geek-merlinOK i found the solution in the config dependency factory \Drupal\Core\Config\ConfigManager::getConfigDependencyManager:
Only configuration entities can be depended on so we can ignore everything else.(We use a config object, not config entity.)
Imho converting to configEntity OR adding our own dependency handling would be a PITA.
So we're back to #11 and add a CR:
> look into menu_ui how it's done, and make AEL settings a ThirdPartySetting of the bundle entity.
(I can review but won't work on this though.)
Comment #16
damienmckennaFor an initial stable release could this be handled via hook_ENTITY_TYPE_delete()? I think the major architecture rewrite should be postponed in order to have a stable release sooner rather than later. This issue could also be postponed, IMHO.