[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