• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Environment affecting the configuration files in CLI mode

#1
Hi,

Frustrated right now. I'm creating a cron job in CodeIgniter.

Now, I have 2 folders inside my config directory, namely: development and testing and inside of it are the config files that are set for different environment, especially the database.php

The environment is set inside my .htaccess with the following code:
Code:
<IfModule mod_env.c>
   SetEnv CI_ENV testing
</IfModule>

Please take note that my database (per environment):
  • development => 'mydatabase_dev'
  • testing          => 'mydatabase_test'
  • production    => 'mydatabase_live'
(I changed the names due to confidentiality, sorry)

And also, my current environment is set to "testing".

When I run a command, the error shows up:

PHP Code:
A PHP Error was encountered

Severity
   Warning
Message
    mysqli::real_connect(): (HY000/1049): Unknown database 'mydatabase_dev'
Filename   C:/var/www/html/MY/system/database/drivers/mysqli/mysqli_driver.php
Line Number
201

Backtrace
:
 
       FileC:/var/www/html/MY/application/core/CI_Exceptions.php
        Line
220
        Function
: include

 
       FileC:/var/www/html/MY/application/core/CI_Controller.php
        Line
36
        Function
__construct

        File
C:/var/www/html/MY/application/controllers/Cron.php
        Line
53
        Function
__construct

        File
C:/var/www/html/MY/index.php
        Line
315
        Function
: require_once



Database errorA Database Error Occurred

        Unable to connect to your database server using the provided settings
.
 
       Filenamecore/CI_Controller.php
        Line Number
36 

The database driver is looking for the non-existing database (because the mydatabase_dev is located in my laptop, while the mydatabase_live is located in our production server and mydatabase_test is located in our test servers.

It is annoying. Can't figure out why this is happening. This only happens in CLI and in the browser it works fine.
Reply

#2
Could be because CLI also runs in an "environment", and when it can't find CI_ENV, it defaults to wrong option, but you can easily set similar variables in any environment.

For Windows machines, you can search environment variables from your settings page.

For Unix/Linux, you have to create/update a specific file that gets loaded when you log in or when user account is active - more here https://unix.stackexchange.com/questions...-variables

For cron, you can set these variables from cron file, check the second and third answer from here - https://stackoverflow.com/questions/2229...b-will-use
Reply

#3
(07-16-2018, 11:24 PM)Pertti Wrote: Could be because CLI also runs in an "environment", and when it can't find CI_ENV, it defaults to wrong option, but you can easily set similar variables in any environment.

For Windows machines, you can search environment variables from your settings page.

For Unix/Linux, you have to create/update a specific file that gets loaded when you log in or when user account is active - more here https://unix.stackexchange.com/questions...-variables

For cron, you can set these variables from cron file, check the second and third answer from here - https://stackoverflow.com/questions/2229...b-will-use

I see. I run a quick test on my CLI and found out that:
Code:
$_SERVER['CI_ENV']
is not set when using CLI.
It always point to my 'development' database configuration. That's why I'm getting that error. Meaning to say that "SetEnv CI_ENV" is not working on .htaccess if you use CLI. So my alternative way is to manually change the index.php where ENVIRONMENT constant is defined.
Or another alternative (I don't know if this will work) to SetEnv is DotEnv. I don't know how I can make this work but let's give it a try.
Thank you.
Reply

#4
(07-17-2018, 12:02 AM)kaitenz Wrote: It always point to my 'development' database configuration. That's why I'm getting that error. Meaning to say that "SetEnv CI_ENV" is not working on .htaccess if you use CLI.

That's right, because .htaccess is Apache webserver related and is only used if you access php files via browser or API remotely. Cron job is local process where you tell php library to run a specific script and so .htaccess is completely out of the mix.

(07-17-2018, 12:02 AM)kaitenz Wrote: So my alternative way is to manually change the index.php where ENVIRONMENT constant is defined.

Hardcoding is quick and dirty fix, but it might bite you when you need to re-build servers or add more test servers or work with more people who have their local dev environments, so environmental variables / DotEnv are better option in that sense.

(07-17-2018, 12:02 AM)kaitenz Wrote: Or another alternative (I don't know if this will work) to SetEnv is DotEnv. I don't know how I can make this work but let's give it a try.

Yep, that should work, as long as your CLI and normal web-side settings are the same.
Reply

#5
I'll go with the DotEnv. How can I setup that?

I found this: https://github.com/agungjk/phpdotenv-for-codeigniter
He's suggesting to put the DotEnv files inside the 'system' folder which I don't want to touch.

Any other work-around?
Reply

#6
Using 'system' is fine - the files are in it's separate folder, so updating CI itself won't be an issue.

If you really must keep it somewhere else, you need to adjust following line in index.php example:
PHP Code:
require_once BASEPATH.'dotenv/autoloader.php'

In this context BASEPATH is 'system/', so if you want to put your dotenv files somewhere else, you need to update paths for require_once accordingly.
Reply

#7
(07-17-2018, 01:06 AM)Pertti Wrote: Using 'system' is fine - the files are in it's separate folder, so updating CI itself won't be an issue.

If you really must keep it somewhere else, you need to adjust following line in index.php example:
PHP Code:
require_once BASEPATH.'dotenv/autoloader.php'

In this context BASEPATH is 'system/', so if you want to put your dotenv files somewhere else, you need to update paths for require_once accordingly.

What am I thinking.
I forgot that if I overwrite all CI system files, dotenv will not affect since it has a separate folder.
What I am thinking is to rename the original system folder (something like system_319 [319 as the version number]) and extract the updated system folder inside it, so making rollback to last version easy.

Hahahaha I make something complicated when there's a simple solution.
Reply

#8
Oops. I got a problem.

If my intention of using DotEnv is to replace the functionality of SetEnv in Apache and to alter the ENVIRONMENT constant, then it will be useless.

The library is also relying on the ENVIRONMENT constant (like .env.development, .env.testing, .env.production). If I will use DotEnv to use this:
PHP Code:
define('ENVIRONMENT'getenv('ENVIRONMENT')) 
it will be useless. Sad
Reply

#9
That's odd.

While I haven't used DotEnv specifically myself, we've implemented similar functionality via Windows / Unix environmental variables, but I thought in principle it was suppose to work slightly differently.

In my understanding you don't use dev or testing or production, you just have a .env file on every server/copy/instance of code you use, and in that settings file you specify what DB you want this instance to connect to.

If you use Git or other source management software, you ignore the file and when you upload copy somewhere first time, you create file based on .env.example to specifically handle this new instance.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.