Cada aplicación symfony consta de una colección de paquetes que añaden herramientas útiles (servicios) a su proyecto. Cada paquete se puede personalizar a través de archivos de configuración que viven - por defecto - en el directorio app / config.

Configuración: config.yml

El archivo de configuración principal se llama config.yml:

config yml symfony3

Referencia de configuración y dumping

Hay dos maneras de saber qué claves puede configurar:

  • Utilice la sección de referencia;
  • Utilice el mandato config: dump-reference.

Por ejemplo, si desea configurar algo en Twig, puede ver un ejemplo de volcado de todas las opciones de configuración disponibles ejecutando:

php bin/console config:dump-reference twig

La clave de importaciones: Cargando otros archivos de configuración

El archivo de configuración principal de Symfony es app / config / config.yml. Pero, para la organización, también carga otros archivos de configuración a través de su clave de importaciones:

las claves de importacion configuracion de symfony 3

La clave de importaciones funciona como la función include () de PHP: se leen y se cargan los contenidos de parameters.yml, security.yml y services.yml. También puede cargar archivos XML o archivos PHP.

Si su aplicación utiliza extensiones de archivo no convencionales (por ejemplo, sus archivos YAML tienen una extensión .res) puede establecer el tipo de archivo explícitamente con la opción type:

cambiar extension yml de yaml symfony 3

Puede definir cualquier nombre de parámetro que desee bajo la clave de parámetros de cualquier archivo de configuración. Para hacer referencia a un parámetro, rodee su nombre con signos de dos por ciento - p. %locale%.

El archivo Special parameters.yml

En la superficie, parameters.yml es como cualquier otro archivo de configuración: es importado por config.yml y define varios parámetros:

special parametres symfony 3

Pero el archivo parameters.yml es especial: define los valores que normalmente cambian en cada servidor. Por ejemplo, las credenciales de base de datos en su máquina de desarrollo local pueden ser diferentes de sus compañeros de trabajo. Es por eso que este archivo no está asignado al repositorio compartido y sólo se almacena en su máquina.

Debido a eso, parameters.yml no está comprometido con su control de versiones. De hecho, el archivo .gitignore que viene con Symfony evita que se cometa.

Sin embargo, se compromete un archivo parameters.yml.dist (con valores ficticios). Symfony no lee este archivo: es sólo una referencia para que Symfony conozca qué parámetros deben definirse en el archivo parameters.yml. Si agrega o quita claves a parameters.yml, agregue o elimínelos de parameters.yml.dist también para que ambos archivos estén siempre sincronizados.

Ambientes y otros archivos de configuración

Sólo tienes una aplicación, pero si te das cuenta o no, necesitas que se comporte de manera diferente en momentos diferentes

Durante el desarrollo, desea que su aplicación registre todo y exponga las herramientas de depuración;

Después de implementar en la producción, desea que la misma aplicación se optimice para la velocidad y sólo errores de registro.

¿Cómo puede hacer que una aplicación se comporte de dos maneras diferentes? Con ambientes.

Probablemente ya has estado utilizando el entorno de desarrollo sin siquiera saberlo. Después de implementar, usará el entorno prod.

Cómo organizar archivos de configuración

El estándar Symfony Standard Edition define tres entornos de ejecución llamados dev, prod y test. Un entorno simplemente representa una manera de ejecutar la misma base de código con diferentes configuraciones.

Para seleccionar el archivo de configuración a cargar para cada entorno, Symfony ejecuta el método registerContainerConfiguration () de la clase AppKernel:

clase appkernel symfony3

Este método carga el archivo app / config / config_dev.yml para el entorno dev y así sucesivamente. A su vez, este archivo carga el archivo de configuración común ubicado en app / config / config.yml. Por lo tanto, los archivos de configuración de Symfony Standard Edition por defecto siguen esta estructura:

estructura directorio config symfony 3

 

Esta estructura predeterminada se eligió por su simplicidad: un archivo por entorno. Pero como cualquier otra característica de Symfony, puedes personalizarla para que se adapte mejor a tus necesidades. Las siguientes secciones explican diferentes maneras de organizar sus archivos de configuración. Con el fin de simplificar los ejemplos, sólo los entornos de dev y prod se tienen en cuenta.

Diferentes directorios por entorno

En lugar de sufijo los archivos con _dev y _prod, esta técnica agrupa todos los archivos de configuración relacionados en un directorio con el mismo nombre que el entorno:

directorio con mismo nombre que entorno symfony 3

Para que esto funcione, cambie el código del método registerContainerConfiguration():

registercontainerconfiguration symfony 3

A continuación, asegúrese de que cada archivo config.yml cargue el resto de los archivos de configuración, incluidos los archivos comunes. Por ejemplo, esto sería las importaciones necesarias para el archivo app / config / dev / config.yml:

cargar resto de archivos de configuarcion en config.yml symfony 3

Debido a la forma en que se resuelven los parámetros, no puede utilizarlos para crear rutas de importación dinámicamente. Esto significa que algo como lo siguiente no funciona:

no puedo usar los parametros para crear rutas de importacion symfony 3 

Archivos de configuración semántica

Puede ser necesaria una estrategia de organización diferente para aplicaciones complejas con archivos de configuración de gran tamaño. Por ejemplo, puede crear un archivo por paquete y varios archivos para definir todos los servicios de aplicaciones:

archivos de configuracion semantica symfony 3

Nuevamente, cambie el código del método registerContainerConfiguration () para que Symfony esté al tanto de la nueva organización de archivos

cambie el código del método registerContainerConfiguration symfony 3

Asegúrese de importar los archivos de configuración apropiados de cada archivo principal (common.yml, dev.yml y prod.yml).

Técnicas avanzadas

Symfony carga archivos de configuración utilizando el componente Config, que proporciona algunas funciones avanzadas.

Formatos de configuración de mezcla y coincidencia

Los archivos de configuración pueden importar archivos definidos con cualquier otro formato de configuración incorporado (.yml, .xml, .php, .ini):

Formatos de configuración de mezcla y coincidencia symfony 3

IniFileLoader analiza el contenido del archivo mediante la función parse_ini_file. Por lo tanto, sólo puede establecer parámetros para valores de cadena. Utilice uno de los otros cargadores si desea utilizar otros tipos de datos (por ejemplo, booleano, entero, etc.).

Si utiliza cualquier otro formato de configuración, debe definir su propia clase de cargador que lo extienda desde FileLoader. Cuando los valores de configuración son dinámicos, puede utilizar el archivo de configuración de PHP para ejecutar su propia lógica. Además, puede definir sus propios servicios para cargar configuraciones desde bases de datos o servicios web.

Archivos de configuración global

Algunos administradores de sistemas pueden preferir almacenar parámetros sensibles en archivos fuera del directorio del proyecto. Imagine que las credenciales de la base de datos de su sitio web se almacenan en el archivo /etc/sites/mysite.com/parameters.yml. La carga de este archivo es tan simple como indicar la ruta completa del archivo al importarla desde cualquier otro archivo de configuración:

importar archivo de configuracion desde otro archivo symfony 3

La mayoría de las veces, los desarrolladores locales no tendrán los mismos archivos que existen en los servidores de producción. Por esta razón, el componente Config proporciona la opción ignore_errors para descartar silenciosamente los errores cuando el archivo cargado no existe:

componente Config proporciona la opción ignore errors symfony 3

hay muchas maneras de organizar tus archivos de configuración. Puede elegir uno de estos o incluso crear su propia forma personalizada de organizar los archivos. No se sienta limitado por la edición estándar que viene con Symfony.

Cómo dominar y crear nuevos entornos

Cada aplicación es la combinación de código y un conjunto de configuración que dicta cómo debería funcionar ese código. La configuración puede definir la base de datos que se está utilizando, si algo debe almacenarse en caché o cómo debería ser el registro detallado.

En Symfony, la idea de "entornos" es la idea de que la misma base de código se puede ejecutar utilizando múltiples configuraciones diferentes. Por ejemplo, el entorno de dev debe utilizar la configuración que hace que el desarrollo sea fácil y amigable, mientras que el entorno prod debe utilizar un conjunto de configuración optimizada para la velocidad.

Entornos diferentes, diferentes archivos de configuración

Una aplicación típica de Symfony comienza con tres entornos: dev, prod y test. Como se mencionó, cada entorno simplemente representa una forma de ejecutar la misma base de código con diferentes configuraciones. No debería sorprender entonces que cada entorno cargue su propio archivo de configuración individual. Si utiliza el formato de configuración YAML, se utilizan los siguientes archivos:

Para el entorno dev: app / config / config_dev.yml

Para el entorno prod: app / config / config_prod.yml

Para el entorno de prueba: app / config / config_test.yml

Esto funciona a través de un estándar simple que se utiliza por defecto dentro de la clase AppKernel:

class appekernel symfony 3 entornos

Como puede ver, cuando se carga Symfony, usa el entorno dado para determinar qué archivo de configuración cargar. Esto logra el objetivo de múltiples entornos de una manera elegante, potente y transparente.


Por supuesto, en realidad, cada entorno difiere solo un poco de los demás. En general, todos los entornos compartirán una gran base de configuración común. Al abrir el archivo de configuración config_dev.yml, puede ver cómo esto se lleva a cabo de manera fácil y transparente:

archivo config dev yml symfony 3

Ejecución de una aplicación en diferentes entornos

Para ejecutar la aplicación en cada entorno, cargue la aplicación utilizando el controlador frontal app.php (para el entorno prod) o app_dev.php (para el entorno dev):

http://localhost/app.php      -> *prod* environment
http://localhost/app_dev.php  -> *dev* environment

Si no tiene ningún nombre de archivo en su URL, le corresponde al servidor web decidir qué archivo ejecutar detrás de las escenas. Si está utilizando el servidor web PHP integrado, sabe utilizar el archivo app_dev.php. En la producción, configurará su servidor web para usar app.php. De cualquier manera: uno de estos dos archivos siempre se ejecuta.

Las URLs dadas suponen que su servidor web está configurado para usar el directorio web / de la aplicación como su raíz. 

Si abre uno de estos archivos, verá rápidamente que el entorno utilizado por cada uno está definido explícitamente:

archivo entrono prod app

La clave prod especifica que esta aplicación se ejecutará en el entorno prod. Una aplicación Symfony se puede ejecutar en cualquier entorno utilizando este código y cambiando la cadena de entorno

El entorno de prueba se utiliza al escribir pruebas funcionales y no es accesible en el navegador directamente a través de un controlador frontal. En otras palabras, a diferencia de los otros entornos, no hay ningún archivo controlador app_test.php.

Modo de depuración

Importante, pero no relacionado con el tema de los entornos es el argumento false como el segundo argumento para el constructor de AppKernel. Esto especifica si la aplicación debe ejecutarse en "modo de depuración". Independientemente del entorno, se puede ejecutar una aplicación Symfony con el modo de depuración configurado como true o false. Esto afecta a muchas cosas en la aplicación, como la visualización de stacktraces en páginas de error o si los archivos de caché se reconstruyen dinámicamente en cada solicitud. Aunque no es un requisito, el modo de depuración generalmente se establece en true para los entornos de dev y prueba y falso para el entorno prod.

Internamente, el valor del modo de depuración se convierte en el parámetro kernel.debug utilizado dentro del contenedor de servicio. Si observa el archivo de configuración de la aplicación, verá el parámetro utilizado, por ejemplo, para activar o desactivar el registro al utilizar Doctrine DBAL:

modeo depuracion symfony 3

Selección del entorno para los comandos de consola

De forma predeterminada, los comandos de Symfony se ejecutan en el entorno de dev y con el modo de depuración habilitado. Utilice las opciones --env y --no-debug para modificar este comportamiento:

seleccion entorno para los comandos de consola symfony 3

 

Además de las opciones -env y -no-debug, el comportamiento de los comandos de Symfony también puede controlarse con variables de entorno. La aplicación de consola Symfony comprueba la existencia y el valor de estas variables de entorno antes de ejecutar cualquier comando:

SYMFONY_ENV

Establece el entorno de ejecución del comando al valor de esta variable (dev, prod, test, etc.);

SYMFONY_DEBUG

Si 0, el modo de depuración está deshabilitado. De lo contrario, el modo de depuración está habilitado.

Estas variables de entorno son muy útiles para los servidores de producción porque permiten garantizar que los comandos se ejecuten siempre en el entorno prod sin tener que agregar ninguna opción de comando.

Crear un nuevo entorno

De forma predeterminada, una aplicación Symfony tiene tres entornos que manejan la mayoría de los casos. Por supuesto, ya que un entorno no es más que una cadena que corresponde a un conjunto de configuración, crear un nuevo entorno es bastante fácil.

Supongamos, por ejemplo, que antes de la implementación, necesita comparar su aplicación. Una forma de comparar la aplicación es usar la configuración de producción cercana, pero con el web_profiler habilitado para Symfony. Esto permite a Symfony registrar información sobre su aplicación mientras compara.

La mejor manera de lograr esto es a través de un nuevo entorno llamado, por ejemplo, benchmark. Comience creando un nuevo archivo de configuración:

 configuracion entorno benchmark symfony 3

Y con esta simple adición, la aplicación ahora soporta un nuevo entorno llamado benchmark.

Este nuevo archivo de configuración importa la configuración del entorno prod y la modifica. Esto garantiza que el nuevo entorno es idéntico al ambiente prod, excepto los cambios explícitamente realizados aquí.

Debido a que querrá que este entorno sea accesible a través de un navegador, también debe crear un controlador frontal para ello. Copie el archivo web / app.php a web / app_benchmark.php y edite el entorno para que sea referencia:

app benchmark entorno nuevo symfony 3

El nuevo entorno es ahora accesible a través de:

http://localhost/app_benchmark.php

Algunos entornos, como el entorno de dev, nunca están destinados a ser accesados ​​por el público en ningún servidor implementado. Esto se debe a que ciertos entornos, para propósitos de depuración, pueden dar demasiada información sobre la aplicación o la infraestructura subyacente. Para asegurarse de que estos entornos no son accesibles, el controlador frontal normalmente está protegido de direcciones IP externas mediante el siguiente código en la parte superior del controlador:

proteccion entorno dev solo local symfony 3

Entornos y el Directorio de caché

Symfony aprovecha el almacenamiento en caché de muchas maneras: la configuración de la aplicación, la configuración de enrutamiento, las plantillas Twig y más se almacenan en caché en objetos PHP almacenados en archivos del sistema de archivos.

De forma predeterminada, estos archivos almacenados en caché se almacenan en gran medida en el directorio var / cache. Sin embargo, cada entorno almacena en caché su propio conjunto de archivos:

directorio cache tu entorno symfony 3

A veces, al depurar, puede ser útil para inspeccionar un archivo en caché para entender cómo está funcionando algo. Al hacerlo, recuerde buscar en el directorio del entorno que está utilizando (más comúnmente desarrollando y depurando). Aunque puede variar, el directorio var / cache / dev incluye lo siguiente:

AppDevDebugProjectContainer.php

El "contenedor de servicio" en caché que representa la configuración de la aplicación en caché.

AppDevUrlGenerator.php

La clase PHP generada a partir de la configuración de enrutamiento y utilizada al generar URL.

AppDevUrlMatcher.php

La clase PHP utilizada para la coincidencia de rutas - mire aquí para ver la lógica de expresión regular compilada utilizada para coincidir con URL entrantes a diferentes rutas.

Twig/

Este directorio contiene todas las plantillas de Twig almacenadas en caché.

Puede cambiar fácilmente la ubicación y el nombre del directorio.

Cómo establecer parámetros externos en el contenedor de servicio

En el artículo Configuración de Symfony (y Entornos), aprendió a administrar la configuración de la aplicación. A veces, puede beneficiar su aplicación para almacenar ciertas credenciales fuera del código del proyecto. La configuración de la base de datos es un ejemplo. La flexibilidad del contenedor de servicios Symfony le permite hacerlo fácilmente.

Variables de entorno

Puede referenciar variables de entorno utilizando parámetros especiales nombrados después de las variables que desea utilizar entre env (). Sus valores reales se resolverán en tiempo de ejecución (una vez por solicitud), de modo que los contenedores objeto de dumping pueden reconfigurarse dinámicamente incluso después de ser compilados.

Por ejemplo, si desea utilizar el valor de la variable de entorno DATABASE_HOST en su configuración de contenedor de servicio, puede hacer referencia a ello mediante% env (DATABASE_HOST)% en sus archivos de configuración:

desea utilizar el valor de la variable de entorno DATABASE HOST symfony 3

También puede asignar a los parámetros env () un valor por defecto: el valor por defecto se utilizará siempre que no se encuentre la variable de entorno correspondiente:

asignar a los parámetros env un valor por defecto symfony 3

El establecimiento de variables de entorno generalmente se realiza en el nivel del servidor web o en el terminal. Si está utilizando Apache, Nginx o simplemente la consola, puede utilizar, por ejemplo, uno de los siguientes:

Apache

apache variable de entorno

Ngix

NGIX variable de entorno symfony 3

Terminal

terminal variable de entorno symfony 3

El soporte de las SYMFONY__variables de entorno especiales quedó obsoleto en Symfony 3.3 y se eliminará en 4.0. En lugar de usar esas variables, defina variables de entorno regulares y obtenga sus valores usando la %env(...)%sintaxis en sus archivos de configuración.
También puede definir el valor predeterminado de cualquier parámetro existente utilizando variables de entorno especiales nombradas después de su parámetro correspondiente con el prefijo SYMFONY__después de reemplazar puntos por subrayados dobles (por ejemplo, SYMFONY__KERNEL__CHARSETpara establecer el valor predeterminado delkernel.charsetparámetro). Estos valores predeterminados se resuelven al compilar el contenedor de servicios y no se modificarán en el tiempo de ejecución una vez que se vuelque.

Parámetros en archivos de configuración


Use la parameterssección de un archivo de configuración para establecer los parámetros:

parametrers section symfony 3

Puede consultar los parámetros en cualquier otro lugar de cualquier archivo de configuración rodeándolos con %signos de porcentaje ( ), p %mailer.transport%. Ej . Un uso para esto es inyectar los valores en sus servicios. Esto le permite configurar diferentes versiones de servicios entre aplicaciones o servicios múltiples basados ​​en la misma clase pero configurados de manera diferente en una sola aplicación. Puede inyectar la opción de transporte de correo en la Mailerclase directamente. Pero declararlo como un parámetro hace que sea más fácil cambiar en lugar de estar atado y oculto con la definición del servicio:

inyectar parametro en una clase directamente symfony 3

Los valores entre las parameteretiquetas en los archivos de configuración XML no se recortan.
Esto significa que la siguiente muestra de configuración tendrá el valor \n sendmail\n:

valores entre las parametrers etiquetas symfony 3

En algunos casos (para constantes o nombres de clase), esto podría arrojar errores. Para evitar esto, siempre debe alinear sus parámetros de la siguiente manera:

evitar errores asignando parametrsos symfony 3
Si usa una cadena que comienza con @o tiene algún %lugar en ella, debe escapar agregando otra @o %:


cadena con arroba symfony 3

Obtener y configurar los parámetros del contenedor en PHP

Trabajar con los parámetros del contenedor es sencillo utilizando los métodos de acceso del contenedor para los parámetros:

metodos de acceso al contenedor para parametros symfony 3

La notación "." utilizada es solo una convención de Symfony para facilitar la lectura de los parámetros. Los parámetros son simplemente elementos de valor-clave planos, no se pueden organizar en una matriz anidada.
Solo puede establecer un parámetro antes de compilar el contenedor: no en tiempo de ejecución. Para obtener más información sobre la compilación del contenedor

Parámetros de la matriz

Los parámetros no necesitan ser cadenas planas, también pueden contener valores de matriz. Para el formato XML, necesita usar el type="collection"atributo para todos los parámetros que son matrices.

parametros de la matriz symfony 3

Constantes

El contenedor también tiene soporte para establecer constantes de PHP como parámetros.

constantes como parametros symfony 3

Palabras clave de PHP en XML

De manera predeterminada, true, falsey nullen XML se convierten en las palabras clave de PHP (respectivamente true, falsey null):

palabras clave php en xml symfony 3

Para deshabilitar este comportamiento, use el tipo string:

deshabilitar palabras clave de php con tipo string symfony 3

Configuración miscelánea

La directiva imports puede usarse para obtener parámetros almacenados en otro lugar. La importación de un archivo PHP le brinda la flexibilidad de agregar lo que sea necesario en el contenedor. Lo siguiente importa un archivo llamado parameters.php.

directiva import para obtener parametros almacenados en otro lugar symfony 3

En parameters.php, indique al contenedor del servicio los parámetros que desea establecer. Esto es útil cuando la configuración importante está en un formato no estándar. El siguiente ejemplo incluye una configuración de base de datos Drupal en el contenedor de servicios de Symfony.

configuración de base de datos Drupal en el contenedor de servicios de Symfony

 

 

 

Web Analytics