Generalizing deletion of placeholderfield django-cms with signals

I'm currently working in django-cms and utilizing a PlaceholderField in several of my models. As such, I'd like to generalize this process to avoid having to override every model's delete, and add a specialized manager for each type of object just to handle deletions.

a little back story:

After working up the design of my application a little bit and using the (honestly impressive) PlaceholderFields I noticed that if I deleted a model that contained one of these fields, it would leave behind it's plugins/placeholder after deletion of the model instance that spawned it. This surprised me, so I contacted them and according to django-cms's development team:

By design, the django CMS PlaceholderField does not handle deletion of the plugins for you. If you would like to clear the placeholder content and remove the placeholder itself when the object that references it is deleted, you can do so by calling the clear() method on the placeholder instance and then the delete() method

So being that this is expected to happen prior to deletion of the model, my first thought was use the pre_delete signal provided by django. So I set up the following:

my problem

models.py

 class SimplifiedCase(models.Model):

     #... fields/methods ...
    my_placeholder_instance= PlaceholderField('reading_content')  # ****** the placeholder 

    #define local method for clearing placeholderfields for this object 
    def cleanup_placeholders(self):
        # remove any child plugins of this placeholder
        self.my_placeholder_instance.clear()

        # remove the placeholder itself
        self.my_placeholder_instance.delete()  


# link the reciever to the section
signals.pre_delete.connect(clear_placeholderfields, sender=SimplifiedCase)

signals.py

# create a generalized reciever 
#(expecting multiple models to contain placeholders so generalizing the process)
def clear_placeholderfields(sender, instance, **kwargs):
    instance.cleanup_placeholders()  # calls the newly defined cleanup method in the model

I expected this to work without any issues, but I'm getting some odd behavior from when calling the [placeholder].delete() method from within the method called by the pre_delete receiver.

For some reason, when calling the placeholder's delete() method in my cleanup_placeholders method, it fires the parent's pre_delete method again. Resulting in an recursion loop

I'm relatively new to using django/django-cms, so possibly I'm overlooking something or fundamentally misunderstanding what's causing this loop, but is there a way to achieve what I'm trying to do here using the pre_delete signals? or am I going about this poorly?

Any suggestions would be greatly appreciated.

Solution

After several days of fighting this, I believe I've found a method of deleting Placeholders along with the 3rd party app models automatically.

Failed attempts: - Signals failed to be useful due to the recursion mentioned my question, which is caused by all related models of a placeholder triggering a pre_delete event during the handling of the connected model's pre_delete event.

Additionally, I had a need for handling child FK-objects that also contained their own placeholders. after much trial and error the best course of action (I could find) to ensure deletion of placeholders for child objects is as follows:

define a queryset which performs an iterative deletion. (non-ideal, but only way to ensure the execution of the following steps)

class IterativeDeletion_Manager(models.Manager):
    def get_queryset(self):
        return IterativeDeletion_QuerySet(self.model, using=self._db)

    def delete(self, *args, **kwargs):
        return self.get_queryset().delete(*args, **kwargs)

class IterativeDeletion_QuerySet(models.QuerySet):

    def delete(self, *args, **kwargs):

        with transaction.atomic():

            # attempting to prevent 'bulk delete' which ignores overridden delete
            for obj in self:
                obj.delete()

Set the model containing the PlaceholderField to use the newly defined manager.

Override the deletion method of any model that contains a placeholder field to handle the deletion of the placeholder AFTER deletion of the connected model. (i.e. an unoffical post_delete event)

class ModelWithPlaceholder(models.Model):

    objects = IterativeDeletion_Manager()

    # the placeholder
    placeholder_content = PlaceholderField('slotname_for_placeholder')

    def delete(self, *args, **kwargs):

        # ideally there would be a method to get all fields of 'placeholderfield' type to populate this
        placeholders = [self.placeholder_content]

        # if there are any FK relations to this model, set the child's 
        # queryset to use iterative deletion as well, and manually 
        # call queryset delete in the parent (as follows)

        #self.child_models_related_name.delete()

        # delete the object
        super(ModelWithPlaceholder,self).delete(*args, **kwargs)

        # clear, and delete the placeholders for this object 
        # ( must be after the object's deletion )
        for ph in placeholders:
            ph.clear()
            ph.delete()

Using this method I've verified that the child PlaceholderFieldfor each object is deleted along with the object utilizing the Admin Interface, Queryset deletions, Direct deletions. (at least in my usage cases)

Note: This seems unintuitive to me, but the deletion of placeholders needs to happen after deletion of the model itself, at least in the case of having child relations in the object being deleted.

This is due to the fact that calling placeholder.delete() will trigger a deletion of all related models to the deleted-model containing the PlaceholderField.

I didn't expect that at all. idk if this was the expected functionality of deleting a placeholder, but it does. Being that the placeholder is still contained in the database prior to deleting the object (by design), there shouldn't be an issue with handling it's deletion after calling the super(...).delete()

if ANYONE has a better solution to this problem, feel free to comment and let me know my folly. This is the best I could come up with after many hours running through debuggers and tracing through the deletion process.