[drupal-devel] [task] usability: redirect to proper page after edit/delete operations

stefan nagtegaal drupal-devel at drupal.org
Wed Jan 26 21:44:44 UTC 2005


 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     tasks
 Priority:     normal
 Assigned to:  moshe weitzman
 Reported by:  moshe weitzman
 Updated by:   stefan nagtegaal
 Status:       patch

This is another great improvement when we look at usability! Moshe, you
did a terrific job on this..
After this patch is applied every submitted page drupal_goto()'s the
page you expect it to go..

This is really one of the best patches i'd seen and tested lately, so
++ for this patch in HEAD..

stefan nagtegaal



Previous comments:
------------------------------------------------------------------------

January 26, 2005 - 20:18 : moshe weitzman

Attachment: http://drupal.org/files/issues/drdest.patch (11.05 KB)

Here is a patch I've been wanting to finish for a while. This patch
assures that you end up on the proper page after you edit/delete a
node, comment, user, or url alias. This is true no matter if you go
through the usual interface or the admin interface. Further, if click
the 'edit' link from 3rd page of  a custom sorted view (e.g.
admin/comment&from=100&sort=asc&order=Author) you still are returned to
the right page.

The technique used here is generally available for module developers.
I've minimally enhanced drupal_goto() so that it will redirect to the
url specified in a 'destination' querystring parameter if such
parameter exists. If it does not exist, we redirect just as today. No
changes are required to existing drupal_goto() calls. A new helper
function, drupal_get_destination() was added; it helps contruct the
'destination' string which is appended to add/edit links.

The only downside I can see to this patch is that a few URLs are less
pretty than before. These urls are only shown to admins. This could
only be avoided by having each admin page implement its own way of
passing a destination, or stashing the destination in the $_SESSION. We
recently tried storing referer in $_SESSION, and it  was eventually
removed because of poor coordination when a user has multiple browser
windows open.

In addition to the above, 
- I cleaned up some 'destination' handling in user login code
- I assured that after adding a new taxo term, we arrive back on the
'Add' page. That restores prior behavior








-- 
View: http://drupal.org/node/16246
Edit: http://drupal.org/project/comments/add/16246





More information about the drupal-devel mailing list