Closed adamkiss closed 3 months ago
I guess if we make it an argument, it could come before the command to distinguish it from a command argument:
kirby -e production.com custom:command -a 'argument for command'
Regarding the two options: Why not both? We could even set the env variable up in a way that it can be used in a shell profile (e.g. .zshrc
or .bash_profile
), i.e. the name should be specific to Kirby (like KIRBY_ENV
).
@lukasbestle Iβ¦ have no opinion. My use cases are mostly stuff like live services vs. mock services (email sending, third party API, etc), where you defensively set the mock as default and override in production, so setting env in the shell profile isβ¦ π€·π»ββοΈ
re: order: I think that's too complicated I think long --env
argument is much more readable. Also, I don't know if the underlying CLI parser is capable of distinguishing stuff like "argument before the command".
If I can do anything (sketch PR with env maybe?) to have this released faster, let me know
I get the following errors when trying to enter kirby commands in my website directory, is this related to this issue?
I'm running different environment configurations, also testing with starterkit
is seems to work as expected
Kirby\Exception\InvalidArgumentException: The environment is not allowed in /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:245
Stack trace:
#0 /var/www/html/vendor/getkirby/cms/src/Http/Environment.php(177): Kirby\Http\Environment->detectAllowed()
#1 /var/www/html/vendor/getkirby/cms/src/Http/Environment.php(108): Kirby\Http\Environment->detect()
#2 /var/www/html/vendor/getkirby/cms/src/Cms/App.php(1095): Kirby\Http\Environment->__construct()
#3 /var/www/html/vendor/getkirby/cms/src/Cms/App.php(104): Kirby\Cms\App->optionsFromEnvironment()
#4 /var/www/html/public/index.php(7): Kirby\Cms\App->__construct()
#5 /home/alex/.config/composer/vendor/getkirby/cli/bootstrap.php(16): require('...')
#6 /home/alex/.config/composer/vendor/getkirby/cli/bin/kirby(9): Kirby\CLI\bootstrap()
#7 /home/alex/.config/composer/vendor/bin/kirby(120): include('...')
#8 {main}
Kirby\Exception\InvalidArgumentException: The environment is not allowed in file /var/www/html/vendor/getkirby/cms/src/Http/Environment.php on line 245
Stack trace:
1. Kirby\Exception\InvalidArgumentException->() /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:245
2. Kirby\Http\Environment->detectAllowed() /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:177
3. Kirby\Http\Environment->detect() /var/www/html/vendor/getkirby/cms/src/Http/Environment.php:108
4. Kirby\Http\Environment->__construct() /var/www/html/vendor/getkirby/cms/src/Cms/App.php:1095
5. Kirby\Cms\App->optionsFromEnvironment() /var/www/html/vendor/getkirby/cms/src/Cms/App.php:104
6. Kirby\Cms\App->__construct() /var/www/html/public/index.php:7
7. require() /home/alex/.config/composer/vendor/getkirby/cli/bootstrap.php:16
8. Kirby\CLI\bootstrap() /home/alex/.config/composer/vendor/getkirby/cli/bin/kirby:9
9. include() /home/alex/.config/composer/vendor/bin/kirby:120
@bogdancondorachi What is your url
option set to?
@adamkiss I agree, env would probably the easiest and most flexible. I'd still call it KIRBY_ENV
though to avoid clashes with other tools.
Hi all,
I ran into the same issue, while developing our email check plugin. Is there any news on this? I personally would prefer a --host
or --env
argument to every command, but the order of arguments must not matter β that is just confusing IMO.
I wouldn't mind an argument and the environment variable being implemented, though π
It's coming to 1.5.0 with the new KIRBY_HOST env variable.
For many tasks a user might want to do with a cli command, configuration differs for production/staging/dev environments.
Kirby solves this very elegantly with
config.domain.ext.php
files, but these are not available in the cli commands (Logically, even though that was not a fun debugging session).I'd like then, to somehow pass the environment - probably the domain to use, so we could use the existing configuration - to cli.
There are two options:
1.) Use a command argument
2.) Use an environment value
I personally prefer the option 1 (argument), but that would be a first kind of argument not passed through to command, so I'm not sure if that's a good idea or not.