WP-CLI error about wordpress-multi-env-config HOT 9 CLOSED

Hi,

I run into the same problem, $argv seems to be always NULL when I run wp-cli on my development server.

I resorted to specify environment via environment variable: WP_ENV=development wp-cli core version. Maybe it helps someone.

from wordpress-multi-env-config.

Thanks, I think the "Define site host" section needs swapping with the WP-CLI section.

$argv can be checked for, but as far as I'm aware it should always exist in CLI mode.

If you do have any PR please do submit.

best wishes,
Simon

from wordpress-multi-env-config.

Hi leesherwood, I am definitely interested if you have a solution to #3. I'm automating the process of exporting our production database and bringing it to a dev folder on the same server. Now I need to ensure that WP-CLI targets the correct database when doing Search & Replace to change to the dev account. (Already had an issue with updating production by mistake - easy to undo, thankfully - and want to make this process foolproof.)

from wordpress-multi-env-config.

@davide101 can you please add some example commands that you're using where you cannot pass the --env argument just so I fully understand the need for resolving this issue.

from wordpress-multi-env-config.

Sure. Here is an example below.

wp search-replace --url=www.examplw.com dev.example.com www.example.com --precise --env=development

Error: Parameter errors:
 unknown --env parameter

Thank you very much for sharing this code. It saved a good bit of time in setting up our dev environment. We very much appreciate it!

from wordpress-multi-env-config.

Hi @davide101. Ultimately we can't change wp-cli behaviour. We could create a wrapper php invoker for wp-cli but as a public solution that's pretty aweful.

In the end i used phpdotenv library to load the data from a private .env file (if you're using things like composer and modern php frameworks you'll be aware of how this works). However by default wordpress isn't setup with composer and requiring users to install a library seems a little OTT.

I think the best thing to do is a hybrid of the existing solution with .env overrides. (I personally would drop the existing solution and make it pure .env controlled, but the existing solution does have its benefits to more junior programmers as it's easier to understand, guess its a matter of personal opinion).

Anyway, i do have a solution that works for me. If @simonrjones likes, i'm happy to make a version of my solution thats not composer dependant and create a PR that addresses all the issues from my original post, however it's more than just a small tweak and might be better served as a second solution (especially if this is the way studio24 prefer to do it).

I'll leave it up to @simonrjones as to whether he wants me refactoring his solution or not :P

from wordpress-multi-env-config.

Sorry for the long delay in replying here.

hi @leesherwood, if you have example code would be interested to see it.

I think I understand in principle, that sometimes it's just not possible to set --env in WP-CLI, and using something like .env file makes more sense. If it's just for setting the environment that's simple enough to integrate without the whole phpdotenv library.

I am currently reviewing a v2 release since am refactoring a few things, making this a bit more secure, best practise, so will review this too.

from wordpress-multi-env-config.

Hi, any update on getting this to work with wp-cli?

from wordpress-multi-env-config.

$argv value has been fixed in the recent update to this code.

If you cannot use --env then please use environment variables as suggested. Another alternative is to create a .env file with the current environment set within it.

from wordpress-multi-env-config.