Forms: Fix device visibility CSS classes not applied to field wrapper on frontend by agent-sandbox-automattic[bot] · Pull Request #49945 · Automattic/jetpack

agent-sandbox-automattic · 2026-06-24T22:47:18Z

Proposed changes

Form fields were not respecting the block editor's device visibility settings ("Hide on desktop / tablet / mobile") on the front end.

Root cause: Core's block-visibility support stores the setting in the block's metadata.blockVisibility and applies a wp-block-hidden-{viewport} class via a render_block filter that writes the class onto the first tag of the block's rendered output (alongside the @media { … display: none !important } CSS it emits). Jetpack form fields render through the shortcode pipeline rather than render_block, so the class never reaches the rendered field wrapper — core still outputs the hide CSS, but nothing on the field carries the class, so the field stays visible.

Fixes:

block_attributes_to_shortcode_attributes() re-derives the wp-block-hidden-{viewport} classes from the field block's metadata.blockVisibility and adds them to the field wrapper, where the CSS that core already outputs expects them.
Device visibility only makes sense at the field (and label) level, so the per-block visibility control is disabled (supports.visibility: false) on the inner field sub-blocks — input, phone-input, input-range, input-rating, option, options. The label sub-block keeps the control.
A required field that is hidden for the visitor's current device no longer blocks submission. The client-side validation skips fields whose element is not rendered for the current viewport (offsetParent === null), and the server skips required validation for an empty field whose wrapper carries a wp-block-hidden-* class (the server can't know the viewport). Required fields that are visible are still enforced.
An empty device-hidden field is no longer listed on the post-submission confirmation page (a device-visibility field that was filled in on a viewport where it shows still appears). Storage and email notifications are unchanged.

Testing instructions

Create a page with a Jetpack Form. Add a Text field, mark it required, and set it to Hide on tablet via its visibility control. Add a visible required field (e.g. Email).
Save and view the page on the front end.
At a tablet-width viewport (≈700px): the field is hidden, and the form submits successfully without a "This field is required" error for it. The Email field is still required.
At a desktop-width viewport: the field is visible and still required — submitting empty is blocked as before.
Inspect the field at tablet width: the outer wrapper <div class="wp-block-jetpack-field-text wp-block-hidden-tablet …"> carries the class, and core's @media rule hides it.
In the editor, confirm the inner Input / Options sub-blocks no longer expose the device-visibility option, while the field and its Label still do.

Related product discussion/links

FORMS-694

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

No.

…y support When a user applies device visibility settings (or any custom CSS classes) to a Jetpack form field block via the block editor, the resulting CSS classes (stored in the block's className attribute) were not being propagated to the outermost wrapper div of the rendered field on the frontend. Instead, the classes were only applied to the inner input element and were also transformed with a -wrap suffix on the outer div (e.g. wp-hide-on-desktop became wp-hide-on-desktop-wrap), which breaks the CSS selectors used by the block visibility feature. This fix ensures that custom CSS classes (after extracting the is-style-* block style variation classes) are also added to fieldwrapperclasses, so they appear on the outermost field wrapper element where device visibility CSS rules expect them. Co-authored-by: CGastrell <christian.gastrell@automattic.com>

github-actions · 2026-06-24T22:48:19Z

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the ai/agent/forms-694-1782340429 branch.
To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack ai/agent/forms-694-1782340429

Interested in more tips and information?

In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
Read more about our development workflow here: PCYsg-eg0-p2
Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

jp-launch-control · 2026-06-24T22:58:01Z

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

github-actions · 2026-06-24T23:56:07Z

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 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 🤖

Follow this PR Review Process:

Ensure all required checks appearing at the bottom of this PR are passing.
Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
You can use GitHub's Reviewers functionality to request a review.
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!

CGastrell · 2026-06-25T14:48:22Z

Thanks for picking this up — but I don't think this hides fields on the frontend. Device visibility isn't a className; it's metadata.blockVisibility, which core turns into wp-block-hidden-* classes plus the matching media-query CSS via its render_block filter. The Forms field pipeline flattens blocks to a shortcode array and bypasses that filter, so forwarding className to the wrapper won't carry the setting — and the CSS that actually hides the field is never generated.

Direction's still open in FORMS-694: either replicate core's class+CSS generation (support it), or disable the control on fields so the non-working option disappears (drafted in #49973). Probably worth settling that first.

Copilot

Pull request overview

This PR fixes Jetpack Forms frontend rendering so block className values (including device visibility classes like wp-hide-on-desktop) are propagated to the outermost form-field wrapper element, aligning frontend markup with block visibility CSS expectations.

Changes:

Update block_attributes_to_shortcode_attributes() to add remaining (non-is-style-*) classes to fieldwrapperclasses.
Extend PHPUnit coverage to assert device visibility classes are present on the wrapper classes.
Add a patch-level changelog entry documenting the fix.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
projects/packages/forms/src/contact-form/class-contact-form-plugin.php	Adds remaining custom classes to `fieldwrapperclasses` so wrapper markup receives device visibility classes.
projects/packages/forms/tests/php/contact-form/Contact_Form_Plugin_Test.php	Updates/extends test expectations to cover wrapper class propagation (including device visibility classes).
projects/packages/forms/changelog/ai-agent-forms-694-1782340429	Adds changelog entry for the user-facing fix.

+					// Also apply remaining custom classes (e.g. device visibility classes) directly
+					// to the field wrapper so they take effect on the outermost wrapper element.
+					if ( ! empty( $atts['class'] ) ) {
+						$atts['fieldwrapperclasses'] .= ' ' . $atts['class'];
+					}


…trol on inner field sub-blocks

…on page

…ity flag)

github-actions Bot added [Feature] Contact Form [Package] Forms [Status] In Progress [Tests] Includes Tests labels Jun 24, 2026

github-actions Bot added the [Status] Needs Author Reply We need more details from you. This label will be auto-added until the PR meets all requirements. label Jun 24, 2026

enejb requested a review from Copilot June 26, 2026 18:02

Copilot started reviewing on behalf of enejb June 26, 2026 18:02 View session

Copilot AI reviewed Jun 26, 2026

View reviewed changes

Forms: derive block visibility classes from metadata and hide the con…

80ad462

…trol on inner field sub-blocks

github-actions Bot added the [Block] Contact Form label Jun 26, 2026

enejb added 3 commits June 26, 2026 14:04

Forms: skip required validation for fields hidden by device visibility

0a5a386

Forms: hide empty device-hidden fields from the submission confirmati…

75f50e0

…on page

Forms: address simplify review (gate layout reads, structured visibil…

3bbbbcb

…ity flag)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Forms: Fix device visibility CSS classes not applied to field wrapper on frontend#49945

Forms: Fix device visibility CSS classes not applied to field wrapper on frontend#49945
agent-sandbox-automattic[bot] wants to merge 5 commits into
trunkfrom
ai/agent/forms-694-1782340429

agent-sandbox-automattic Bot commented Jun 24, 2026 •

edited by enejb

Loading

Uh oh!

github-actions Bot commented Jun 24, 2026 •

edited

Loading

Uh oh!

jp-launch-control Bot commented Jun 24, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 24, 2026 •

edited

Loading

Uh oh!

CGastrell commented Jun 25, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

agent-sandbox-automattic Bot commented Jun 24, 2026 • edited by enejb Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed changes

Testing instructions

Related product discussion/links

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

Uh oh!

github-actions Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jp-launch-control Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage Summary

Uh oh!

github-actions Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CGastrell commented Jun 25, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

agent-sandbox-automattic Bot commented Jun 24, 2026 •

edited by enejb

Loading

github-actions Bot commented Jun 24, 2026 •

edited

Loading

jp-launch-control Bot commented Jun 24, 2026 •

edited

Loading

github-actions Bot commented Jun 24, 2026 •

edited

Loading