This may depend on #1606794: Implement new routing system, but I don't think it does.

As discussed in Munich, one of the improvements we're able to make with the new Symfony-based architecture is that we can detect form submissions in a kernel.request event listener. That listener can detect the presence of a POST request with form ID, load the appropriate form, validate, it, and submit it, all without triggering the Matcher, any controllers, etc. It ends by setting a redirect response object (based on the form), which neatly short-circuits all of the rest of the page.

If a form does not validate, then the listener can flag the invalid information and allow processing to continue, or else do a direct forward() to the normal controller. (Details to be worked out in implementation.)

That is only a small win for a form that's in the body of a page, but a huge win for forms that are in blocks. Of course, in the new model the page vs. block distinction should be going away, which makes this a win for any form.

Assigning to effulgentisa since he's one of the people that volunteered to work on this. :-)

Comments

sdboyer’s picture

i am very curious about the approach we take to this, as these seems to be one of the first places we'll be tackling a "short circuiting" router that circumvents much of the heavy matching/routing process. an obvious best-approach to doing so has not jumped out at me in the time i've spent thus far with the routing system. my criteria are, roughly speaking:

  • the approach must deterministically succeed at short-circuiting routing and taking over, but...
  • still "plays nice" with others to whatever extent necessary, probably by virtue of following a known pattern at a defined step in the routing process
Crell’s picture

Issue summary: View changes

Are we going to be able to do this? :-)

mgifford’s picture

Assigned: effulgentsia » Unassigned
pounard’s picture

This would mean anyone could be able to POST any form on any URL as soon as he/she knows the form ID, am I wrong or automating such this seems dangerous and may bypass a few access checks, that are mostly based upon URL or Controller ?

effulgentsia’s picture

Yes, I think the only way to do this would be to introduce access control on forms. See links in #1.

mgifford’s picture

@effulgentsia please feel free to assign it to yourself again. I was looking for issues that were largely inactive and had been assigned (but where no active development was being done).

Should this get moved to 8.1?

pounard’s picture

I don't think it would be such a good idea, processing forms on arbitrary URLs goes against REST etc... It may induce behaviors that would appear random to a lot of people and make things really hard to understand.

Crell’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

This could still be potentially useful, but I'm sure all of the metrics have changed in the last year based on the heavy rewriting of the render system.

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now 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.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.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.

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.