Problem

  • Many form submission handlers are manually calling into form_state_values_clean() today.

Goal

  • Simplify form handling.

Proposed solution

  1. Make Form API call form_state_values_clean() before executing form submit handlers.
CommentFileSizeAuthor
#15 form-1729882-15.patch9.14 KBtim.plunkett
#10 drupal8.form-state-values-clean.10.patch25.19 KBsun
#8 drupal8.form-state-values-clean.8.patch25.25 KBsun
#6 drupal8.form-state-values-clean.6.patch22.07 KBsun
#4 drupal8.form-state-values-clean.4.patch17.79 KBsun
#1 drupal8.form-state-values-clean.1.patch5.38 KBsun

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Assigned: Unassigned » sun
Status: Active » Needs review
StatusFileSize
new drupal8.form-state-values-clean.1.patch5.38 KB

Let's see what breaks.

I know for sure that Taxonomy has at least 1-2 stone-age submit handlers that are still checking for 'op' instead of using dedicated #submit handlers.

Status: Needs review » Needs work

The last submitted patch, drupal8.form-state-values-clean.1.patch, failed testing.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Almost all of the test failures are expected — "Undefined index: op" — those can be fixed very easily.

There's one nasty surprise though: The Views "wizard" multistep form implementation seems to depend on 'op', too... that might take more time to refactor :-/

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs work » Needs review
StatusFileSize
new drupal8.form-state-values-clean.4.patch17.79 KB

Attached patch fixes most of the test failures.

Status: Needs review » Needs work

The last submitted patch, drupal8.form-state-values-clean.4.patch, failed testing.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs work » Needs review
Issue tags: +VDC
StatusFileSize
new drupal8.form-state-values-clean.6.patch22.07 KB

Attached patch should resolve the Views UI failures.

Apparently, the Views Wizard plugin already contained a @todo about some weird validation logic in there. Resolved that while being there.

Status: Needs review » Needs work

The last submitted patch, drupal8.form-state-values-clean.6.patch, failed testing.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs work » Needs review
StatusFileSize
new drupal8.form-state-values-clean.8.patch25.25 KB

Fixed Form\ProgrammaticTest.

Status: Needs review » Needs work

The last submitted patch, drupal8.form-state-values-clean.8.patch, failed testing.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Needs work » Needs review
StatusFileSize
new drupal8.form-state-values-clean.10.patch25.19 KB
dawehner’s picture

dawehner
Primary language German
commented 
+++ b/core/includes/form.incundefined
@@ -732,13 +733,17 @@ function drupal_retrieve_form($form_id, &$form_state) {
+    try {
...
+    catch (DatabaseExceptionWrapper $e) {

What is the reason why catch DataBaseExceptionWrapper here? The usages i could found didn't used it.

+++ b/core/modules/dblog/dblog.admin.incundefined
@@ -370,21 +371,19 @@ function dblog_filter_form_validate($form, &$form_state) {
-  return 'admin/reports/dblog';

So we don't want to have a redirect anymore? Not sure whether return actually works but there is at least an intention to do so.

+++ b/core/modules/locale/locale.pages.incundefined
@@ -211,6 +211,7 @@ function locale_translate_filter_form($form, &$form_state) {
+      '#submit' => array('locale_translate_filter_form_reset_submit'),

Is there a fundamental reason we have to change so much in this patch? Couldn't we just replace $op with using triggered element?

+++ b/core/modules/locale/locale.pages.incundefined
@@ -221,24 +222,19 @@ function locale_translate_filter_form($form, &$form_state) {
-  $form_state['redirect'] = 'admin/config/regional/translate/translate';

Also lost?

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/wizard/WizardPluginBase.phpundefined
@@ -47,11 +47,18 @@
+   * @var Drupal\views_ui\ViewUI

Oh i thought the standard now suggests to prepend the "\"

+++ b/core/modules/views/lib/Drupal/views/Plugin/views/wizard/WizardPluginBase.phpundefined
@@ -1098,45 +1105,6 @@ protected function set_override_options(array $options, DisplayPluginBase $displ
-    // @todo Figure out why all this hashing is done. Wouldn't it be easier to
-    //   store a single entry and that's it?

Yeah I totally think we can remove that now, as it's silly complicated stuff.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Thanks for reviewing!

re: Catching a database exception for menu_get_item() in drupal_retrieve_form():
This allows DrupalUnitTestBase to submit forms programmatically without having to install the {menu_router} & Co database schemata first.

The include file from the route definition is optional, and that was only added to support processing of cached forms, which may be re-retrieved on a different router path (e.g., /system/ajax).

re: Redirects in form submission handlers:
All of these filter forms actually do not want to redirect anywhere. They want to show the form on the same page they were displayed before.

And yeah, the instances that returned a path as string from the submit handler did not redirect anymore in the first place. That way no longer works since D6, I think.

re: Different button submit handlers:
I think we're generally moving towards separate button submit handlers. But as you probably noticed, I only figured out later when doing the patch that I could as well just replace $form_state['values']['op'] with $form_state['triggering_element']['#value']...

Don't have a strong preference there myself. Not sure whether it's worth to revert the button submit handler changes (and redo them in a separate issue).

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue tags: -API clean-up, -VDC

#10: drupal8.form-state-values-clean.10.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, drupal8.form-state-values-clean.10.patch, failed testing.

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Issue summary: View changes
Status: Needs work » Needs review
StatusFileSize
new form-1729882-15.patch9.14 KB

Reviving this.

Status: Needs review » Needs work

The last submitted patch, 15: form-1729882-15.patch, failed testing.

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.

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.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.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should 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.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should 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.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Needs work » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

smustgrave commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

Since there's been no follow up to above in 3+ months going to close out. If still a valid task please re-open

Thanks all!