Update Text Field block so that it doesn't render a shortcode

[talldan]

This PR isn't intended to be merged. This is the first attempt at a proof of concept for #41840. The code is a little messy in places, and it ideally needs some tests! If we want to proceed with this approach, I think it'd be best to break this up into 2-3 smaller PRs where it's possible to focus more on code quality, testing and thorough review.

This demonstrates the possibility for a field block to no longer depend on shortcode rendering.

The good news:

Migrating individual blocks like this should be fairly straightforward once a foundation is put in place.

The bad news:

The form submission and verification code was fairly deeply coupled to the idea of all form fields being shortcodes, I had to refactor a significant part of it to remove its dependency on Contact_Form and Contact_Form_Field shortcode classes. The reasoning is explained some more in this comment - #41840 (comment).

Things that haven't been addressed in this PR:

• The text field doesn't implement the animated/outlined style. It will add some more complexity to the block's render callback, but it should be trivial to implement. I haven't done it as I wanted to take the fastest path to a working proof of concept for this PR.
• I've only really tested this using posts. It may or may not work for templates, template parts, and widgets which all use a slightly different id system for forms. I expect this won't be an issue to implement, it's just a fair amount of boilerplate, and it takes some time to test it all.
• I still need to test that standalone shortcodes still work normally
• There are a lot of places where I added phpcs:disable WordPress.Security.NonceVerification.Missing without checking. Just like the code in trunk.
• I haven't touched any tests, so they're expected to fail.

Proposed changes:

• The Text Field block is moved to its own folder - projects/packages/forms/src/blocks/field-text/class-field-text-block.php
  • The PHP render code is added to the block render callback, it no longer calls Contact_Form::parse_contact_field. I've copied mostly what the shortcode does, but the code itself is a little different.
  • The JS code changes are quite minimal, it's mostly just moving code around.
• Rather than the Contact_Form class handling form submission, this is now handled by a new Contact_Form_Submission class.
  • In trunk right now, the Contact_Form class handles submissions, and it gathers submission values and errors from every instance of a Contact_Form_Field.
  • This isn't possible for blocks, so in this PR, during submission a Contact_Form_Submission instance is created, and all fields add their values and errors to this submission instance.
  • The process_submission method is moved from Contact_Form to Contact_Form_Submission, and it now interacts with these stored values/errors, instead of trying to retrieve them from the Contact_Form and Contact_Form_Field classes. A lot of this is copy/paste. Several utility functions are also moved over.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

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

Testing instructions:

• Go to '..'

[github-actions]

Are you an Automattician? The PR will need to be tested on WordPress.com. This comment will be updated with testing instructions as soon the build is complete.

[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 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.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen semi-continuously (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly. The next release is scheduled for none scheduled (scheduled code freeze on undefined).

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Cannot generate coverage summary while tests are failing. 🤐

Please fix the tests, or re-run the Code coverage job if it was something being flaky.

Full summary · PHP report · JS report