-
Notifications
You must be signed in to change notification settings - Fork 804
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Contact Form Block: Prevent removal of the submit button #24838
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
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. Jetpack plugin:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
…available in editor
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.
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 |
@@ -16,6 +16,7 @@ import deprecated from './deprecated'; | |||
import edit from './edit'; | |||
import transforms from './transforms'; | |||
import variations from './variations'; | |||
import './view'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
…ng on the front-end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Great news! One last step: head over to your WordPress.com diff, D83186-code, and deploy it. Thank you! |
Caution: This PR has changes that must be merged to WordPress.com |
r248397-wpcom |
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:
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.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:
Jetpack product discussion
Does this pull request change what data or activity we track or use?
Testing instructions:
Before
After