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

WordPress Quickstart Format #11

Open
adamziel opened this issue Feb 14, 2024 · 1 comment
Open

WordPress Quickstart Format #11

adamziel opened this issue Feb 14, 2024 · 1 comment

Comments

@adamziel
Copy link
Collaborator

Snapshots and Blueprints go hand in hand. Let's find a convenient way for a developer to type in a single command, like wp up, and get a WordPress site built / served based on the current directory contents.

For example, I could have just some themes, plugins, etc:

    ./wp-config.php
    ./wp-content
    ./wp-content/database
    ./wp-content/themes/twentytwentythree
    ./wp-content/plugins/gutenberg
    ./wp-content/plugins/woocommerce
    ./wp-content/mu-plugins
    … etc …

Or, I could have just a Blueprint:

    ./blueprint.json

Or I could have both:

    ./blueprint.json
    ./wp-content/plugins/gutenberg

This is, more or less, what wp-env and wp-now do today. They could converge into a single tool.

Open questions

  • Should the WordPress directory structure be required?
  • Should the local directory change as a result of wp up? E.g. should the downloaded themes be unzipped in wp-content/themes? And should there be a wp reset command to restore the original site? And how it would work under the hood?
  • Should wp up create a new, ephemeral site? Or always the same site running from that local directory? Or should that be a matter of the runtime adapter used? Or a CLI switch? Like --temporary or --permanent?

cc @danielbachhuber @noahtallen @sejas @dmsnell @youknowriad @mtias

@noahtallen
Copy link
Member

One interesting feature of wp-env is that if you run it in a directory containing a plugin or theme, you'll automatically get a site running with that plugin or theme with no configuration necessary.

IMO, the benefit of not requiring the WordPress directory structure is that it's easy to use the tool for a monorepo which might have lots of projects, where code might be organized differently. (plus, you often only care about the stuff under wp-content, not the other core code.) As a result, wp-env has a separate "hidden" directory in the home folder which contains any downloaded themes/plugins, and then everything is mapped together with Docker. The nice part about this is the downloaded plugin is treated like a true dependency that you aren't supposed to modify. (And therefore it doesn't matter if it gets overwritten.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants