-
Notifications
You must be signed in to change notification settings - Fork 842
Forms: Add form editor #46444
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
Forms: Add form editor #46444
Conversation
|
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 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! Jetpack plugin: No scheduled milestone found for this plugin. If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack. |
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.
Pull request overview
This PR introduces a dedicated form editor for the Jetpack Forms feature, providing a tailored editing experience when creating or editing forms via /wp-admin/post-new.php?post_type=jetpack_form. The functionality is gated behind feature flags (reusable-forms and central-form-management) and includes form locking, block nesting enforcement, and a rename command.
Key Changes
- New form editor with automatic form block creation and locking to prevent removal/movement
- Form rename functionality accessible via command palette when form block is selected
- Custom styling that hides post title, editor tabs, and adjusts block appearance for form editing context
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 16 comments.
Show a summary per file
| File | Description |
|---|---|
projects/plugins/jetpack/changelog/add-form-editor |
Changelog entry documenting the form editor addition |
projects/packages/forms/changelog/add-form-editor |
Package-level changelog entry |
projects/packages/forms/tools/webpack.config.form-editor.js |
Webpack configuration for building the form editor bundle |
projects/packages/forms/src/form-editor/use-form-rename-command.tsx |
Custom hook providing form renaming functionality via command palette |
projects/packages/forms/src/form-editor/style.scss |
Styling for form editor including tab hiding and rename modal |
projects/packages/forms/src/form-editor/index.tsx |
Main form editor logic for block locking, nesting enforcement, and category management |
projects/packages/forms/src/form-editor/class-form-editor.php |
PHP class managing allowed blocks, editor settings, and script enqueuing |
projects/packages/forms/src/contact-form/class-contact-form.php |
Adds template definition for jetpack_form post type |
projects/packages/forms/src/contact-form/class-contact-form-plugin.php |
Initializes Form_Editor when feature flag is enabled |
projects/packages/forms/src/blocks/shared/util/constants.js |
Adds FORM_POST_TYPE constant for consistent reference |
projects/packages/forms/src/blocks/contact-form/editor.scss |
Hides post title in jetpack_form editor context |
projects/packages/forms/package.json |
Adds form-editor build tasks and required dependencies |
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
Code Coverage SummaryCoverage changed in 3 files.
4 files are newly checked for coverage.
Full summary · PHP report · JS report If appropriate, add one of these labels to override the failing coverage check:
Covered by non-unit tests
|
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.
Pull request overview
Copilot reviewed 12 out of 13 changed files in this pull request and generated 9 comments.
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.
Pull request overview
Copilot reviewed 14 out of 15 changed files in this pull request and generated 8 comments.
projects/packages/forms/src/form-editor/use-form-rename-command.tsx
Outdated
Show resolved
Hide resolved
projects/packages/forms/src/form-editor/use-form-rename-command.tsx
Outdated
Show resolved
Hide resolved
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.
Pull request overview
Copilot reviewed 18 out of 19 changed files in this pull request and generated 7 comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
Comments suppressed due to low confidence (1)
projects/packages/forms/tests/js/form-editor/index.test.js:21
- The second test "should have a style.scss file" doesn't actually verify anything meaningful - it just checks that true equals true. This test should either be removed or replaced with a meaningful assertion that verifies the SCSS file can be imported or that its styles are applied correctly.
projects/packages/forms/src/form-editor/use-form-rename-command.tsx
Outdated
Show resolved
Hide resolved
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.
Pull request overview
Copilot reviewed 18 out of 19 changed files in this pull request and generated 3 comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
projects/packages/forms/src/form-editor/use-form-rename-command.tsx
Outdated
Show resolved
Hide resolved
The form editor now tracks and restores the previous block categories order when moving the Jetpack contact form category to the front and back. Tests were added to verify tracking, restoring, and fallback behavior for category management.
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.
Pull request overview
Copilot reviewed 16 out of 17 changed files in this pull request and generated 6 comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
| * @return True if the block should be locked | ||
| */ | ||
| export function shouldLockBlock( block: Block ): boolean { | ||
| const lock = block.attributes?.lock as { remove?: boolean; move?: boolean } | undefined; |
Copilot
AI
Jan 6, 2026
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.
The block lock type assertion is also present in the utility file. Consider defining the BlockLock type in the block-utils.ts file and exporting it for reuse, so both the utility and the main index file can use the same type definition, improving consistency.
| // Expected blocks - core blocks | ||
| $expected_core_blocks = array( | ||
| 'core/paragraph', | ||
| 'core/heading', | ||
| 'core/list', | ||
| 'core/list-item', | ||
| 'core/separator', | ||
| 'core/spacer', | ||
| 'core/columns', | ||
| 'core/column', | ||
| 'core/group', | ||
| 'core/image', | ||
| 'core/html', | ||
| ); |
Copilot
AI
Jan 6, 2026
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.
The PHP test file includes blocks like 'core/audio', 'core/row', 'core/stack', 'core/subhead', and 'core/video' in the allowed list (lines 88-103 of the PHP file), but these blocks are not included in the test expectations (lines 430-443 in the test file). The test should verify all allowed core blocks to ensure completeness.
Renamed asset files and script handles from 'jetpack-forms-editor' to 'jetpack-form-editor' for consistency. Improved TypeScript typing for block locking by introducing a BlockLock interface and updating related usages. Added asset file existence check and dynamic dependency loading in PHP registration.
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.
Pull request overview
Copilot reviewed 16 out of 17 changed files in this pull request and generated 5 comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
projects/packages/forms/tests/php/form-editor/Form_Editor_Test.php
Outdated
Show resolved
Hide resolved
….php Co-authored-by: Copilot <[email protected]>
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.
Pull request overview
Copilot reviewed 16 out of 17 changed files in this pull request and generated no new comments.
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
| } else if ( categoriesFiltered ) { | ||
| categoriesFiltered = false; | ||
| moveFormsCategoryBackToOriginalOrder( previousCategories || [] ); | ||
| } |
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.
Do we need to 'undo' the unregisterPlugin() call? I think in most cases if you navigate to a different block editor, this should reload/reset, but I'm not 100% sure.
| $screen = get_current_screen(); | ||
|
|
||
| // Only load in block editor contexts, not site editor | ||
| if ( ! $screen || $screen->id === 'site-editor' || ! $screen->is_block_editor ) { |
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.
Do we want to only be loading this JS when post_type === jetpack_form? I think that's also possible with the $screen var.
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 my testing when I do that (limit by post type) then the switching in the block editor (clicking the edit form button) doesn't quite work as expected.
But since this feature doesn't load on the site-editor removing the script from the site editor is fine.
| "type": "module", | ||
| "scripts": { | ||
| "build": "pnpm run clean && pnpm run build:blocks && pnpm run build:contact-form && pnpm run build:dashboard && pnpm run module:build", | ||
| "build": "pnpm run clean && pnpm run build:blocks && pnpm run build:contact-form && pnpm run build:dashboard && pnpm run build:form-editor && pnpm run module:build", |
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.
@enejb - the form editor if feature flagged, but this build code will always run and include the feature flagged form editor. Same with other package.json updates below specific to the form editor.
Is that a concern?
Update: I was also trying find other places the changes might leak out of the feature flag.
- We bump a dependency version in this file.
- We've added tests - I assume it's fine if those run during automated testing even if functionality is feature flagged.
- We update the template for register_post_type in a general file, but that is feature flagged upstream.
Anyways, just worth doing a sanity check that any code outside the feature flag will be safe.
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.
Thanks for bringing this up. This will definitely create scripts even though the feature flag is not enabled.
I think this is fine since there shouldn't be an impact on the user. (They are not downloading) the script when they visit the editor. (for example) but we might be distributing the assets (js and css) files even though they the site is under the feature flag. ( but the same cases exists for PHP files)
edanzer
left a comment
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.
Reviewed and tested:
- The new form editor is working well for me.
- We removed objectionable editor hacks based on comments.
- PHP and JS tests pass.
- I tried to find any place our changes might leak outside the feature flag, and it mostly looks good. Added a comment/question about this elsewhere.
- I also tested with feature flag off with no issues to confirm no regressions.
I added a few other small comments/questions.
There will be things to tweak, but I'd say let's merge so we can clear blockers and start tackling other things in smaller increments. Nice work @enejb!
This PR is part of #46297
It breaks up the larger PR (#46297 ) in a meaningfully smaller PR that can be reviewed easier and merged.
It adds a new Form Editor

Proposed changes:
Other information:
Jetpack product discussion
No
Does this pull request change what data or activity we track or use?
No
Testing instructions:
Since we are adding a new class. You will need to run
jetpack install -rafter you switch to this PR.Have the feature flag enabled in your sandbox.
Notice that the you can visit
/wp-admin/post-new.php?post_type=jetpack_formand that see the placeholder.You should be able to save the form and add new form fields.
With the feature flag disabled.
You should not be able to visit
/wp-admin/post-new.php?post_type=jetpack_formNothing should crash.
You can insert a form without any issues.
No form-editor js or css should be loaded.