Why is "destination" added to admin page URLs?

Ah, wrote a long answer to this, but got logged out - drats!

We'll to cut it short: will fix.

Thanks, I will commit a update to the CVS that renames the current url_data "Go to" handler to "Go to and return" and adds a new "Go to" handler that doesn't append a destination parameter. Cobalt will now also learn both which actions you usually use, and what actions you use with a specific item.

Ah, well, here comes the long explanation then. I've not actually used admin menu, for obvious reasons :), but I've seen it used. My guess is that it always just links to the menu-items, without adding a destination parameter, ever. That was the way I did with Cobalt at first, but I found that people (colleagues) often expected the chosen action to be performed, and then they should end up in the same place they started out. This is most obvious when you empty the cache, tweak permissions, rebuild permissions and all such stuff. So I, rather naively, added the destination parameter to all url_data items. That works fine in most cases, but as you've discovered it kinda breaks admin/content/node.

My solution to this is _not_ to dump the destination functionality and go back to the do naathing approach. Neither do I want to hard-code mappings between paths and Cobalt handlers. What I do is instead to allow Cobalt to learn from what you do, in two levels. If you choose to use the plain "Go to" handler more often than the "Go to and return" counterpart, then it will be used as your default handler for all items that Cobalt doesn't know your preference for. This is overridden by your most usual choice for a specific item.

So say that you use "Go to" a couple of times, then Cobalt will stop giving you "Go to and return" as the default and start suggesting "Go to" instead. If you then execute "Empty cache" with "Go to and return" Cobalt will remember that, but it will still go on and suggest the "Go to" handler for other items as long as it's the most used handler.

This is what's implemented right now, in version 6.x-1.2. I feel that I would like to revise the "learning" implementation at a later stage. Maybe exhanging "used most often" to "used last" for specific items. I guess that the overall "most popular" learning implementation also has a bit too much inertia, and will need to take time into account.

I think it's often a good thing that it redirects because Cobalt is often about performing actions rather than visiting pages - and after I've performed an action I would like to be back where I started if that's possible

Just a random thought from me on this issue