rewrite destination parameter when using node delete links.

Bot.

#1: 2004960-delete-link-destantion-1.patch queued for re-testing.

Thank you for the patch!

+++ b/modules/node/views_handler_field_node_link_delete.incundefined
@@ -25,6 +25,15 @@ class views_handler_field_node_link_delete extends views_handler_field_node_link
+    if(count($this->view->result) == 1 && $this->view->query->offset >= $this->view->query->limit){
+      $destination = drupal_get_destination();
+      $url_query = parse_url($destination['destination']);
+      parse_str($url_query['query'], $url_data);
+      $url_data['page'] = $url_data['page'] - 1;
+      $destination['destination'] =  $url_query['path'] . '?' . http_build_query($url_data);
+      $this->options['alter']['query'] = $destination;
+    }

This is probably the case in many other situations (like comment delete etc.) so what about make this more generic and move this to a function? Additional: this really needs some documentation what is the problem and how we fix it. (I understand that, but many others won't)

hi,

@ycshen, your patch is very useful.
I follow your patch add a option that user can choose whether enable this function. Maybe we can let user to choose it. That's friendly.

Cheers.

I tried the above patch (7) and it didn't really help my use case (perhaps I'm not using it correctly?). I'm trying to redirect users back to their main organic group page when they delete og content. So I ended up modifying views_handler_field_node_link_delete.inc

if(isset($node->og_group_ref['und'][0]['target_id'])){ 
    $this->options['alter']['query']['destination'] = 'node/'.$node->og_group_ref['und'][0]['target_id'];
}else{
//ORIGINAL
    $this->options['alter']['query'] = drupal_get_destination();
//END ORIGINAL
}

I'm wondering if maybe the destination parameter could(should?) be set in the Views UI using tokens?...or if perhaps my use case is too marginal for such a major overhaul.

Thanks for the quick reply ycshen.

I forgot to mention something that may make my use case even more marginal (and a bit different from yours) so i'll explain in a bit more detail in case its relevant for you or anyone else.

When I tried the patch using delete_get_destination (without my og modification above), I was redirected to my default 404 page after deleting a node...which is what also happens when I use the original views code with drupal_get_destination. This is almost certainly because I am using a content pane view to generate custom buttons (including delete) for users, and embedding that button view in a node_view panel.

You can correct me if I'm wrong here but I *think* in both cases (drupal and delete) the destination parameter tries to return to the node page (rather than a view page as in your case which would be more the norm) that has since been deleted. I tried modifying delete_get_destination when I applied the patch with a "page-2" but got the same result so I went with my og customization + the original code to try and keep it simpler. I suggested the use of a customized destination parameter in case others have a similar use case because in my case I could then just get the og_group_ref in a hidden field of the view, and put it in as a token in a customized destination parameter....which is essentially what i'm doing in my customized handler.

Let me know if any of that doesnt make sense and i'll try to explain it a little better...but given that info do you think delete_get_destination would be useful in my case? I'm happy to test this further or perhaps help a bit with the code if I can. Thanks again

Hi ycshen,

So basically the url before delete is /node/123. I hit delete to delete /node/123. Then either drupal_get_destination or delete_get_destination tries to return me to /node/123...which I just deleted. So I added

if(isset($node->og_group_ref['und'][0]['target_id'])){ 
    $this->options['alter']['query']['destination'] = 'node/'.$node->og_group_ref['und'][0]['target_id'];
}

to the original views_handler_field_node_link_delete.inc to return the user to the main og group page (node/12 for example) after they delete /node/123. This works just fine and I dont need to change it...I am just suggesting that adding a feature to the patch that allows one to set a custom destination in the views UI might be useful to others as well.

Thanks for the offer to assist and your work on the patch!

cheers,
el

There is another bug report, #1009646: Rendered links token replacement URL encoding is broken which contains a much simpler fix for this problem. The patch in #24 was written to fix a bug in token substitution, but it also fixes the destination and edit link with pager bug described here.

Closing in favor of issue #1009646: Rendered links token replacement URL encoding is broken