Forms: Require at least one field

[lezama]

Fixes #11886

Background

Currently, contact forms can be submitted with all fields empty, even non-required fields. This leads to empty form submissions that provide no value and potentially waste storage space.

Changes proposed in this Pull Request

• Adds an optional "Require at least one field" setting in the block editor's Submission Settings panel
• When enabled, validates that at least one field has been filled out before form submission
• Displays a user-friendly error message when attempting to submit a completely empty form
• Error message states: "Please fill out at least one field."
• Adds data-require-one-field attribute to the form element to control this behavior

Testing instructions

1. Add a contact form to a post/page with multiple non-required fields
2. In the block editor sidebar, under "Submission Settings", locate the "Require at least one field" toggle
3. Enable the toggle and save the form
4. Try to submit the form without filling out any fields
5. Verify you see the error message "Please fill out at least one field"
6. Fill out at least one field and submit
7. Verify the form submits successfully
8. Test different combinations of fields types
9. Disable the toggle and verify empty submissions are allowed again

Screenshots

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WordPress.com Simple site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin, and enable the update/forms-require-one branch.

• To test on Simple, run the following command on your sandbox:

  bin/jetpack-downloader test jetpack update/forms-require-one
  

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• 🔴 Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• 🔴 Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ Add testing instructions.
  
• 🔴 Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so:

## Does this pull request change what data or activity we track or use?

My PR adds *x* and *y*.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Choose a review path based on your changes:
   • A. Team Review: add the "[Status] Needs Team Review" label
     • For most changes, including minor cross-team impacts.
     • Example: Updating a team-specific component or a small change to a shared library.
   • B. Crew Review: add the "[Status] Needs Review" label
     • For significant changes to core functionality.
     • Example: Major updates to a shared library or complex features.
   • C. Both: Start with Team, then request Crew
     • For complex changes or when you need extra confidence.
     • Example: Refactor affecting multiple systems.
3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

[github-actions]

Code Coverage Summary

Coverage changed in 2 files.

File	Coverage	Δ%	Δ Uncovered
projects/packages/forms/src/contact-form/js/accessible-form.js	175/378 (46.30%)	-0.80%	12 💔
projects/packages/forms/src/blocks/contact-form/edit.js	0/39 (0.00%)	0.00%	1 💔

Full summary · PHP report · JS report

[enejb]

This Pr doesn't work for me as expected.

I created a form but when I submit it nothing happens. I don't the the expected error. 🤔
You can find it here - https://enejdev.jurassic.tube/2025/01/28/all-fields-but-non-are-required/

[edanzer]

We update tests in this PR, and I see some failures on the PR checks. I didn't dig into it, but looks like we do introduce some issues. I navigated to projects/packages/forms, and ran composer test-php.

For this branch, results are:

FAILURES!
Tests: 58, Assertions: 211, Failures: 4, Skipped: 4.

For trunk, results are:

OK, but incomplete, skipped, or risky tests!
Tests: 58, Assertions: 218, Skipped: 4.

[edanzer]

This Pr doesn't work for me as expected.

I created a form but when I submit it nothing happens. I don't the the expected error. 🤔 You can find it here - https://enejdev.jurassic.tube/2025/01/28/all-fields-but-non-are-required/

There's a console error on this site when I try to submit. That may be the issue.

Uncaught TypeError: input.value is undefined
    hasAnyFieldValue accessible-form.js:63
    hasAnyFieldValue accessible-form.js:59
    onSubmit accessible-form.js:96

[lezama]

After further consideration and testing, I've made some significant changes to this implementation:

1. Made the "require at least one field" validation opt-in via a new toggle in the block's Submission Settings panel
   - This addresses potential backward compatibility concerns with existing forms

   • Gives form creators explicit control over this validation requirement

2. Simplified the implementation to focus on client-side validation first

   • Currently works with standard input fields (text, email, url, etc.)
   • The validation is controlled by the data-require-one-field attribute on the form
   • We can expand support for more complex field types in future iterations

3. Decided to defer PHP validation to a future PR

   • This keeps the current changes contained and easier to review/test
   • Allows us to gather real-world usage data before adding server-side complexity
   • Gives us time to properly consider how to handle different field types on the server side

I believe this approach provides a better balance between functionality and compatibility. We can iterate on both field type support and server-side validation based on user feedback and real-world usage patterns.

@Automattic/zap Would appreciate feedback on this direction, particularly regarding the opt-in approach vs. making it a default behavior.

[simison]

Made the "require at least one field" validation opt-in via a new toggle in the block's Submission Settings panel

• This addresses potential backward compatibility concerns with existing forms
• Gives form creators explicit control over this validation requirement

Can you elaborate on the concerns about backward compatibility? I'm not big fan of adding options where there could be smart defaults. :-) In what scenario users would likely disable the toggle?

[lezama]

In what scenario users would likely disable the toggle?

I imagine a form with pre-selected checkboxes. For a case like this, we’ll need a more elaborate check.

[simison]

Forms like below?

We still shouldn't offload that responsibility to make the form function as expected to the user? Seems fine if for now we let pre-checked inputs "validate" empty forms, and we can create separate checks for that later, too.

[lezama]

A workaround could be to require a field only when input fields only are present.