Change default submit redirect to $_GET['q']

I can confirm this behavior, also happens at /admin/logs. I believe this would be the watchdog.module, though I didn't have time to track down the source of the problem. IMHO this needs to be fixed before 4.7 release so I'm bumping it to critical.

This is not the related with the watchdog.module as this was introduced with this patch http://drupal.org/node/49799

The problem is in form.inc::drupal_get_form()

...
  $form = form_builder($form_id, $form);
  if (!empty($_POST['edit']) && (($_POST['edit']['form_id'] == $form_id) || ($_POST['edit']['form_id'] == $callback))) {
    drupal_validate_form($form_id, $form, $callback);
    if ($form_submitted && !form_get_errors()) {
      $redirect = drupal_submit_form($form_id, $form, $callback);
      if (isset($redirect)) {
        $goto = $redirect;
      }
      // This redirects to the main page as '#redirect' is always set to an empty
      // string in system.module
      elseif (isset($form['#redirect'])) {
        $goto = $form['#redirect'];
      }
      else {
        $goto = $_GET['q'];
      }
      if ($goto !== FALSE) {
        if (is_array($goto)) {
          call_user_func_array('drupal_goto', $redirect);
        }
        else {
          drupal_goto($goto);
        }
      }
    }
  }
...

Here is the definition of '#redirect' for all forms.

/**
 * Implementation of hook_elements().
 */
function system_elements() {
  // Top level form
  $type['form'] = array('#method' => 'post', '#action' => request_uri(), '#redirect' => '');
...

So either remove the #redirect from system.module or change form.inc, however I've no time to investigate more deeply currentlty.

I assigned it to me to keep track of it. IMHO there should be the possibility to use '#redirect' = ''; to redirect to the very top of a domain.

This one is easy to solve.

Yes sure -- but it does not solve the general problem behind it, this is just a "hack" to solve the specific problem with watchdog.

Adding new modules without defining '#redirect' or returning the redirect in _submit it will always redirect to the main page.

which is just good. return FALSE if you do not want a redirect. more often you want than you don't.

What I actually mean is that it will redirect to the main page rather than to the page you were at.

Submitting something on http://example.com/foo/bar without having '#redirect' defined nor returning something in the _submit hook will redirect you to http://example.com/.

But it should really return to the page you were submitting from.

Here is another example http://drupal.org/node/50982

This patch would have fixed the above report as well without adding the "return 'admin/filters';".

I will talk to Adrian about changing the default return to $_GET['q'] but I am not for removing the default.

I agree, that would be the better alternative.

Reassigned to system.module

My friend, that's by far not enough.

Good work.

Could you review this part, please?

     db_query("UPDATE {users} SET login = %d WHERE uid = %d", time(), $user->uid);
 
     user_module_invoke('login', $form_values, $user);
+    // Redirect the user to the page he logged on from.
+    return '';
   }
 }

As the comment is confusing me -- the return will do the opposite of the comment, won't it?

TIAS. I mean, really, try it and you will see it works. (destination is set beforehands and request['destination'] overwrites whatever you hand to drupal_goto. if you want to experiment change that return to anything. it will just work.)

Actually I tried it (I would not review it ("Good work.") if I had not).

What I mean is not the user login block but (Sorry, I forgot to mention that)

1. Go to http://example.com/user
2. Enter your name/password and login
3. You get redirected to http://example.com/ instead of http://example.com/user (-> http://example.com/user/X)

As for my needs this is important; the login block is disabled on the productive site.

That's easy to mend. Please review whether the login block and the user/login page works both and the other forms I changed, too.

Tried patch.

http://localhost/~kieran/drupal/?q=user

Logged in.

Got redirected to: http://localhost/~kieran/drupal/?q=user/2

Ok. I've installed a fresh HEAD, created new user fromt scratch fine (apart from the duplicate system_update_173 but I gather there's another patch for that). Enabled every single module.

I created blogs, created comments, admin'ed comments, created taxonomies, edited the contact form, added a block, changed the theme, changed some settings pages, and even ran through an update (even though that made 10,000 errors ;)), created and edited users, logged out, and logged back in (both from user block and from the 'normal' user page). Probably some other stuff too. :P Basically I clicked on anything I could think of that was a form, and tried it to see if I got redirected. In all cases, the behaviour looked normal to me. I don't think I was ever redirected to the home page, apart from when I hit edit, then deleted a node (but that's expected behaviour).

Marking ready to commit.

Committed to HEAD. Thanks.