[kaitenz]

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:
        File: C:/var/www/html/MY/application/core/CI_Exceptions.php
        Line: 220
        Function: include

        File: C:/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 error: A Database Error Occurred

        Unable to connect to your database server using the provided settings.
        Filename: core/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.

[Pertti]

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

[kaitenz]

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.

[Pertti]

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.

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.

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.

[kaitenz]

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?

[Pertti]

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.

[kaitenz]

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.

[kaitenz]

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.

[Pertti]

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.