Problem/Motivation

Webform 8.x-5.x is using Drupal core's #states API to handle conditional logic, which is a client-side JavaScript library. Required element validation only occurs for browsers that support HTML5 validation. Conditionally required elements should also be validated using server-side validation

Proposed resolution

Add support for server side validation for conditionally required elements.

Remaining tasks

  • Create a server-side validation service.
  • Implement server-side validation
  • Write tests

User interface changes

None

API changes

  • Add WebformValidation service and interface.

Data model changes

None

CommentFileSizeAuthor
#2 webform-server-side-conditionals-2875949-0.patch19.73 KBmmaciusowicz-rr

Comments

jrockowitz created an issue. See original summary.

mmaciusowicz-rr’s picture

mmaciusowicz-rr commented
StatusFileSize
new webform-server-side-conditionals-2875949-0.patch19.73 KB

This is still work in progress, but this patch adds the basic elements of server-side conditional validation.

There is a new webform.conditional_logic_provider service, which contains methods for checking whether a given condition or a given state is applicable. The webform.form_validator decorator calls these to modify element arrays, adding properties that specify validation criteria, prior to the elements being validated.

This patch also addresses issue #2838651, as webform.conditional_logic_provider can also be used to decide, when modifications need to be made in render arrays for displaying fields.

Still to do:
- Add remaining conditional validation criteria (currently only "value" and "filled" available).
- Make the conditional checking work with draft submissions.
- Come up with and add tests.

jrockowitz’s picture

jrockowitz commented

I need sometime to review this code.

Some challenges....

  • Supporting composites (ie :input[name="address[city]"])
  • Custom select other elements (ie :input[name="select[other]"])

We might need to create \Drupal\webform\Plugin\WebformElementBase::getElementSelectorInputValue($element, $webform_submission, $selector) which parse the :input[name=""] selector and gets the value.

jrockowitz’s picture

jrockowitz commented

My general concern about implementing server-side conditional logic is that it is a critical features that needs to be completely thought out, easy to test, and easy to maintain. One of the biggest issues I see with contrib modules, is someone contributes a key patch and then they are not available to maintain the functionality. BTW, this why certain complex features like Webform Views integration is being developed outside the Webform core module.

I need to make sure all major features can be maintained by me. I am very open to people becoming Webform 8.x-5.x co-maintainers. Potential co-maintainers should start by working on small patches and minor API tweaks. For example, I would love it if @bucefal91 became a co-maintainer because he has helped out with many webform related issues and understands the APIs and design patterns.

@mmaciusowicz-rr I really appreciate your effort here but we need to start out small. If you are open to working with me, I can gradually start building out how we should implement this feature and you can help me work out the details.

For example, my first step would be to get an API that can take any jQuery element selector (ie :input[name="ELEMENT_KEY"]) and look up the submitted value. This API will have to have dedicated tests. (For example an see \Drupal\webform\Tests\Element\WebformElementStatesSelectorsTest). Once this is done, I would set-up a very simple example/test that starts to figure how to properly handle triggers and states using just the 'required' state triggered by a simple textfield 'value' or the 'filled' trigger.

Finally, adding server-side conditional logic is the next big feature I am planning on implementing. I hope to get it done by September/October.

jrockowitz’s picture

jrockowitz commented
Status: Active » Fixed

@see #2900719: Server side Conditional Logic using #states API

mmaciusowicz-rr’s picture

mmaciusowicz-rr commented

Firstly, thank you for all your work to resolve this issue.

I understand your point about being able to maintain the module in the long term and the concerns around accepting contributions to key parts of the module. There is naturally going to be a difference in the understanding of the module's mechanics between the creator or regular contributors and occasional contributors. I guess it is difficult to incorporate an occasional submission "as is", considering also the extra review effort, but it can still serve to demonstrate an approach, even if not fully refined, to solving the issue.

jrockowitz’s picture

jrockowitz commented

@mmaciusowicz-rr The approach in #2900719: Server side Conditional Logic using #states API examines the actual webform submission values and not the $form_state->getValue(). Being able to process conditional logic via the webform submission values will allow for conditional logic to be applied to webform handlers.

Your code was and still is potentially a generic server-side validator for #states, which could be built out in a separate module.

It is very tricky figuring out what is the best approach to contributing patches to modules. You took on a very very challenging task. It took me a year to finally do this work and I had made it my summer goal to complete it.

Any help is appreciated, start small, and don't hesitate to ask if you should take on a specific ticket. If you really want to be ambitious (and learn a lot) you should create some sandbox modules.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.