[drupal-devel] [bug] hook_delete_confirm -- custom controls for modules during delete cycle
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: 4.6.2 Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG thehunmonkgroup
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal -Version: 4.6.2 +Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 15:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Steven Status: patch a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. Steven Previous comments: ------------------------------------------------------------------------ July 14, 2005 - 00:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 14, 2005 - 01:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Steven Status: patch Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. Steven Previous comments: ------------------------------------------------------------------------ July 14, 2005 - 00:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 14, 2005 - 01:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 14, 2005 - 01:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 15:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 13, 2005 - 16:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 13, 2005 - 16:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 13, 2005 - 16:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Bèr Kessels Status: patch I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. Bèr Kessels Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 23:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 14, 2005 - 00:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 14, 2005 - 00:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 14, 2005 - 00:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ July 14, 2005 - 02:03 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 15:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 13, 2005 - 16:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 13, 2005 - 16:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 13, 2005 - 16:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ July 13, 2005 - 18:03 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ July 14, 2005 - 03:08 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Bèr Kessels Status: patch 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) Bèr Kessels Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 23:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 14, 2005 - 00:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 14, 2005 - 00:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 14, 2005 - 00:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ July 14, 2005 - 02:03 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ July 14, 2005 - 11:08 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ July 14, 2005 - 16:46 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: killes@www.drop.org Status: patch I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. killes@www.drop.org Previous comments: ------------------------------------------------------------------------ July 14, 2005 - 00:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 14, 2005 - 01:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 14, 2005 - 01:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 14, 2005 - 01:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ July 14, 2005 - 03:03 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ July 14, 2005 - 12:08 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ July 14, 2005 - 17:46 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ July 14, 2005 - 18:02 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Bèr Kessels Status: patch oh, btw, you have my +1. forgot to add that in the previous issue. ;) Bèr Kessels Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 23:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 14, 2005 - 00:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 14, 2005 - 00:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 14, 2005 - 00:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ July 14, 2005 - 02:03 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ July 14, 2005 - 11:08 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ July 14, 2005 - 16:46 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ July 14, 2005 - 17:02 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ July 14, 2005 - 17:03 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go thehunmonkgroup Previous comments: ------------------------------------------------------------------------ July 13, 2005 - 15:53 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ July 13, 2005 - 16:00 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ July 13, 2005 - 16:28 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ July 13, 2005 - 16:30 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ July 13, 2005 - 18:03 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ July 14, 2005 - 03:08 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ July 14, 2005 - 08:46 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ July 14, 2005 - 09:02 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ July 14, 2005 - 09:03 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ July 14, 2005 - 09:04 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;)
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [1]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [1] http://drupal.org/www.outofprintdownloads.com thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [2] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [2] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) that last link to the test site was no good. try here [1]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [1] http://www.outofprintdownloads.com thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [2] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [2] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [3]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [3] http://drupal.org/www.outofprintdownloads.com
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL)
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system -Category: bug reports +Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: chx Status: patch (code needs review) When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? chx Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: chx Status: patch (code needs review) Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. chx Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'?
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Bèr Kessels Status: patch (code needs review) I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Bèr Kessels Status: patch (code needs review) Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) Bèr Kessels Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :)
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?)
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [1] [1] http://www.outofprintdownloads.com thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [2] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [2] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [3]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [3] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [4]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: crunchywelch Status: patch (code needs review) +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... crunchywelch Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: mathias Status: patch (code needs review) +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. mathias Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed...
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: humaneasy Status: patch (code needs review) +1 from me too. Nothing to add to the discussion besides thanks. humaneasy Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup -Status: patch (code needs review) +Status: patch (ready to be committed) i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: bomarmonk Status: patch (ready to be committed) Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). bomarmonk Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status...
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: shane Status: patch (ready to be committed) I'd like to see this go into 4.7 so that repeating events [1] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [1] http://drupal.org/node/4122 shane Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [2] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [2] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [3]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [3] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [4]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [5] [5] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality).
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: benshell Status: patch (ready to be committed) +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. benshell Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: bkudrle Status: patch (ready to be committed) +1 for me also. I am looking forward to the functionality provided by the recurring events. bkudrle Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Steven -Status: patch (ready to be committed) +Status: patch (code needs work) Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. Steven Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup -Status: patch (code needs work) +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Iluvatar -Status: won't fix +Status: patch (code needs review) I don't know if I'm supposed to go against Dries and change the status back, but I do not completely agree with him. I think he is referring to the fact that modules can prevent the deletion of a node. "When I want to delete a node, I want to do exactly that: delete it." Exactly. But... That does not mean that the delete pre nodeapi operation can't be used to insert some extra information and/or form fields. I already have implemented this in one of my modules. This module provides some sort of container node, and I used the delete pre hook to add a checkbox to the delete confirmation form asking if the user wants to the delete all nodes that are attached to the container node. Works great. The cancellation thing can be removed from the patch. Please reconsider. Iluvatar Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:46:19 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:13:37 +0000 : Dries I'm not a fan of this patch (as mentioned before). Deleting nodes is meant to be a simple task, not a programmable task. When I want to delete a node, I want to do exactly that: delete it.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: chx Status: patch (code needs review) Reconsider indeed. I had my reasons for asking a feature so modules can turn down the deletion of a node. Matt provided a concrete use case http://drupal.org/node/26649#comment-40478 and also, node relation modules will need this. chx Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:46:19 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:13:37 +0000 : Dries I'm not a fan of this patch (as mentioned before). Deleting nodes is meant to be a simple task, not a programmable task. When I want to delete a node, I want to do exactly that: delete it. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:35:08 +0000 : Iluvatar I don't know if I'm supposed to go against Dries and change the status back, but I do not completely agree with him. I think he is referring to the fact that modules can prevent the deletion of a node. "When I want to delete a node, I want to do exactly that: delete it." Exactly. But... That does not mean that the delete pre nodeapi operation can't be used to insert some extra information and/or form fields. I already have implemented this in one of my modules. This module provides some sort of container node, and I used the delete pre hook to add a checkbox to the delete confirmation form asking if the user wants to the delete all nodes that are attached to the container node. Works great. The cancellation thing can be removed from the patch. Please reconsider.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: Iluvatar Status: patch (code needs review) Maybe the cancellation code should be reworked, it is not very user-friendly atm, for example when deleting a single node the code simply redirects back to the edit page. A few suggestions are: * somehow forcing the module that cancels the deletion to provide a message with a reason; * another hook, delete cancel for example; * a combination of them both. Iluvatar Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:46:19 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:13:37 +0000 : Dries I'm not a fan of this patch (as mentioned before). Deleting nodes is meant to be a simple task, not a programmable task. When I want to delete a node, I want to do exactly that: delete it. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:35:08 +0000 : Iluvatar I don't know if I'm supposed to go against Dries and change the status back, but I do not completely agree with him. I think he is referring to the fact that modules can prevent the deletion of a node. "When I want to delete a node, I want to do exactly that: delete it." Exactly. But... That does not mean that the delete pre nodeapi operation can't be used to insert some extra information and/or form fields. I already have implemented this in one of my modules. This module provides some sort of container node, and I used the delete pre hook to add a checkbox to the delete confirmation form asking if the user wants to the delete all nodes that are attached to the container node. Works great. The cancellation thing can be removed from the patch. Please reconsider. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:43:01 +0000 : chx Reconsider indeed. I had my reasons for asking a feature so modules can turn down the deletion of a node. Matt provided a concrete use case http://drupal.org/node/26649#comment-40478 and also, node relation modules will need this.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: thehunmonkgroup Status: patch (code needs review) Attachment: http://drupal.org/files/issues/delete_pre_1.patch (2.52 KB) one more minor code change. it should be theme('item_list', $list), and not theme_item_list($list)... thehunmonkgroup Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:46:19 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:13:37 +0000 : Dries I'm not a fan of this patch (as mentioned before). Deleting nodes is meant to be a simple task, not a programmable task. When I want to delete a node, I want to do exactly that: delete it. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:35:08 +0000 : Iluvatar I don't know if I'm supposed to go against Dries and change the status back, but I do not completely agree with him. I think he is referring to the fact that modules can prevent the deletion of a node. "When I want to delete a node, I want to do exactly that: delete it." Exactly. But... That does not mean that the delete pre nodeapi operation can't be used to insert some extra information and/or form fields. I already have implemented this in one of my modules. This module provides some sort of container node, and I used the delete pre hook to add a checkbox to the delete confirmation form asking if the user wants to the delete all nodes that are attached to the container node. Works great. The cancellation thing can be removed from the patch. Please reconsider. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:43:01 +0000 : chx Reconsider indeed. I had my reasons for asking a feature so modules can turn down the deletion of a node. Matt provided a concrete use case http://drupal.org/node/26649#comment-40478 and also, node relation modules will need this. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:57:30 +0000 : Iluvatar Maybe the cancellation code should be reworked, it is not very user-friendly atm, for example when deleting a single node the code simply redirects back to the edit page. A few suggestions are: * somehow forcing the module that cancels the deletion to provide a message with a reason; * another hook, delete cancel for example; * a combination of them both.
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: chx Status: patch (code needs review) The following criteria are used by core developers in reviewing and approving proposed changes: * /The changes support and enhance Drupal project aims [1]/. " can collectively produce .. information" this patch helps complex information structures remain intact. Also, recurring events are a popular request in community circles. * /The proposed changes are current. /Yes they are. * /The proposed change doesn't raise any significant issues or risks. /Specifically, issues that have been raised in the review process have been satisfactorily addressed. -- I had my concerns at the beginning, lately Steven had some but those are answered in detail. * /The changes are well coded. /Yes they are. Code is short and nice and the only "WTF" line is commented. * /There is demonstrated demand and support for the change. / There is. Besides empty, useless +1s there are valid use cases provided. * /The change will be used by a significant portion of the installed Drupal base/This does not stand, true, but the number of users will be at least proportional to the amount of LoC this patch contains. * /The benefits of the change justifies additional code and resource demands. /Again, code is small and light. And it's even documented. [1] http://drupal.org/node/view/10250 chx Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [2] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [2] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [3]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [3] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [4]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [5] [5] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [6] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [6] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:46:19 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:13:37 +0000 : Dries I'm not a fan of this patch (as mentioned before). Deleting nodes is meant to be a simple task, not a programmable task. When I want to delete a node, I want to do exactly that: delete it. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:35:08 +0000 : Iluvatar I don't know if I'm supposed to go against Dries and change the status back, but I do not completely agree with him. I think he is referring to the fact that modules can prevent the deletion of a node. "When I want to delete a node, I want to do exactly that: delete it." Exactly. But... That does not mean that the delete pre nodeapi operation can't be used to insert some extra information and/or form fields. I already have implemented this in one of my modules. This module provides some sort of container node, and I used the delete pre hook to add a checkbox to the delete confirmation form asking if the user wants to the delete all nodes that are attached to the container node. Works great. The cancellation thing can be removed from the patch. Please reconsider. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:43:01 +0000 : chx Reconsider indeed. I had my reasons for asking a feature so modules can turn down the deletion of a node. Matt provided a concrete use case http://drupal.org/node/26649#comment-40478 and also, node relation modules will need this. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:57:30 +0000 : Iluvatar Maybe the cancellation code should be reworked, it is not very user-friendly atm, for example when deleting a single node the code simply redirects back to the edit page. A few suggestions are: * somehow forcing the module that cancels the deletion to provide a message with a reason; * another hook, delete cancel for example; * a combination of them both. ------------------------------------------------------------------------ Sun, 18 Sep 2005 19:58:53 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_1.patch (2.52 KB) one more minor code change. it should be theme('item_list', $list), and not theme_item_list($list)...
Issue status update for http://drupal.org/node/26649 Post a follow up: http://drupal.org/project/comments/add/26649 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: thehunmonkgroup Reported by: thehunmonkgroup Updated by: sepeck Status: patch (code needs review) I have to add my +1 voice here as well. I have one site that uses event module. Currently to have repeating or multi day classes, the store owner must hand enter each and every class time indivudally. This is a waste of her time if adding and removing multi day scheduled events can be done through one interface. The event repeat module worked on my test site with this patch in the brief time I had to test it. She does not see 'nodes' as what she is deleting, she see's one class(event) that she is cancelling and deleting. That the event in question is actually occuring over 5 evening classes makes it 5 nodes confuses her, so this ability to automate node removal is important. It is like when deleting a comment, all the child comments get deleted automatically too with but one warning. sepeck Previous comments: ------------------------------------------------------------------------ Wed, 13 Jul 2005 22:53:01 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm.patch (547 bytes) the proposed patch creates a hook_delete_confirm, which is called from node_delete during the confirmation cycle. this hook allows modules to inject custom control structures into the deletion process, as they don't currently have this ability. this is needed, for example, in the eventrepeat.module that i'm creating, which handles repeating/recurring events for event.module. without a solution such as this, there is no way for the module to put in options for different kinds of deletions--ex. 'this occurance only', 'this and all future occurances', 'all occurances'. click here [1] for a screenshot of what this hook looks like in action... i've tested this patch and it works great, even when multiple modules are calling hook_delete_confirm. i'd also be happy to write the documentation for hook_delete_confirm if this patch gets accepted. [1] http://www.apartmentlines.com/hook_delete_confirm_screenshot.PNG ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:00:56 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_screenshot.PNG (92.79 KB) just a note that this patch will apply to both 4.6.x and HEAD. marking the version as 'cvs'. also, attached is the screenshot i mentioned above. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:28:28 +0000 : Steven a) New features don't get added to 4.6, this would only go into HEAD. b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not allowed according to the PHP docs. It is best to be precise: http://php.net/implode. ------------------------------------------------------------------------ Wed, 13 Jul 2005 23:30:08 +0000 : Steven Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your module depends on operations being performed on deletion. ------------------------------------------------------------------------ Thu, 14 Jul 2005 01:03:55 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/node_module_hook_delete_confirm_2.patch (551 bytes)
a) New features don't get added to 4.6, this would only go into HEAD.
no problem there. since many people are waiting for this feature, i'll include this patch (or a patched version of node.module) so that the functionality will be available for those that wish to begin using my module right away in 4.6.x
b) You're using the historic argument order to implode(), and leaving out the 2nd argument, which is not >>allowed according to the PHP docs.
attached patch corrects this.
Also, you don't deal with mass-deletion. This needs to be added, otherwise things might break if your >>module depends on operations being performed on deletion.
this shouldn't be necessary, as the modules have ample tools to deal w/ mass deletion themselves--as long as they can pass some kind of control stucture into the deletion cycle (so that the module knows what kind of delete operation it needs to perform). i've tested the multiple delete functionality extensively in eventrepeat.module, and it works flawlessly with this patch in place. my thinking in designing this patch was add the absolute minimum to core that allows the modules some control in the deletion process. i think this is all that they'll need as long as they're well written. ------------------------------------------------------------------------ Thu, 14 Jul 2005 10:08:40 +0000 : Bèr Kessels I do like the idea of this, since i ran into a similar issue for shazamgallery and for books. But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a range of nodes at once. your patch will break that. And furthermore, I would like to see a good piece of documentation on how to use this. From what you have coded it seems the hook must return an array. Why not a straing? You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for returning a string. ------------------------------------------------------------------------ Thu, 14 Jul 2005 15:46:07 +0000 : thehunmonkgroup
But, steven is right when he says you should deal with batch deletion. in node/admin you can delete a >>range of nodes at once. your patch will break that.
not true. this patch isn't involved in the actual deletion of nodes, only with allowing modules to pass in a control structure so they have the ability to initiate different kinds of deletes--this doesn't interfere w/ the admin batch delete functionality at all. admin batch delete has it's own custom delete function, and this hook will not be called during it. here is a detailed use case for this patch, so that the flow can be seen more clearly: in eventrepeat.module, i have a need to be able to give the user a choice to delete entire repeat sequences, or just the current node. this needs to be decided at time of deletion, and i want to give them three choices: 'this occurance' 'this occurance and all future occurances' (which deletes from the date of the selected node forward) 'all occurances' (which deletes from today's date forward) prior to this patch, there was no way that my module could inject this kind of control structure into the deletion process. here's the hook i put into eventrepeat.module to take advantage of the new feature provided by this patch: function eventrepeat_delete_confirm($node) { if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never' && variable_get('eventrepeat_nodeapi_'. $node->type, 0) == 1) { if ($node->eventrepeat_rid) { $form .= form_hidden('eventrepeat_rid', $node->eventrepeat_rid); $options = array( 'this' => t('This occurance only'), 'future' => t('This occurance and all future occurances'), 'all' => t('All occurances') ); $form .= form_radios('Repeat event--delete the following:', 'eventrepeat_delete_type', 'this', $options, $description = t('\'This occurance and all future occurances\' will delete repeat events from the date of the selected node forward, \'All occurances\' will delete repeat events from today\'s date forward.'), $required = FALSE, $attributes = NULL); } return $form; } } this injects the id of the repeat sequence and the control structure i detailed above into the delete confirmation screen (i do some checks at the top to make sure that this data is only injected for nodes that are in a repeat sequence). now, when the user clicks 'Delete', the info i injected is available as $_POST data. since the user clicked delete, drupal processes the deletion of the node, and eventually during that process eventrepeat_nodeapi is called, at which point the module grabs the info it needs from $_POST. if, for example, the user selected 'all occurances', the module then calls it's own custom delete function to handle that process. simply put, the guts of that process is grabbing all the nids that need to be deleted, and calling node_delete for each one (in this case i pass in the confimation setting as well to node_delete, to automate the process). node_delete takes care of all the deletion dirty work for each node. the only tricky part is making sure that my custom delete function isn't called from eventrepeat_nodeapi multiple times (b/c that's called multiple times in a multiple delete)--i take care of this by unsetting the injected $_POST data when my custom delete function is called. works beautifully... :)
And furthermore, I would like to see a good piece of documentation on how to use this.
hopefully the above example makes usage clear, but i'd be happy to write up more doc if needed.
From what you have coded it seems the hook must return an array. Why not a straing?
the hook returns an html string which is the form data that will be injected into the confirmation screen
You concenate arrays with nothin ('') which IMHO is bad PHP. But I guess you have good reasons for >>returning a string.
these steps are necessary, because: #1 module_invoke_all returns an array, and each element of the array is an html string that i described above. if multiple modules return form data to be injected into the confirmation screen, this array will have multiple elements #2 the $extra argument in theme confirm needs to be passed in as a string, so i implode the array. it's best to include the 'glue' argument in implode (according to PHP documentation), but i don't want a seperator--i just want to turn the array into a string. therefore i insert an empty string as the 'glue'. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:02:51 +0000 : Bèr Kessels 1: you are right about the batch deletion. In fact, that will even benefit from this, because it might be able to use this hook. 2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:03:55 +0000 : killes@www.drop.org I obviously support this patch. Aside from the demand for docs nothing stops it from being submitted to core. Since the docs for hook calls actually reside outside of core, even that is no reason to not commit it right now. ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:04:26 +0000 : Bèr Kessels oh, btw, you have my +1. forgot to add that in the previous issue. ;) ------------------------------------------------------------------------ Thu, 14 Jul 2005 16:43:20 +0000 : thehunmonkgroup
2: the fact that both Steven and I misread your patch shows that the use of this hook needs clarification. I am not sure how the hooks at drupaldocs are documented, but it really needs to show up there, with details about what to returns and what to pass along. Also some clarification about when this hook is called is important (for that caused the confusion at #1)
i definitely agree. it's usage confused me in the beginning and i wrote it... ;) if the patch gets committed, i'm happy to write supporting documentation for hook_delete_confirm and post it whereever it needs to go ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:43:48 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_4.patch (2.19 KB) ok, based on several discussions with core developers, i've expanded the functionality so that mods can inject info into the admin mass delete cycle as well. for single node deletions, the patch allows for multiple modules to inject info into the confirmation screen. for admin mass deletions the same capability exists, plus modules can also inject data for multiple nodes. for the admin part of the hook, i also cleaned up the code that prints the confirmation screen--removing some unnecessary database queries and putting the list of nodes to be deleted into a theme_item_list. because of the extra database queries i removed, i think performance will be about the same even with the new functionality. this patch introduces a very handy functionality, and i've already found use for it in two of the mods i'm developing... :) not only can it inject control structures to enable mods to handle different types of multiple deletions (which i use in eventrepeat.module), but it can also be used to inject custom module messages into the delete cycle (ex., in signup.module, i use it to warn users when they're about to delete a node that users are signed up for!) for the module developer, this hook takes one argument, which is an array of nids to be deleted, and returns an array, the elements of which are also an array, with each key being the nid for which to inject the data, and the corresponding value is the data to be injected. (the array nesting was necessary because of the way module_invoke_all returns it's results. this approach returns each mod's custom injection data in it's own array--very flexible!) you can see this hook in action here [2]--username 'test' password 'drupal'. please also note that i didn't spend much time on working out the list theming, so we can clean that up later if it's not to everyone's liking! [2] http://drupal.org/www.outofprintdownloads.com ------------------------------------------------------------------------ Thu, 18 Aug 2005 17:48:24 +0000 : thehunmonkgroup that last link to the test site was no good. try here [3]--username 'test' password 'drupal' also, i'll post some screenshots of the hook in action, and write up some better doc in the next day or two... [3] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:11:23 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_screenshot.PNG (96.33 KB) attached are some screenshots of what this hook can do. after some more talks w/ other developers, it seems as though this functionality may fit better in hook_nodeapi, as a 'delete confirm' case. this seems to make sense b/c all modules have the option to inject data into any of the nodes that are being deleted. i'm happy to modify the patch in this case, but there is one catch that i wanted to get some opinions on before i dive in... in order for this hook to be supported in the admin batch delete, it's necessary to pass an array of nids to the module hook, so that the module can decide which nids to inject data into. the problem is, hook_nodeapi doesn't currently have an available argument where that can be passed in. what does everybody think about the idea of adding an $extra argument? the hook would then look like: hook_nodeapi(&$node, $op, $teaser = NULL, $page = NULL, $extra = NULL) ------------------------------------------------------------------------ Sat, 20 Aug 2005 06:03:26 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc.txt (3.21 KB) attached is module developer's documentation for this hook. If the code gets put into nodeapi as i mentioned above, i can modify this documentation accordingly. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:53:36 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_5.patch (2.54 KB) after further irc discussions w/ chx, i've rewritten this hook to live in nodeapi, and added a really cool extra feature... :) now modules can actually prevent deletion of a node by explicitly returning a value of FALSE. on a single node deletion, the user will be bounced back to the node/edit screen, and in batch deletions, the node will be removed from the batch delete queue prior to the confirmation screen. i left it up to module developers to drupal_set_message and tell their users what happened... :) couple of things about this new approach: 1. it's less efficient than the old approach for batch deletions, because now node_load and node_invoke_nodeapi get called for each node in the batch, as opposed to the old way which just made one call for all nodes. however... 2. it now lives in nodeapi, where i believe it belongs, and 3. the implementation for module developers is now way, way easier and less complicated. also, from an efficiency standpoint, i was able to completely remove all database queries from the confirm screen code in admin batch delete (the current approach queries the database once for each node in the batch, which i thought was inefficient). so i don't think the overall performance is going to be much different. i'll post module developer code for this new version shortly. outside of the delete prevention functionality, the patch does the same thing as before--so the screenshots i posted above are still relevant. ------------------------------------------------------------------------ Sun, 21 Aug 2005 02:58:07 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_2.txt (3.61 KB) new module developer documentation for the nodeapi version of this patch attached. ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:24:46 +0000 : chx When a node calls node_view of other nodes, it's invaluable to be able to stop the deletion of its 'siblings'. I was doing evil hackery before: I str_replace'd in the theme to get rid of the delete button. So I like this feature. However, I am not fully convinced that full node object needs to be passed on during mass deletion. A simple <?php $node = new stdClass(); $node->nid = ...; ?> should be enough IMO. But then again, node_delete issues a node_load. For consistency reasons, maybe this should be changed. BTW. in HEAD, node_load is simply node_load($nid). So what others think: is node_load necessary before deletion? What about renaming the op to 'delete pre'? ------------------------------------------------------------------------ Sun, 21 Aug 2005 07:26:47 +0000 : chx Just a note, because I love giving credits: the implementation of how deletions can be stopped is straight out from workflow. ------------------------------------------------------------------------ Sun, 21 Aug 2005 08:26:18 +0000 : Bèr Kessels I beleive we need node_load. As Robin states: " i left it up to module developers to drupal_set_message and tell their users what happened" So it is a good thing to have teh complete node, including all the metadata around it, available. ------------------------------------------------------------------------ Sun, 21 Aug 2005 14:16:28 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_confirm_6.patch (2.51 KB) per chx's suggestions, changed node_load to node_load($nid), and renamed the nodeapi $op to 'delete pre'. also double-checked the coding style. unless anybody catches something else, i think this baby is ready to go! Ber: btw, the name is Chad... :) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:11:20 +0000 : Bèr Kessels Sorry for the name, Chad. (what about two new profile fields: #drupal irc nick and REal name?) ------------------------------------------------------------------------ Sun, 21 Aug 2005 15:46:16 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/hook_delete_pre_7.patch (2.59 KB) minor cleanup. just adding a comment line to clear up potential confusion--no functional changes ------------------------------------------------------------------------ Sun, 21 Aug 2005 16:08:17 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_confirm_doc_3.txt (3.6 KB) ...and... updated module developer doc for the latest version of the patch the updated patch can be seen in action here [4] [4] http://www.outofprintdownloads.com ------------------------------------------------------------------------ Mon, 22 Aug 2005 23:05:23 +0000 : crunchywelch +1 from me, a lot of thought and discussion has happened around it, and I dont think there is another way to accomplish this without it. The patch seems small enough and will allow much needed functionality to progress. If only to quell the low roar of demand for repeating events, this patch should be committed... ------------------------------------------------------------------------ Tue, 23 Aug 2005 00:35:11 +0000 : mathias +1 The ability to cancel the deletion of a node comes in handy for ecommerce when attempting to remove a still-valid recurring payment product that still has subscribers. ------------------------------------------------------------------------ Wed, 24 Aug 2005 00:12:45 +0000 : humaneasy +1 from me too. Nothing to add to the discussion besides thanks. ------------------------------------------------------------------------ Sat, 27 Aug 2005 04:55:20 +0000 : thehunmonkgroup i've tested this patch extensively w/ no problems--works exactly as advertised. code has undergone review and several revisions, and is solid. developer feedback seems to indicate it's a desirable piece of functionality. switching to commit status... ------------------------------------------------------------------------ Sun, 28 Aug 2005 06:56:58 +0000 : bomarmonk Please get this in core for 4.7 (just adding my support, but I'm no developer--- just anxious for this functionality). ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:24:20 +0000 : shane I'd like to see this go into 4.7 so that repeating events [5] can also go live. I've been needing repeating events for over 3 years - and have been manually adding repeating events every month. HEARTY +1 for this. [5] http://drupal.org/node/4122 ------------------------------------------------------------------------ Thu, 01 Sep 2005 21:05:39 +0000 : benshell +1 from me also. I'm also waiting for this before I upgrade one of my older (heavily modified) sites. ------------------------------------------------------------------------ Wed, 07 Sep 2005 00:50:45 +0000 : bkudrle +1 for me also. I am looking forward to the functionality provided by the recurring events. ------------------------------------------------------------------------ Thu, 08 Sep 2005 09:02:24 +0000 : Steven Attachment: http://drupal.org/files/issues/delete.pre.patch (2.53 KB) I was planning on committing this, but then I noticed that the mass delete changes are broken: the extra data in the mass delete form is never passed to node_delete(). I've attached a patch with cleaned up comments and code style, but the big is still there. ------------------------------------------------------------------------ Fri, 09 Sep 2005 23:56:50 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre.patch (2.47 KB) Cleaned up the pass by reference stuff, and doubled checked coding style. Mass delete changes should be fine--none of the module-specific data needs to be passed to node_delete, as the mods can grab whatever data that's posted from the confirm screen (which is the same way that node delete get it's confirmation info). Just to be clear, there are two steps in the deletion cycle, and the module developer can make use of this functionality in both steps: * The confirmation step: the patch allows modules to inject data into the confirmation screen, and/or (under extreme cases) completely cancel the deletion of the node. Use cases for the injected data could be: * Warning message: ex. 'This event has X users signed up for it!' This allows relevant information to appear on the confirmation screen, instead of just the rather uninformative 'Are you sure you want to delete this?' blurb. * Control structure: ex, 'Delete this occurance', 'Delete all occurances'. In this instance, mods that need to get information from the user about things they'll do during the deletion cycle (like mass deletes in eventrepeat) have a way to get it! This is not possible with the current delete structure in core. * The deletion step: if a mod has passed in a control structure, it is available in $_POST during the actual deletion of the node. When node_delete invokes the nodeapi 'delete' op, then the mod can grab the $_POST data and perform any operations it needs. In the case of eventrepeat, I use it to perform mass deletes on other nodes in the repeat sequence. ------------------------------------------------------------------------ Thu, 15 Sep 2005 22:46:19 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_0.patch (2.52 KB) that last patch seems to be malformed--here's a working one... ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:13:37 +0000 : Dries I'm not a fan of this patch (as mentioned before). Deleting nodes is meant to be a simple task, not a programmable task. When I want to delete a node, I want to do exactly that: delete it. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:35:08 +0000 : Iluvatar I don't know if I'm supposed to go against Dries and change the status back, but I do not completely agree with him. I think he is referring to the fact that modules can prevent the deletion of a node. "When I want to delete a node, I want to do exactly that: delete it." Exactly. But... That does not mean that the delete pre nodeapi operation can't be used to insert some extra information and/or form fields. I already have implemented this in one of my modules. This module provides some sort of container node, and I used the delete pre hook to add a checkbox to the delete confirmation form asking if the user wants to the delete all nodes that are attached to the container node. Works great. The cancellation thing can be removed from the patch. Please reconsider. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:43:01 +0000 : chx Reconsider indeed. I had my reasons for asking a feature so modules can turn down the deletion of a node. Matt provided a concrete use case http://drupal.org/node/26649#comment-40478 and also, node relation modules will need this. ------------------------------------------------------------------------ Sun, 18 Sep 2005 17:57:30 +0000 : Iluvatar Maybe the cancellation code should be reworked, it is not very user-friendly atm, for example when deleting a single node the code simply redirects back to the edit page. A few suggestions are: * somehow forcing the module that cancels the deletion to provide a message with a reason; * another hook, delete cancel for example; * a combination of them both. ------------------------------------------------------------------------ Sun, 18 Sep 2005 19:58:53 +0000 : thehunmonkgroup Attachment: http://drupal.org/files/issues/delete_pre_1.patch (2.52 KB) one more minor code change. it should be theme('item_list', $list), and not theme_item_list($list)... ------------------------------------------------------------------------ Sun, 18 Sep 2005 19:59:54 +0000 : chx The following criteria are used by core developers in reviewing and approving proposed changes: * /The changes support and enhance Drupal project aims [6]/. " can collectively produce .. information" this patch helps complex information structures remain intact. Also, recurring events are a popular request in community circles. * /The proposed changes are current. /Yes they are. * /The proposed change doesn't raise any significant issues or risks. /Specifically, issues that have been raised in the review process have been satisfactorily addressed. -- I had my concerns at the beginning, lately Steven had some but those are answered in detail. * /The changes are well coded. /Yes they are. Code is short and nice and the only "WTF" line is commented. * /There is demonstrated demand and support for the change. / There is. Besides empty, useless +1s there are valid use cases provided. * /The change will be used by a significant portion of the installed Drupal base/This does not stand, true, but the number of users will be at least proportional to the amount of LoC this patch contains. * /The benefits of the change justifies additional code and resource demands. /Again, code is small and light. And it's even documented. [6] http://drupal.org/node/view/10250
participants (14)
-
benshell -
bkudrle
-
bomarmonk
-
Bèr Kessels
-
chx
-
crunchywelch
-
humaneasy
-
Iluvatar
-
killes
-
mathias
-
sepeck
-
shane
-
Steven
-
thehunmonkgroup