Skip to content

Conversation

@ivan-ottinger
Copy link
Contributor

@ivan-ottinger ivan-ottinger commented Nov 19, 2025

Related issues

Proposed Changes

  • extract out the blueprint validation logic into utility validateBlueprintData function - so it can be reused easily
  • display validation error message in a dialog when incorrect blueprint is passed in a deeplink
  • remove unnecessary second deeplink blueprint validation from the renderer process
  • update and add related unit tests
  • ensure the deeplink that opens blueprint from a linked URL gets the user to the "Add a site" step directly (instead of the previous "Start from a Blueprint" step)

ℹ️ Please note that this PR does not add validation to the handling of deeplinks that include the base64-encoded blueprint. This is because we will have another PR that will refactor and unify the logic that handles both deeplink types: STU-1008.

Testing Instructions

  1. Check out the PR and build the app with npm install && npm start.
  2. Try to open the blueprint deeplinks provided here: https://jsbin.com/levaburate/2/edit?html,css,output.
  • First two should result in a dialog error message.
  • The third one should get you to the "Add a site" step and allow you to create a new site with it.
  1. Try to manually create sites using blueprint files from 39a4e-pb. The results should be as expected - there should be no regressions.

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?

@ivan-ottinger ivan-ottinger self-assigned this Nov 19, 2025
@ivan-ottinger ivan-ottinger marked this pull request as ready for review November 19, 2025 13:56
@github-actions
Copy link
Contributor

github-actions bot commented Nov 19, 2025

📊 Performance Test Results

Comparing 596772d vs trunk

site-editor

Metric trunk 596772d Diff Change
load 14910.00 ms 12068.00 ms -2842.00 ms 🟢 -19.1%

site-startup

Metric trunk 596772d Diff Change
siteCreation 20065.00 ms 21208.00 ms +1143.00 ms 🔴 5.7%
siteStartup 9982.00 ms 10040.00 ms +58.00 ms 🔴 0.6%

Results are median values from multiple test runs.

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

@ivan-ottinger ivan-ottinger requested a review from a team November 19, 2025 14:32
Copy link
Contributor

@gcsecsey gcsecsey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for refactoring the validation @ivan-ottinger, and for updating the tests! I tested both blueprints from the drive and a couple from the blueprints gallery, and I'm getting the same validation issues reported as on trunk.

Invalid URL Invalid Blueprint Valid Blueprint
Image Image Image


if ( ! validation.valid ) {
await fs.remove( blueprintPath ).catch( () => {
// Ignore cleanup errors
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking maybe we can log this, but as this is a temporary file, I think this is fine to skip. 👍

Copy link
Contributor

@gavande1 gavande1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ivan-ottinger, I believe we are validating the blueprint twice as per the suggested changes in this PR. Is it intended, or am I missing something? Do you think we should refactor that?

const blueprintJson = await getIpcApi().readBlueprintFile( pendingBlueprintPath );
const validation = await getIpcApi().validateBlueprint( blueprintJson );
if ( ! validation.valid ) {
const errorMessage = validation.error || __( 'Invalid Blueprint format' );
throw new Error( errorMessage );
}

Copy link
Contributor

@gavande1 gavande1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have tested this and it works as expected. I have left a comment about duplicate validation. Otherwise, the changes look good to me.

Image

@ivan-ottinger
Copy link
Contributor Author

ivan-ottinger commented Nov 19, 2025

Thank you for your reviews and testing, Gergely and Rahul!

@ivan-ottinger, I believe we are validating the blueprint twice as per the suggested changes in this PR. Is it intended, or am I missing something? Do you think we should refactor that?

That's a good catch, @gavande1! This second validation is no longer needed - since we validate earlier in the flow, before even the modal has a chance to open.

I have addressed that in 6560c93 and the PR is ready for another review round. 🙂

I am looking forward to the next simplifications related to STU-1008 in the next PR.

Copy link
Contributor

@gcsecsey gcsecsey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for removing the extra validation, the updated version LGTM and still works well in all scenarios. 🙌

@ivan-ottinger ivan-ottinger force-pushed the update/blueprint-from-deeplink-url-validation branch from 6560c93 to df4a3f5 Compare November 20, 2025 11:50
Copy link
Contributor

@gavande1 gavande1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ivan-ottinger for addressing the feedback. LGTM 👍

@ivan-ottinger ivan-ottinger merged commit c9adc2e into trunk Nov 20, 2025
10 checks passed
@ivan-ottinger ivan-ottinger deleted the update/blueprint-from-deeplink-url-validation branch November 20, 2025 12:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants