I just wanted to throw this idea out there to see if anyone else is interested in a module like this. I could see this as a very common need for Drupal users. When modeling Drupal sites most people use node references to model hierarchies between content types. Node references allow you to link the content types together, but doesn't do anything when it comes to deleting the referenced nodes. If the parent node is deleted then all the child nodes are just sitting in the database taking up space.
Here is what I would like to see developed if anyone wants to take a stab at it. I don't think my coding skills are up to par for this, but I may attempt it at some point.
Name of module: Delete referenced
Overview:
This module would allow you to select for each content type the node reference fields and choose how to react to those nodes that the field references when the parent node is deleted.
Details:
So when you are editing a content type you would see a tab that say's something like "References" which list all node references that are attached to this content type.
For each node reference field you could choose the following:
- Do nothing
- Prompt User: Display a warning message that this node references the following nodes and allow the user to check off all the
- referenced nodes to be deleted with the parent node. There might need to also be a checkbox indicating whether or not to check all by default.
- Delete Referenced Nodes Automatically
What do you think? Hopefully someone can pick up this idea and run with it. Here is a similar but different in the way it works module. http://drupal.org/project/cck_referential_integrity
Comments
Big Publish Button
Here's a sandbox project (soon to be a full project) that automatically publishes and unpublishes referenced nodes along with the parent node:
http://drupal.org/sandbox/modulewallah/1136472
Automatically deleting them seems like a natural addition.
Module - Referential Integrity for CCK
Checked this existing module out yet?
http://drupal.org/project/cck_referential_integrity
If it doesn't already do all you are looking for (I haven't used it in a while, cannot recall if it does), maybe you'd be better off joining forces with that module maintainer so all contrib CCK referential integrity functionality is in one place...? It might also prevent any conflicts with multiple modules trying to manage child references...
Sorry - I'm an idiot
That module handles referential integrity in the other direction - when a child is deleted, it handles the reference from the parent...
I'm kind of surprised nobody has built a module like this yet as I agree it seems like a logical thing to be able to do... If not, it definitely would help clean up some node tables!
@sreynen - That's an
@sreynen - That's an interesting module, will it be for D6 or D7. Not sure if that is quite what I was thinking.
@arpieb - yah, I listed that module in the post. I also tried making a suggestion there: http://drupal.org/node/546060.
After thinking about this more, there might be away to handle this with Views Bulk Operations and Rules. NodeOne.se has some good videos of using Rules and Views Bulk Operations together. http://nodeone.se/blogg/learn-rules-screencast-series-summed-up
It might also be better to generalize this module because you might want to do more than just delete referenced nodes.
example: unpublish, set a flag from the flag module, etc.
Maybe it should be called something like: Delete Referenced Actions
I'll have to think about this some more.
Thanks for your input. If you have any other ideas just throw out here and maybe we can get a good discussion going.
I like it!
I don't know that setting up Rules and VBO is going to get you where you want very easily - it might be easier to build an action module... I'm just sayin'... ;)
You could provide extra actions that the core Trigger module could fire on node events, which would make your job much easier - and require fewer contrib dependencies. And there's no reason you couldn't additionally implement hooks for Workflow, Rules, or any other trigger-action framework to leverage the action if you desired. Also might make it more portable between D6 and D7.
I just installed the Listhandler module for a site where the dependency list was insane and managed to even confuse Drush, so the "minimize contrib dependencies" is maybe coming more from personal preference than anything - but that philosophy does remove potential breakage points as you don't have any control over the dependent contrib modules and changes in their functionality.
If you wanted to bundle user reference actions in as well (delete/disable users, change roles, etc), you could call it CCK Reference Actions and cover both kinds of CCK-core references in one module, and not limit yourself to just node reference unpub and delete operations...
@gmclelland - you toss some great suggestions out there - roll those sleeves up and sling some code for contrib, man! ;)
Here is another related
Here is another related module. I haven't tried it out. http://drupal.org/sandbox/markusbroman/1077246 - Referenced Node Delete
@arpieb - I would love to be
@arpieb - I would love to be able sling some code down, unfortunately I just lack the knowledge. Agreed, I like minimizing dependencies and increasing portability between D6 and D7, and lets not forget about exportability of these configurations. Having these new actions would allow a site builder to use it with Rules and make the whole thing exportable via the Features module.
CCK Reference Actions - Love the name
I agree user references should be included.
I really like the suggestion, can you give some more details about what kind of extra actions were you thinking? What would you name them?
Action suggestions
This is in no way all-inclusive, but some ideas building on above:
Node References
User References
Cross Clone
The Cross Clone module also provides this functionality, as far as I know.
//Johan Falk
I looked at that module once,
I looked at that module once, but I guess I overlooked the bottom where it talks about Deleting. I just assumed it was for cloning.
I will give it another look. I assume the way it works is you setup a Rule that says:
If node type is deleted then delete all nodes downstream (meaning all child nodes that this parent node references).
-That could possibly solve the deleting nodes use case above
Thanks @Itangalo