2
\$\begingroup\$

I have a legacy PHP project using a self-styled configuration file (named globals.inc.php) which is generated by build scripts based on a template included in the code called globals.template.inc.php:

<?php

use MyPropject\Core\DBConn;

require_once __DIR__ . "/vendor/autoload.php";

/**
 * GLOBAL variables
 *
 */
define("I18N_FILES",         __DIR__ . '/i18n/lang_{LANGUAGE}.json');
define("I18N_CACHE",         __DIR__ . '/langcache/');
define("SITE_TITLE",         "¤SITE_TITLE¤");
define("SITE_NAME",          "¤SITE_NAME¤"); 
define("SITE_FQDN",          "¤SITE_FQDN¤");
define("SESSION_DURATION",   1800);
define("DEFAULT_FROM_EMAIL", "¤DEFAULT_FROM_EMAIL¤");
define("SESSION_NAME",       "¤SESSION_NAME¤"); 
define("CERT_LOCATION",      "¤CERT_LOCATION¤");
define("MYSQL_USERNAME",     "¤MYSQL_USERNAME¤");
define("MYSQL_PASSWORD",     "¤MYSQL_PASSWORD¤");
define("MYSQLDATABASENAME",  "¤MYSQL_DB_NAME¤");
define("MYSQL_HOSTNAME",     "¤MYSQL_HOSTNAME¤");
define("MYSQL_PORT",         ¤MYSQL_PORT¤);
define("MYSQL_DSN",          "mysql:dbname=" . MYSQLDATABASENAME . ";host=" . MYSQL_HOSTNAME. ";port=" . MYSQL_PORT);
define("DEPLOY_DATE",        "¤DEPLOY_DATE¤");
define("GIT_TAG_BACKEND",    "¤GIT_TAG_BACKEND¤");
define("GIT_TAG_FRONTEND",   "¤GIT_TAG_FRONTEND¤");
if (isset($_SERVER["SERVER_NAME"])) {
    define("IS_PROD", $_SERVER["SERVER_NAME"] === "www.MyPropject.com");
}

if (substr(SITE_TITLE, -1) == "¤" || substr(SITE_TITLE, -1) == "\xa4") {
    exit("Globals not set. Please run deploy.sh");
}
date_default_timezone_set('Europe/Berlin');

$mysqlConn = new mysqli(MYSQL_HOSTNAME, MYSQL_USERNAME, MYSQL_PASSWORD, MYSQLDATABASENAME, 3306);
if ($mysqlConn->connect_errno) {
    echo "Failed to connect to MySQL: (" . $mysqlConn->connect_errno . ") " . $mysqlConn->connect_error;
}
$mysqlConn->query("SET NAMES 'utf8'");

This has worked well over the years, but moving to newer versions of PHP and trying to adhere to some best practices and standards I am considering migrating to a .env file, among other reasons, because that approach seems to be more standardized/popular.

I find myself in a chicken-and-egg situation. I would like to be able to keep this configuration, since migrating everything in a big-bang would require revisiting all build jobs, a lot of classes, and many lines of PHP code references.

My proposition as a half-measure-transition is to do the following:

  • Generate the .env file from the globals.inc.php by appending the below code to the file.
  • Coding all new classes to use a central configuration class, which reads the .env file (vlucas/phpdotenv maybe)
  • When all areas of the program use the .env file, rewrite the deploy scripts to generate the .env file
$envFileName = __DIR__ . "/.env";
function createEnvFile()
{
    global $envFileName;
    $contents = 
    "I18N_FILES=\"".I18N_FILES."\"\n".
    "I18N_CACHE=\"".I18N_CACHE."\"\n".
    "SITE_TITLE=\"".SITE_TITLE."\"\n".
    "SITE_NAME=\"".SITE_NAME."\"\n".
    "SITE_FQDN=\"".SITE_FQDN."\"\n".
    "SESSION_DURATION=\"".SESSION_DURATION."\"\n".
    "DEFAULT_FROM_EMAIL=\"".DEFAULT_FROM_EMAIL."\"\n".
    "SESSION_NAME=\"".SESSION_NAME."\"\n".
    "CERT_LOCATION=\"".CERT_LOCATION."\"\n".
    "MYSQL_USERNAME=\"".MYSQL_USERNAME."\"\n".
    "MYSQL_PASSWORD=\"".MYSQL_PASSWORD."\"\n".
    "MYSQLDATABASENAME=\"".MYSQLDATABASENAME."\"\n".
    "MYSQL_HOSTNAME=\"".MYSQL_HOSTNAME."\"\n".
    "MYSQL_PORT=\"".MYSQL_PORT."\"\n".
    "MYSQL_DSN=\"".MYSQL_DSN."\"\n".
    "DEPLOY_DATE=\"".DEPLOY_DATE."\"\n".
    "GIT_TAG_BACKEND=\"".GIT_TAG_BACKEND."\"\n".
    "GIT_TAG_FRONTEND=\"".GIT_TAG_FRONTEND."\"\n";
    file_put_contents($envFileName, $contents);

}

// check if .env file exists and has a timestamp similar to this file:
echo "checking for .env file in $envFileName";
if (file_exists($envFileName)) {
    // if file modification time is more than 10 minutes old, create a new one:
    if ( abs(filemtime(__FILE__) - filemtime($envFileName)) > 600 ){
        unlink($envFileName);
        createEnvFile();
    }
} else {
    createEnvFile();
}
\$\endgroup\$
2
  • 1
    \$\begingroup\$ Your phased approach sounds very reasonable. \$\endgroup\$ Commented Feb 5, 2024 at 21:11
  • 4
    \$\begingroup\$ I'm not so sure whether defining configuration constants in globals.inc.php is such a bad practice. It doesn't require any extra processing and everybody can understand it. Simple is good. You could however improve it. Give if a proper name: configuration.inc.php and don't initiate the database in it. \$\endgroup\$ Commented Feb 5, 2024 at 21:34

2 Answers 2

Reset to default
3
\$\begingroup\$

use sorted order when the order is arbitrary

For both of those source files I recommend you open them in Emacs and use M-x sort-lines to put the global env vars in alphabetic order.

Why? There's an old saying, that if a Fortran routine accepts seven or eight parameters, there's probably two that are still missing. I bet that a few months down the road you'll be using a couple more parameters, here.

One benefit is minimizing git merge conflicts when two engineers add different env vars. The ordering makes it perfectly obvious where the next env var belongs.

Another is that we can cleanly diff proposed changes, or audits against awk output.

Another is that ordering effectively turns this list into a set, with no duplicates. I have definitely done this:

    "MYSQL_USERNAME=\"aa\"\n".
    "MYSQL_PASSWORD=\"bb\"\n".
    "MYSQLDATABASENAME=\"cc\"\n"
    "MYSQL_HOSTNAME=\"dd\"\n".
    "MYSQL_PORT=\"ee\"\n".
    "MYSQL_DSN=\"ff\"\n".
    "MYSQL_PASSWORD=\"gg\"\n".

Do you see the bug? Yeah, neither did I nor my colleagues, the first few times staring at it. (It was a bigger list, with a bunch of MYSQL_foo, then SITE_foo, then MYSQL_foo, requiring vertical scrolling.)

I kept staring at the correct bb password, but the system kept supplying the gg password, and hilarity ensued.

Do yourself a favor, and organize the list while it is still small. Don't wait till it has doubled in size.

(You will need to adjust punctuation near GIT_TAG_FRONTEND.)

\$\endgroup\$
2
\$\begingroup\$

Commentary on the proposal to switch to using a dot env file

Switching to using a dot env file is fine, as modern frameworks like Laravel use them, though as was mentioned in comments it is fine to continue including a php file.

Consider alternatives to using a global variable

As was mentioned in this review global variables are often frowned upon. Global variables have more negative aspects than positives. One could pass the env file path to the function instead of accessing it globally. Another option would be to have the function simply return the contents so the calling code can handle writing the file contents.

Technique for simplifying function to write contents from constants

That function createEnvFile() is twenty five lines long which isn't overly long, but considering it just writes text to a file it could be seen as excessive.

One could utilize get_defined_constants(true) to get the constants defined (at index 'user'), then iterate over them to create the file contents. If more constants are defined than would be required for the env file then that list could be filtered to a white-list or only constants with a name starting with certain prefixes.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Excellent point - and I agree that "If it ain't broke, don't fix it". I like the point about get_defined_constants. that may actually solve some of the Issues I am experiencing \$\endgroup\$ Commented Feb 6, 2024 at 8:17

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.