Contact Form Block: Prevent removal of the submit button

[vykes-mac]

Fixes #16303

Changes proposed in this Pull Request:

This PR aims to make the user experience better when using contact form blocks by removing the ability remove the submit button, since the button naturally is a required component of a contact form for this we:

• add the attribute lock { remove: true} to the submit button on each variation of a form. This makes it unable to remove the button for newly added forms.
• programatically find existing forms on a page and update the submit button attributes to prevent removal. This handles the case for users with existing forms.

Limitations:

The user can unlock the button and uncheck prevent removal and remove the button, but I think this might serve as an indicator to the user that this button shouldn't be removed. If they do remove the button they will find there's no other way to added it back and recreate the form at which point the button will be locked from removal again.

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?

Jetpack product discussion

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

Testing instructions:

1. Set up a Jurassic Ninja site.
2. Connect it to WP.com.
3. First create/save a post with a form block without these changes.
4. Apply changes then visit the post and verify that the option to remove the form button is no longer present.
5. Add a new form to the post and verify that the option to remove the button is no present.

Before

After

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello vykes-mac! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D83186-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[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: July 5, 2022.
• Scheduled code freeze: June 28, 2022.

[coder-karen]

In testing (on a JN site and locally) I found that a form block added before the feature branch was enabled still allowed me to remove the button.

The option suggested in this comment looks like it just prevents the remove button link from working. I experimented with this a bit but couldn't actually get the functionality to work either - I'm wondering if that's why the lock option was chosen? I did find the UI for the lock / unlock option a little confusing, though it does make it that little bit harder to accidentally remove the button which is helpful.

[vykes-mac]

@coder-karen

In testing (on a JN site and locally) I found that a form block added before the feature branch was enabled still allowed me to remove the button.

Can you test this again? I wasn't checking that an actual form exists before unsubscribing so the logic to update the button didn't got executed.

I'm wondering if that's why the lock option was chosen? I did find the UI for the lock / unlock option a little confusing, though it does make it that little bit harder to accidentally remove the button which is helpful.

Yes, I played around with the the reseting the blocks to previous state if remove button was click but as you said it only disable the button and not remove it, which might be more confusing to users. I think the lock feature is less destructive or hacky as it's a provide block api feature. Also we could set lock:true on the global parameters for the jetpack button which would remove the lock icon from the block options, this means users wouldn't be able to unlock the button. The downside to that is all jetpack button added would be locked and cannot be unlocked which might spell problems even though it seems those buttons are not insertable blocks but has to be added programatically.

[jeherve]

If you'd like to start loading js on the frontend whenever the form block is added to a post / page, you would need to also rely on Jetpack_Gutenberg::load_assets_as_required() in PHP to ensure the js gets loaded on the frontend.

That said, I'm thinking we may not need to add this to the frontend, right? It should be enough to load this in the editor.
In this case, I would recommend that you move the code from view.js to edit.js.
This will have the added bonus of not having to load @wordpress/data on the frontend.

[vykes-mac]

That said, I'm thinking we may not need to add this to the frontend, right?

Yes this is not needed in the front-end only the editor. It's purpose is to update existing form blocks to remove the delete option for the submit button.

In this case, I would recommend that you move the code from view.js to edit.js.
This will have the added bonus of not having to load @wordpress/data on the frontend.

Thank you for the suggestion, this make sense since this piece of code is not needed in the front-end. I will update accordingly.

[coder-karen]

Tested again after those changes and I notice the lock option is now showing for form buttons added prior to this PR.

I notice you have a 'needs team review' label this time rather than 'needs review' so I've left that in case you are looking for a review from your team too.

Changes have been made.

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D83186-code, and deploy it.
Once you've done so, come back to this PR and add a comment with your SVN changeset ID (e.g. r12345-wpcom).

Thank you!

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello vykes-mac! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D83614-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[coder-karen]

r248397-wpcom