Création d'un fichier de configuration en PHP

Question

Je veux créer un fichier de configuration pour mon projet PHP, mais je ne suis pas sûr de la meilleure façon de le faire.

J'ai trois idées pour l'instant.

Variable à usage unique

$config['hostname'] = "localhost";
$config['dbuser'] = "dbuser";
$config['dbpassword'] = "dbpassword";
$config['dbname'] = "dbname";
$config['sitetitle'] = "sitetitle";

2-Use Const

define('DB_NAME', 'test');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');
define('TITLE', 'sitetitle');

Base de données à 3 usages

J'utiliserai la configuration dans les classes et je ne suis pas sûr de la meilleure façon de procéder ou de l'existence d'une meilleure méthode.

Answer 1

Une méthode simple mais élégante consiste à créer un config.php (ou quel que soit le nom que vous lui donnez) qui renvoie simplement un tableau :

<?php

return array(
    'host' => 'localhost',
    'username' => 'root',
);

Et puis :

$configs = include('config.php');

Answer 2

Utiliser un fichier INI est une solution flexible et puissante ! PHP a une fonction native pour le gérer correctement. Par exemple, il est possible de créer un fichier INI comme celui-ci :

app.ini

[database]
db_name     = mydatabase
db_user     = myuser
db_password = mypassword

[application]
app_email = mailer@myapp.com
app_url   = myapp.com

La seule chose que vous devez faire est donc d'appeler :

$ini = parse_ini_file('app.ini');

Ensuite, vous pouvez accéder facilement aux définitions en utilisant le $ini le tableau.

echo $ini['db_name'];     // mydatabase
echo $ini['db_user'];     // myuser
echo $ini['db_password']; // mypassword
echo $ini['app_email'];   // mailer@myapp.com

IMPORTANT : Pour des raisons de sécurité, le fichier INI doit se trouver dans un dossier non public.

Answer 3

J'utilise une légère évolution de celle de @hugo_leonardo. solution :

<?php

return (object) array(
    'host' => 'localhost',
    'username' => 'root',
    'pass' => 'password',
    'database' => 'db'
);

?>

Cela vous permet d'utiliser la syntaxe objet lorsque vous incluez le fichier php : $configs->host au lieu de $configs['host'] .

De plus, si votre application a des configurations dont vous avez besoin du côté client (comme pour une application Angular), vous pouvez avoir ceci config.php contient toutes vos configurations (centralisées dans un seul fichier au lieu d'un pour JavaScript et un pour PHP). L'astuce serait alors d'avoir un autre fichier PHP qui echo seulement les informations côté client (pour éviter de montrer des informations que vous ne voulez pas montrer comme la chaîne de connexion à la base de données). Appelez-le comme suit get_app_info.php :

<?php

    $configs = include('config.php');
    echo json_encode($configs->app_info);

?>

Ce qui précède suppose que votre config.php contient un app_info paramètre :

<?php

return (object) array(
    'host' => 'localhost',
    'username' => 'root',
    'pass' => 'password',
    'database' => 'db',
    'app_info' => array(
        'appName'=>"App Name",
        'appURL'=> "http://yourURL/#/"
    )
);

?>

Ainsi, les informations de votre base de données restent du côté du serveur, mais les informations de votre application sont accessibles à partir de votre JavaScript, avec, par exemple, un fichier $http.get('get_app_info.php').then(...); le type d'appel.

Answer 4

Les options que je vois avec des mérites / faiblesses relatifs sont :

Mécanismes basés sur les fichiers

Ceux-ci exigent que votre code cherche le fichier ini à des endroits spécifiques. Il s'agit d'un problème difficile à résoudre, qui se pose toujours dans les grandes applications PHP. Cependant, vous devrez probablement résoudre ce problème afin de trouver le code PHP qui est incorporé/réutilisé lors de l'exécution.

Les approches courantes consistent à toujours utiliser des répertoires relatifs, ou à effectuer une recherche à partir du répertoire actuel vers le haut pour trouver un fichier dont le nom est exclusif au répertoire de base de l'application.

Les formats de fichiers couramment utilisés pour les fichiers de configuration sont le code PHP, les fichiers au format ini, JSON, XML, YAML et PHP sérialisé.

Code PHP

Cela offre une grande flexibilité pour représenter différentes structures de données et (en supposant qu'il soit traité via include ou require) le code analysé sera disponible dans le cache opcode, ce qui offre un avantage en termes de performances.

El include_path fournit un moyen d'abstraire les emplacements potentiels du fichier sans s'appuyer sur du code supplémentaire.

D'autre part, l'une des principales raisons de séparer la configuration du code est de séparer les responsabilités. Elle fournit une voie pour injecter du code supplémentaire dans le runtime.

Si la configuration est créée à partir d'un outil, il peut être possible de valider les données dans l'outil, mais il n'existe pas de fonction standard pour échapper les données pour les intégrer dans le code PHP comme cela existe pour le HTML, les URL, les déclarations MySQL, les commandes shell.....

Données sérialisées Cette méthode est relativement efficace pour de petites quantités de configuration (jusqu'à environ 200 éléments) et permet d'utiliser n'importe quelle structure de données PHP. Elle nécessite très peu de code pour créer/parser le fichier de données (vous pouvez donc consacrer vos efforts à vous assurer que le fichier n'est écrit qu'avec l'autorisation appropriée).

L'échappement du contenu écrit dans le fichier est géré automatiquement.

Puisque vous pouvez sérialiser des objets, cela crée une opportunité pour invoquer du code simplement en lisant le fichier de configuration (la méthode magique __wakeup).

Fichier structuré

Le stockage dans un fichier INI, comme suggéré par Marcel, ou JSON ou XML, fournit également une interface simple pour convertir le fichier en une structure de données PHP (et, à l'exception de XML, pour échapper les données et créer le fichier) tout en éliminant la vulnérabilité de l'invocation de code en utilisant des données PHP sérialisées.

Il aura des caractéristiques de performance similaires à celles des données sérialisées.

Stockage des bases de données

Il est préférable d'envisager cette solution lorsque vous disposez d'un grand nombre de configurations, mais que vous êtes sélectif dans ce qui est nécessaire pour la tâche en cours. J'ai été surpris de constater qu'à partir d'environ 150 éléments de données, il était plus rapide de récupérer les données à partir d'une instance MySQL locale que de désérialiser un fichier de données.

En revanche, ce n'est pas un bon endroit pour stocker les informations d'identification que vous utilisez pour vous connecter à votre base de données !

L'environnement d'exécution

Vous pouvez définir des valeurs dans le environnement d'exécution PHP est exécuté dans.

Cela supprime toute obligation pour le code PHP de rechercher la configuration à un endroit spécifique. En revanche, elle n'est pas adaptée à de grandes quantités de données et il est difficile de la modifier universellement au moment de l'exécution.

Sur le client

Un endroit que je n'ai pas mentionné pour stocker les données de configuration est le client. Là encore, la surcharge du réseau fait que cette solution n'est pas adaptée à de grandes quantités de configuration. Et puisque l'utilisateur final a le contrôle des données, celles-ci doivent être stockées dans un format où toute altération est détectable (c'est-à-dire avec une signature cryptographique) et ne doivent pas contenir d'informations compromises par leur divulgation (c'est-à-dire cryptées de manière réversible).

Inversement, cela présente de nombreux avantages pour le stockage d'informations sensibles appartenant à l'utilisateur final : si vous ne les stockez pas sur le serveur, elles ne peuvent pas être volées.

Annuaires de réseaux Un autre endroit intéressant pour stocker les informations de configuration est le DNS / LDAP. Cela fonctionnera pour un petit nombre de petits éléments d'information - mais vous n'avez pas besoin de vous en tenir à la 1ère forme normale - considérez par exemple SPF .

L'infrastructure prend en charge la mise en cache, la réplication et la distribution. Elle fonctionne donc bien pour les très grandes infrastructures.

Systèmes de contrôle de version

La configuration, tout comme le code, doit être gérée et faire l'objet d'un contrôle de version. Obtenir la configuration directement à partir de votre système VC est donc une solution viable. Mais cela s'accompagne souvent d'un surcoût important en termes de performances, d'où l'intérêt de la mise en cache.

Answer 5

Il serait difficile de stocker les données de configuration de la base de données dans une base de données, n'est-ce pas ?

Mais en réalité, il s'agit d'une question très controversée, car tous les styles fonctionnent, c'est une question de préférence. Personnellement, j'opterais pour une variable de configuration plutôt que pour des constantes - généralement parce que je n'aime pas les choses dans l'espace global, sauf si elles sont nécessaires. Aucune des fonctions de ma base de code ne devrait pouvoir accéder facilement au mot de passe de ma base de données (à l'exception de ma logique de connexion à la base de données) - je l'utiliserais donc à cet endroit, puis je le détruirais probablement.

Modifier Pour répondre à votre commentaire, aucun des mécanismes d'analyse syntaxique n'est le plus rapide (ini, json, etc.), mais ce ne sont pas non plus les parties de votre application que vous devez vraiment optimiser puisque la différence de vitesse est négligeable sur des fichiers aussi petits.