You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 18, 2022. It is now read-only.
Essentially how I see this working is we have a directory, say ~/.yeopress, where you build and store pre-defined configurations. So a command like
$ yo wordpress --use basic-site
for example would pull in the config file for basic-site. So instead of prompting the user a bunch of times, we just use the data in the configuration, and off we go. YeoPress sort of does this already, with one pre-defined configuration. But you still have to press enter a bunch of times if you don't want to change anything.
There is only one or two prompts that I think this wouldn't make sense for: the site URL and the database name. I'm not sure YeoPress is doing anything with the URL. I did a quick check, but I'm guessing @wesleytodd would know off the top of his head whether or not the URL gets used anywhere (in the theme template?). We could still prompt for the database name, or say any other piece of data that's missing from the pre-defined config, and cut down the setup time for YeoPress significantly, especially when you're scaffolding a lot of similar projects.
The text was updated successfully, but these errors were encountered:
I totally see the use case here, so if you had a few different base configurations you used you could have a .yeopress style json file for each. If we are going to change the global .yeopress file into a directory then we should probably do a structure like this:
This would also give us a place to expand with other features in the future (possibly #153 ).
For the skipping of the prompts, I did it this way originally because I thought people would like the confirmation. But if you think it is better to skip them I am fine with that.
But I don't see it anywhere else either. Did you try removing it and seeing if the site still worked?
Lastly, we could do something similar to what npm does with npm-init.js and have a js file that is used to prompt the user. This way you could even script the prompts, so they could so special things depending on your usage. Just a thought, but it could be cool.
I think if we're storing predefined user-defined configs, we'll want to skip the prompt session. Maybe we could actually just do a dump of the config and then do the last "does this all look correct" prompt, that way the user at least has an opportunity to take a look and confirm.
We could even do something like
$ yo wordpress --save basic-site
and then save out the config after the user finishes the prompt session. That way they don't have to worry about actually writing the file themselves.
Awesome ideas. Currently when you say no to the "does this all look correct" prompt it resets the input, so that would have to change, but that wouldn't be that hard. Other than that I am fully on board with this.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Essentially how I see this working is we have a directory, say
~/.yeopress
, where you build and store pre-defined configurations. So a command likefor example would pull in the config file for
basic-site
. So instead of prompting the user a bunch of times, we just use the data in the configuration, and off we go. YeoPress sort of does this already, with one pre-defined configuration. But you still have to press enter a bunch of times if you don't want to change anything.There is only one or two prompts that I think this wouldn't make sense for: the site URL and the database name. I'm not sure YeoPress is doing anything with the URL. I did a quick check, but I'm guessing @wesleytodd would know off the top of his head whether or not the URL gets used anywhere (in the theme template?). We could still prompt for the database name, or say any other piece of data that's missing from the pre-defined config, and cut down the setup time for YeoPress significantly, especially when you're scaffolding a lot of similar projects.
The text was updated successfully, but these errors were encountered: