Forms: add first/last name field variations

[edanzer]

Fixes FORMS-293

Proposed changes:

Add first and last name variations to the name field with the field HTML ID attribute to set to first-name and last-name.

First/name fiels are generally useful - many forms have first/last name - but this also helps with integrations. Many integrations (MailPoet, Hostinger, plus MailChimp in the future) depend on having identifiable first and last name. Right now we look for "First Name" and "Last Name" labels, which are very English-centric, or users must manually add first-name or last-name ids.

A user can insert these, and they will automatically sync to MailPoet and Hostinger first/last fields.

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

See linear issue above.

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

No.

Testing instructions:

• Add a form block to a page or post
• Try adding a first and last name field
• Confirm each of those fields has the first-name or last-name id
• Submit form and confirm fields are submitted correctly

[github-actions]

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 add/forms-name-variations branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/forms-name-variations

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

[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.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ 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:

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

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: November 4, 2025
  • Code freeze: November 3, 2025

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[dhasilva]

LGTM, works as expected

[jp-launch-control]

Code Coverage Summary

1 file is newly checked for coverage.

File	Coverage
projects/packages/forms/src/blocks/field-name/variations.js	0/2 (0.00%) 💔

Full summary · PHP report · JS report

_{If appropriate, add one of these labels to override the failing coverage check: Covered by non-unit tests Use to ignore the Code coverage requirement check when E2Es or other non-unit tests cover the code Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage.}

[simison]

UX wise: I'm wondering if we should have just two variations: "Name and "First- and last name", and just render two inputs side-by-side by default? 🤔 Considering if that would be easier for user although with cost of some flexibility that approach in this PR allows. cc @ilonagl too about UX.

[enejb]

From the UX side it might be good to explore using toggles. Kind of like we do for the phone field.

[simison]

@enejb although it might be useful to get the block-inserter visibility that comes with variations?

[edanzer]

I'm wondering if we should have just two variations: "Name and "First- and last name", and just render two inputs side-by-side by default?

I assume we'd insert them as first/last, but we'd really be inserting two different name field variations? So the two fields could be managed separately for settings, moved separately, etc?

I'd personally keep it simple and just keep them separate. It's not too hard to add two fields. It allows for flexibility - people will always do thing you don't expect with features in WordPress. It keeps the code simple.

From the UX side it might be good to explore using toggles. Kind of like we do for the phone field.

@enejb although it might be useful to get the block-inserter visibility that comes with variations?

Would these be variations that you can switch between, or a single field where you update a toggle, or maybe both (ie, variations that vary by toggle)?

As @Mikael noted, I do think it would be good to have something that can be found/inserted as a first/last name. And I think we should consider adding or updating some of our form patterns to include the first and last name variations. Worth noting you can 'toggle' between first/last name using block transform.

---

I think on balance, I say we go with simple variations. Meets all needs, allows flexibility, easy to add/switch, and skips any extra complexity.

[enejb]

Would these be variations that you can switch between, or a single field where you update a toggle, or maybe both (ie, variations that vary by toggle)?

It would be a single input that would be expanded to include the different "fields". This is how currently the gravity forms does it and I think it works well. See https://docs.gravityforms.com/name/.

[edanzer]

It would be a single input that would be expanded to include the different "fields".

I see. Nice! But does add extra complexity. So question is whether it's worth it vs separate fields. I'd probably opt to keep it simple and do separate fields. But happy to go whichever way we decide. I'll wait and see how convo unfolds.