Clean up siteForm from legacy

[nightnei]

Proposed Changes

While working on Add wpcom to onboarding I noticed:

1. We have a few unused properties, it seems they are from times when we had import process located inside the form for creating a site.
2. Also after the previously mentioned PR we have 2 more unused properties now

So I decided to clean it up.

I was also thinking about moving create-site-form.tsx inside modules/add-site-form, and also merging it with modules/add-site/components/create-site, but to keep this PR easy for review, I decided that it's better not to do it right now.

I was also thinking about merging create-site and create-site-form, but to make this PR easier for review, I decided not to do it. It's not something very critical, but more important to make the PR diff clearer and easier for review.

Testing Instructions

1. Run Studio
2. Create a new site
3. Assert that it was created and no errors in browser's console

[sejas]

Yay! great catch. Thanks for cleaning the code.
I tested it by importing a new site.

importing-site.mp4

Let's also fix unit tests before merging.

[Copilot]

Pull request overview

This PR cleans up the site creation form by removing legacy code related to the import process and renaming SiteForm to CreateSiteForm for better clarity. The cleanup removes unused properties and interfaces that were previously associated with importing backups during site creation.

Key changes:

• Renamed SiteForm component to CreateSiteForm to better reflect its specific purpose
• Removed legacy import-related functionality (FormImportComponent and associated props)
• Cleaned up unused imports and properties (trash icon, useRef, ACCEPTED_IMPORT_FILE_TYPES, isDisabled parameter)

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/modules/add-site/components/create-site.tsx	Updated import and usage to reference CreateSiteForm instead of SiteForm
src/modules/add-site/components/create-site-form.tsx	Renamed component from SiteForm to CreateSiteForm, removed legacy import functionality and unused props, cleaned up unused imports

Comments suppressed due to low confidence (2)

src/modules/add-site/components/create-site-form.tsx:37

• The interface name SiteFormProps should be renamed to CreateSiteFormProps to match the component name CreateSiteForm. This follows the codebase convention where component names match their Props interface names (e.g., BlueprintIssuesModal uses BlueprintIssuesModalProps, Button uses ButtonProps).
  src/modules/add-site/components/create-site-form.tsx:61
• [nitpick] The interface name SiteFormErrorProps and the component SiteFormError should be renamed to match the new component name (e.g., CreateSiteFormErrorProps and CreateSiteFormError) for consistency, since the parent component was renamed from SiteForm to CreateSiteForm.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sejas]

Copilot made a great suggestions. We can rename the props name to match the renamed component.

Suggested change

	interface SiteFormProps {
	interface CreateSiteFormProps {

[fredrikekelund]

This is just a suggestion, and it does increase the scope of this refactor, but this component deserves a refactor to reduce the props drilling even further, IMO.

The ideal scenario would be if CreateSiteForm received a features prop to determine which features to display in the form, and an onSubmit handler that receives an object with all the form values. It makes more sense for the state to live alongside the form controls than in the useAddSite hook, at the AddSite component level.

[github-actions]

📊 Performance Test Results

Comparing ebd9fe4 vs trunk

site-editor

Metric	trunk	ebd9fe4	Diff	Change
load	12468.00 ms	17227.00 ms	+4759.00 ms	🔴 38.2%

site-startup

Metric	trunk	ebd9fe4	Diff	Change
siteCreation	37057.00 ms	34982.00 ms	-2075.00 ms	🟢 -5.6%
siteStartup	15151.00 ms	14131.00 ms	-1020.00 ms	🟢 -6.7%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change

[nightnei]

This is just a suggestion, and it does increase the scope of this refactor, but this component deserves a refactor to reduce the props drilling even further, IMO.
The ideal scenario would be if CreateSiteForm received a features prop to determine which features to display in the form, and an onSubmit handler that receives an object with all the form values. It makes more sense for the state to live alongside the form controls than in the useAddSite hook, at the AddSite component level.

Great idea, but let's do it later as a separate PR

[fredrikekelund]

let's do it later as a separate PR

I created STU-1099 to track this