- Issue created by @finex
- 🇬🇧United Kingdom arcaic Milton Keynes
Not clear what you mean here.
If you remove a block from a nodes layout and the content type has revisions enabled then when the layout is saved a new revision of the node will be created.
The new revision will not reference the block but the previous revision will still reference the block so it is not orphaned.
Only if you delete the node will you "potentially" see an orphaned block but in my experience this is rare now as the layout code seems pretty much ok and doesn't orphan blocks anymore.
Even when you delete nodes completely you will see entries remaining in the inline_block_usage table with null values for the entity_type and entity. These get cleaned up when cron runs.
When this module was first created it seemed quite easy to have layout blocks be orphaned and of course if you are doing your own thing in code you can mess things up quite easily.
Hope that helps let me know if not.
- 🇮🇹Italy finex
Yeah, I know: when the revisions are enabled the procedure I've developed breaks the revisions system.
The main problem I'd like to solve is when you have to delete a block type but you can't delete a node. In this situation the orphaned entry will prevent to delete the block type. You have to delete all the old revisions and after delete the block instance from the database.
- 🇬🇧United Kingdom arcaic Milton Keynes
As far as I can tell this is not an issue with the module but your concern is with the way core manages blocks and revisions.
As far as this module is concerned, as is the case for core, if a revision of an entity still references a block then the block is not orphaned.Closing.
If you feel I have misunderstood then feel free to open another ticket with a more detailed explanation of what is wrong with this module and ideally some recommendation on how it could be modified to address any issue.
- Status changed to Closed: works as designed
8 months ago 7:47am 30 April 2024