Enable Jetpack Forms package by default

[ice9js]

Proposed changes:

Once #28752 is merged, we'll have migrated all contact form related code to the new automattic/jetpack-forms package. In order to not have to maintain multiple codebases, we'd like to make the package the new default with the existing module becoming deprecated and eventually removed - possibly in the following jetpack version once we've confirmed everything is running smoothly.

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

pcsBup-N3-p2

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

No.

Testing instructions:

This PR doesn't contain any user facing changes, that's said it's good to check some of the following:

• Contact form blocks should still load as expected in the editor.
• Submitting feedback or contact form responses should still work correctly.
• You should be able to access the submitted responses in WP Admin under Feedback.

[github-actions]

Are you an Automattician? You can now test your Pull Request on WordPress.com. On your sandbox, run

bin/jetpack-downloader test jetpack update/enable-jetpack-forms-package

to get started. More details: p9dueE-5Nn-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.
  
• ✅ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ 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.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: June 6, 2023.
• Scheduled code freeze: May 29, 2023.

[jcheringer]

Added a small comment regarding the flag we use to control the registration of the blocks in the editor.

[jcheringer]

Not sure if there's a way we can make the filter always return true by default, otherwise we'll also need to change the default value here: https://github.com/Automattic/jetpack/blob/trunk/projects/plugins/jetpack/class.jetpack-gutenberg.php#L695

The line above allows us to control whether we want to register the blocks from the jetpack plugin or the blocks from the Forms package.

[CGastrell]

Might turn into a race condition. I think we should add somewhere at the top add_filter( 'jetpack_contact_form_use_package', '__return_true' );, but it would also be legal to get that line inside this if, so, if nobody has a saying on it, we'll enable it for all subsequent calls:

if ( apply_filters( 'jetpack_contact_form_use_package', true ) ) {
  Jetpack_Forms::load_contact_form();
  add_filter( 'jetpack_contact_form_use_package', '__return_true' );
  return true;
}

[ice9js]

Not sure I understand what you mean 🤔 Wouldn't simply changing the other line you linked to to true as well so it's consistent fix the issue?

[CGastrell]

What I'm saying is: there's no function handling the filter, we just trust the default value we assign during the apply_filters call. So, who/where is it decided that this filter returns true|false?

So, yes, @jcheringer solution is valid, but both calls to apply_filters rely on the default value, hence my question: where is this actually decided? And if the answer is "still nowhere", then make it a single point of entry and once the first apply_filters is run, add a listener/handler for any other subsequent calls. Next time, instead of having to change this in two places, you'd only do it on a single change.

It might also be the case that the two calls to apply_filters are completely independent and need to remain that way, then it makes sense to call it twice and provide a true by default.

[jcheringer]

LGTM!

[jeherve]

Before we flip the switch, I wonder if we should plan some kind of wider testing, at 2 levels:

• At the release level, to ensure that the package and its assets are correctly enqueued / shipped from their new location.
• At the WordPress.com Simple and WoA levels. They'll be the first ones to get the update, as early as next week if we merge this in the next few days. Maybe there could be a call for testing before that happens, to ensure we're not breaking anything?

What do you think?

[CGastrell]

It does what it says

[ice9js]

Following a the call for testing (pcsBup-V4-p2), we've been running from the package on WP.com since March and I believe all remaining glitches that we were aware of have now been fixed. So I think we can merge this now :)