Como se usa config:import magento 2

Prioridades/jerarquía de lectura de valores de configuraciones

Podemos tener un valor para una configuración establecido en varios sitios, y hay un orden, una jerarquía. Estos valores puede venir de (el último sobreescribe al anterior):

  1. Variables en base de datos (las cambiamos desde el admin)
  2. Variables en ficheros de configuración de Magento (config.php y env.php)
  3. Variables del sistema

Es decir, que si tenemos un valor para web/unsecure/base_url en un fichero de configuración (será el env.php), éste sobreescribirá (o mejor dicho, será leído antes) que lo que haya establecido en la base de datos.

Magento por ello, nos da herramientas para exportar e importar valores de estas configuraciones en base de datos a ficheros de configuración, y así poder mover toda la configuración que hayamos hecho en una tienda a otra instalación de magento.

Veremos que podemos exportar estas configuraciones en bloque con un comando, o ir seleccionando solo aquellas que necesitemos para luego importarlas.

Comandos para establecer y ver configuraciones del admin

En Magento podemos usar comandos para las opciones de configuración sin entrar al admin a cambiarlos o verlos:

bin/magento config:show
bin/magento config:set
bin/magento config:sensitive:set

Si usamos el comando config:set a secas, nos establecerá el valor en el admin y dejará que siga siendo editable, sin guardarlo en ningún fichero. No podemos usar este comando con configuraciones “sensibles”. Por ejemplo:

bin/magento config:set web/unsecure/base_url http://example.com/

NOTA: config:set no permitirá establecer un valor si dicha variable ya se encuentra volcada en un archivo de configuración, y nos tirará un mensaje de usar uno de los parámetros, o bien –lock-env o bien –lock-config.

Sin embargo si lo usamos así config:set –lock-env bloquea esta opción en el admin (no puede ser editada desde el admin) y nos copia el valor en app/etc/env.php, fichero que es específico a nuestro sistema y no debería transferirse entre equipos ni debe ser versionado. Por ejemplo (usamos otros parámetros referentes a scopes):

bin/magento config:set --lock-env --scope=stores --scope-code=default web/unsecure/base_url http://example3.com

El env.php nos viene muy bien para sobreescribir valores en la base de datos, por ejemplo la base_url, así no tenemos que tocar la base de datos

También podemos bloquear esta opción en el admin, pero llevárnosla al fichero app/etc/config.php. Este fichero sí podemos transferirlo entre equipos ya que contiene configuración compartida y no sensible, y debería ser por tanto versionado. Por ejemplo:

bin/magento config:set --lock-config --scope=stores --scope-code=default web/url/use_store 1

La config:sensitive:set establecerá un valor “sensible”. Es un poco especial, porque requiere previamente haber volcado en el env.php. Lo vemos más adelante cuando hayamos visto el volcado con app:config:dump o config:set –lock-env

  • Previamente, como dijimos, hemos de realizar un app:config:dump para tener el dato en el env.php
  • Teóricamente también con un config:set –lock-env debería dar el mismo resultado pero al menos a mí no… me da por consola el mensaje “There are no sensitive configurations to fill”
  • Tras el app:config:dump, nos permitirá asignar un valor sensible en el env.php bloquear esta opción desde el admin (por ejemplo para trans_email/ident_general/name)

Exportar las configuraciones de Magento con app:config:dump

Podemos exportar nuestras configuraciones a ficheros (al env.php y al config.php) con el comando:

bin/magento app:config:dump {config-types}

{config-types} es una lista de las configuraciones que queremos: scopes, system, themes, i18n. Por ejemplo:

bin/magento app:config:dump scopes themes

Obtendremos en app/etc/config.php ese listado listo para hacer el import. En el env.php no tendremos nada porque ni scopes ni themes son configuraciones ni sensibles ni dependientes del sistema, son configuraciones compartidas.

Sin embargo si hacemos directamente:

bin/magento app:config:dump

Lo vuelva todo. Obtendremos el siguiente mensaje:

  • Shared configuration was written to config.php and system-specific configuration to env.php.
  • Shared configuration file (config.php) doesn’t contain sensitive data for security reasons.
  • Sensitive data can be stored in the following environment variables:
    • (listado de variables)

Nos escribe todas las configuraciones no sensibles y sensibles: en el env.php lo específico de este sistema y/o sensible, y en el config.php lo que es compartido y/o no sensible.

Ahora que hemos volcado la info en archivos de configuración, ya podemos ejecutar el comando config:sensitive:set para modificar algún valor de los que se han volcado. También, habrán quedado bloqueadas las opciones en el admin, y para modificar cualquier opción, o editamos manualmente el archivo o usamos config:set –lock-env, config:set –lock-config o config:sensitive:set

Importar de archivos de configuración a Magento

El comando es:

bin/magento app:config:import [-n, --no-interaction]

Esto nos importa desde los ficheros env.php y config.php, los valores de las variables de configuración a Magento, cuando nos hemos traído esto normalmente desde la misma web en otro entorno (estamos en producción y venimos de desarrollo por ejemplo).

Si no usamos el parámetro -n del comando, nos pedirá confirmación para ejecutar los cambios.

¿Qué se importa realmente?

Variables del sistema: no se importan, se leen de estos archivos directamente como se ha descrito en la jerarquía de lectura anteriormente. Esto se debe a que muchos de estos valores necesitan una validación previa y posterior a su uso.

Websites, stores, storeviews: estarán en el config.php. Creará, actualizará o borrará cualquier cambio que hayamos hecho respecto a estas configuraciones.

Configuraciones del theme: registra o no registra nuevos themes

¿Qué ocurre si modificamos el archivo manualmente?

Si por ejemplo, hemos hecho el volcado y nos vamos al env.php y metemos manualmente un nuevo store view siguiendo la estructura del fichero, al cargar el admin verá el cambio hecho y nos pedirá ejecutar un app:config:import o un setup:upgrade.

Hay un control entre lo que se ha importado y lo que se haya en los ficheros.

Al ejecutar app:config:import nos avisará “These Stores will be created: …” indicando el nombre del store view.

Y si ejecutamos setup:upgrade, en el proceso nos hará la misma pregunta.

¿Qué ocurre si tras el volcado, borramos los datos de los ficheros de configuración?

Los themes registrados y activos no cambian. Como tampoco ocurre con los websites, stores, o store views que se hayan creado.

Pero la configuración en system se perderá, ya que esta configuración como hemos mencionado, no se importa guardándola en base de datos sino que se lee de los archivos directamente.

Si las borramos y recargamos el admin, veremos que los valores de las opciones que hemos seteado ya no son los mismos, son los antiguos y que ya no están bloqueado para su edición desde el admin.

¿Y de qué sirve todo esto?

Nos permite volcar información que normalmente solo está en base de datos, a ficheros. De forma que podemos versionarlos y realizar migraciones o simplemente subir a algún sitio los cambios hechos en uno de los sistemas (mi local por ejemlo) a otro (staging por ejemplo).