Not being redirected after node creation or edit [#513322]

I've created a custom content type in a module I have built, using AHAH and the AHAH helper module. After creating or editing a node, I'm not being redirected to the node view page, rather I'm left on the same page that I used to either create or edit the page.

I have tracked it down to using this code:

function to_do_form_alter(&$form, $form_state, $form_id)
{
	if($form_id == 'to_do_node_form')
	{
		ahah_helper_register($form, $form_state);
	}
}

Wehn I comment out this code, I am brought to the node view page, so something in ahah_helper_register is causing my form not to bring me to the node view page. Is there a way to fix this?

Comments

Comment #1

jaypan

Victoria, BC

commented 8 July 2009 at 07:28

I figured out that I can fix this by using drupal_goto at the end of hook_insert() and hook_update() and everything *seems* to work well so far. I haven't figured out if there are any underlying problems yet though, so if someone knows a better way to do this, I'd be happy to hear.

Comment #2

grahamgilchrist commented 4 August 2009 at 09:38

I also have this error when using the form_alter hook on the user-registration page. There is no redirect at the end, so on successful registration the user is returned to the same page. I think it's got something to do with the ahah_helper_render resetting the form['#redirect'] value and then caching this new form?

Comment #3

aaronbauman

he/him

commented 22 September 2009 at 16:21

Priority:

Normal

» Critical

Since this breaks expected core functionality, i'm raising this to critical.

As far as I can tell, Drupal is skipping the redirect in function drupal_process_form around line 448 of include/form.inc:

      // If no submit handlers have populated the $form_state['storage']
      // bundle, and the $form_state['rebuild'] flag has not been set,
      // we're finished and should redirect to a new destination page
      // if one has been set (and a fresh, unpopulated copy of the form
      // if one hasn't). If the form was called by drupal_execute(),
      // however, we'll skip this and let the calling function examine
      // the resulting $form_state bundle itself.
      if (!$form['#programmed'] && empty($form_state['rebuild']) && empty($form_state['storage'])) {
        drupal_redirect_form($form, $form_state['redirect']);
      }

Apparently, Drupal thinks that the form submission was called from drupal_execute and refrains from redirecting.

In my case, the node form has an ahah_helper field on it, and this conditional is always returning false, preventing the redirect. In my case, it's because $form_state['storage'] is always set.

Is this an issue with ahah_helper, or an issue with my usage of ahah_helper?

Comment #4

Rok Žlender commented 28 September 2009 at 18:47

I don't really understand the issue here. The way I use AHAH and ahah helper module is in cases when I want user to stay on the page and not redirect them. If I want to redirect users on submission I just use regular Drupal form submission. Can you explain what you are trying to achieve from users perspective.

Comment #5

aaronbauman

he/him

commented 28 September 2009 at 18:54

Rok:
Consider Drupal's out of the box behavior on a node form:
After saving a new node or editing a node, the user is redirected to the node view.

The issue describe herein breaks that functionality, causing the user not to be redirected after the form submit.

Regardless of whether there are AHAH elements on the form, the core forms API redirect functionality should not be interfered with.

Comment #6

muhleder commented 8 October 2009 at 09:19

I'm seeing this too, the problem as mentioned above in #3 is that $form['storage'] is set, and this prevents $form['redirect'] from being respected in includes/form.inc

This is the proper behaviour when an ajax call is being made, but not when the form is being finally submitted. We should probably unset $form['storage'] if the form submission is not an ajax call.

I've got some code in a custom module which implements this for my specific case, not fully tested yet but seems to work. Not sure what the correct changes to ahah_helper.module would be.

Comment #7

jaypan

Victoria, BC

commented 21 October 2009 at 05:01

I want to add to some new discoveries I have made on this subject. I previously posted that this issue could be worked around by using drupal_goto() at the end of hook_update() and hook_insert(). However, I have recently started adding hook_node_access_records() to my module. This hook is necessary if you want to have any kind of granular access on who can and can't see a particular node. Any access module - Node Access, Domain Access, OG etc, uses this hook to set permissions on per node basis, and some modules (such as the one I'm creating), will also set permissions on a per node basis.

The problem here is that hook_node_access_records() is called after hook_insert() [or hook_update() if updating the node]. So if drupal_goto() is entered at the end of these functions, hook_node_access_records() is not entered, and the per node security settings are not set, meaning that people who should be able to see the node, cannot.

The problem is that I can't set drupal_goto() at the end of this hook, because unlike hook_insert() and hook_update(), this hook requires a value to be returned, and using drupal_goto() would prevent that value from being returned.

So this redirect bug has become a much bigger issue to me now. When a user creates a new node, they always end up back on the node creation page, instead of being able to see the node they created. This isn't the expected behavior, so I would really like to fix this. I will see if I can find a work around myself, but I don't know the inner workings of the AHAH Helper module, so I don't know if I will be able to discover anything.

Comment #8

jaypan

Victoria, BC

commented 21 October 2009 at 07:45

Well, I found a way around this. It's not ideal, as I am having to bypass Drupal altogether to do it, but it works, and right now that is most important to me.

What I have done is at the very end of hook_node_access_records(), I set a session variable:

<?php
  $_SESSION['node_redirect'] = $node->nid;
?>

Then at the top of my hook_form(), I do a check for that session and if it exists, it unsets the variable, then redirects:

<?php
hook_form(&$node, $form_state)
{
  if(isset($_SESSION['node_redirect']))
  {
    $destination = 'node/' . $_SESSION['node_redirect'];
    unset($_SESSION['node_redirect']);
    drupal_goto($destination);
  }
}
?>

This works, because the session is set at the end of the hooK_node_access_records(), which I believe is the last spot that we as developers have access to before being redirected. And since the bug in the system is causing the user to remain on the node creation form after submission, the session variable is the first thing the system comes across when it tries to reload the form. Snce the session variable is there, it redirects the user to the node display page.

But again, it's a hack, since it's not using the Drupal system. If anyone can come up with the proper way to do this, that would be great.