Skip to content
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

VS Code: Launch Playground in VS Code using "blueprint mode" #211

Open
flexseth opened this issue Mar 30, 2024 · 7 comments
Open

VS Code: Launch Playground in VS Code using "blueprint mode" #211

flexseth opened this issue Mar 30, 2024 · 7 comments
Labels
Enhancement New feature or request

Comments

@flexseth
Copy link

flexseth commented Mar 30, 2024

When launching WordPress in VS Code via the extension, search first for a blueprint.json file to bootstrap the instance.

If a blueprint.json file is found in the project directory, load up the blueprint at the click of a button.

image

Current available modes

The WordPress Playground VS Code Extension automatically operates in a few different modes. The selected mode depends on the project directory in which it is executed

Automattic modes

  • plugin, theme, or wp-content
  • wordpress
  • wordpress-develop
  • index
  • playground
@flexseth flexseth added the Enhancement New feature or request label Mar 30, 2024
@adamziel
Copy link
Collaborator

adamziel commented Apr 2, 2024

+1 on that, or some form of it that allows for multiple Blueprints and is consistent with how Blueprints are supported in GitHub projects.

I'll move this over to the https://github.com/WordPress/playground-tools/ repo where the VS Code extension is maintained.

cc @sejas

@adamziel adamziel transferred this issue from WordPress/wordpress-playground Apr 2, 2024
@adamziel adamziel changed the title Launch Playground in VS Code using "blueprint mode" VS Code: Launch Playground in VS Code using "blueprint mode" Apr 2, 2024
@sejas
Copy link
Collaborator

sejas commented Apr 5, 2024

I love the idea! The only thing to bear in mind is that the blueprint should be executed only the first time, because blueprints are expected to create a "running" WordPress instance once.

@flexseth
Copy link
Author

flexseth commented Apr 6, 2024

the blueprint should be executed only the first time

great phrasing @sejas - adding this to the docs. It's an important distinction to make

@flexseth
Copy link
Author

flexseth commented Apr 9, 2024

The only thing to bear in mind is that the blueprint should be executed only the first time, because blueprints are expected to create a "running" WordPress instance once.

@jonathanbossenger did a livestream on the Playground, he was able to get a new site generated by running the blueprint again - using wp-now

In his example, he changed the blueprint step to change the site name.
Around 1 hour into the livestream.

If a blueprint can re-write an entire site, it probably would be helpful to throw some type of Caution message to let the user know the entire site could be re-written.

Following progress - feel like this has opportunity to be a great feature.
One-click from VS Code or command-line to a WordPress demo website.

@sejas
Copy link
Collaborator

sejas commented Apr 9, 2024

Yes! Some blueprints are less destructive.
Maybe we shouldn't autorun a blueprint by default, and instead the user can run it on demand with one click from the UI, as many times as they want.
My concern is that maybe some blueprints could be used to hack/or inject some malicious code in the user's computer.

@flexseth
Copy link
Author

flexseth commented Apr 9, 2024

Maybe we shouldn't autorun a blueprint by default, and instead the user can run it on demand with one click from the UI, as many times as they want.

Absolutely. The UI for VS Code I think could offer a ton more options. While using the extension I'll try to track down a "Wishlist" of sorts for things I'd love to see. It's the main way I could see using Playground!!

My concern is that maybe some blueprints could be used to hack/or inject some malicious code in the user's computer.
From my understanding, due to the "containerized" implementation of the Playground... this is a limited concern?

On the other hand I could see DDoS attacks or other outgoing attacks being more prevelant?

Disclaimer: Not a security expert by any way, but this is a feature that is appealing of Playground (less danger)

@flexseth
Copy link
Author

Maybe we shouldn't autorun a blueprint by default, and instead the user can run it on demand with one click from the UI, as many times as they want.

I was working on generating some use journeys that could create errors. GitHub Copilot is magical, by the way... nonetheless, here's two user scenerios it generated for blueprint errors:

User Journey 1: User is trying to import a Blueprint and gets an error

  1. User navigates to the Playground dashboard
  2. User clicks on the "Blueprints" tab
  3. User clicks on the "Import Blueprint" button
  4. User selects a Blueprint file to import
  5. User clicks the "Import" button
  6. User receives an error message

User Journey 2: User is trying to create a new Blueprint and gets an error

  1. User navigates to the Playground dashboard
  2. User clicks on the "Blueprints" tab
  3. User clicks on the "Create Blueprint" button
  4. User fills out the Blueprint form
  5. User clicks the "Create" button
  6. User receives an error message

Which could actually provide some ideas for how the UI could work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants