API page: http://api.drupal.org/api/drupal/includes%21form.inc/function/drupal_bui...

Enter a descriptive title (above) relating to drupal_build_form, then describe the problem you have found:

The description of the $form_state['rebuild'] should read "However, a validation handler may already set $form_state['rebuild'] to cause the form processing to bypass submit handlers and rebuild the form instead, when there are no validation errors."

Instead of "However, a validation handler may already set $form_state['rebuild'] to cause the form processing to bypass submit handlers and rebuild the form instead, even if there are no validation errors."

Since the form is not rebuilt if there is a validation error. The current description implies that the form will be rebuilt whether or not a validation error occurs.

Comments

jhodgdon’s picture

Title: $form_state['rebuild'] description » $form_state['rebuild'] description is confusing in drupal_build_form()
Version: 7.x-dev » 8.x-dev
Issue tags: +Needs backport to D7

Well, I think the "even if" was meant to imply "Normally, a validation handler only takes and action if there is a validation problem, but in this case, even though there is no validation problem, it has taken an action". I agree that the wording could be improved though. I'm not sure the suggested wording is the best idea though? Maybe we should just take out the "when there are no validation errors" clause?

In any case, it needs to be fixed in 8.x first and then backported when that fix is accepted.

lemming’s picture

I'm okay different wording as long as it makes it clear that the rebuilt only occurs when there are no validation errors.

I've found that when there is a validation error, the form does not get rebuilt, regardless of how this flag is set. This is confirmed by the logic in the drupal_process_form() function starting line 925

    if (($form_state['rebuild'] || !$form_state['executed']) && !form_get_errors()) {
      // Form building functions (e.g., _form_builder_handle_input_element())
      // may use $form_state['rebuild'] to determine if they are running in the
      // context of a rebuild, so ensure it is set.
      $form_state['rebuild'] = TRUE;
      $form = drupal_rebuild_form($form_id, $form_state, $form);
    }

The current wording "even if" implied that the rebuilt action would be taken, despite valiation errors. It needs to be clear that rebuild only happens if no validation errors occurred. Unless of course, the behavior gets changed in Drupal 8.

jhodgdon’s picture

Ah, I did not know that! Thanks for the detective work.

So... This whole description of the rebuild parameter is very awkward. Maybe we can make it all clearer?... I think the word "already" is throwing me off -- can we get rid of that and/or rewrite the whole sentence so it is both correct and clear?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jp.stacey’s picture

Issue summary: View changes
Issue tags: +SprintWeekend2017

Is FormState::$rebuild the equivalent to $form_state['rebuild'] in 8.x?

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Fo...

It looks like the equivalent logic to that quoted in comment #2 is around line 616 in FormBuilder:

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Form%21Fo...

i.e:

if (($form_state->isRebuilding() || !$form_state->isExecuted()) && !FormState::hasAnyErrors()) {
  /* ... */
}

There's a large comment block immediately before this logic, which I think is trying to solve the same thing as the original documentation bug reported.

Because form state has become an object with behaviours, I think 8.x and 7.x need different strategies:

8.x:
1) Improve the docblocks of FormState::setRebuild() / FormState::isRebuilding() to explain more about the parameter, but that it's basically a "dumb" property with no behaviours of its own, adding a @see FormBuilder::submitForm to reference the actual behaviour.
2) Improve the comment block immediately before that logic, to explain what the logic is doing and @see FormState::...

7.x:
1) Improve the docblock of drupal_build_form() based on 8.x's improvements.

jp.stacey’s picture

Version: 8.2.x-dev » 8.4.x-dev

Sorry, I should add: does that analysis make sense? Moving this to 8.4.x

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

wdseelig’s picture

This is old [Drupal 7], but should be said somewhere.

If you set $form_state['rebuild'] to TRUE in your submit routine, then a return from that routine WILL cause the form to be rebuilt [i.e., your mymodule_form($form, &$form_state) function will be re-run. HOWEVER, $form_state['rebuild'] will be set to FALSE before you do this rebuild. So if you want to change the way the form looks on a rebuild, you have to test something other than $form_state['rebuild']. In my use case, I'm testing $form_state['input']['mytextfield'] to see if I'm building for the first time or rebuilding.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.