- Cron jobs
- Mensajes de notificación
- Sesiones y cookies
- Inicio sesión
- Perfilador
- Eventos y observadores
- cachés
- widgets
- Variables personalizadas
- i18n (internacionalización)
- Indexadores
Desarrolladores Backend en Magento 2
Desarrolladores Backend en Magento 2
Gratis
Conceptos principales de desarrolladores Backend para Magento 2
Cron jobs
Hablando de trabajos cron, vale la pena señalar una cosa importante. Un trabajo cron de Magento no es lo mismo que un trabajo cron del sistema operativo. Un cron del sistema operativo está controlado por un archivo crontab (abreviatura de tabla cron). El archivo crontab es un archivo de configuración que especifica los comandos de shell que deben ejecutarse periódicamente según un cronograma determinado.
Un trabajo cron de Magento es impulsado por una ejecución periódica de código PHP que maneja las entradas en la tabla cron_schedule. La tabla cron_schedule es donde los trabajos cron de Magento se ponen en cola una vez que se seleccionan del archivo crontab.xml individual.
Los trabajos cron de Magento no se pueden ejecutar sin que el trabajo cron del sistema operativo esté configurado para ejecutar el comando php bin/magento cron:run. Idealmente, se debería configurar un trabajo cron del sistema operativo para activar el cron:run de Magento cada minuto. Luego, Magento ejecutará internamente sus trabajos cron de acuerdo con la forma en que se define un trabajo cron individual en el archivo crontab.xml.
Para definir un nuevo trabajo cron en Magento cron, primero debemos definir un archivo crontab.xml en el módulo. Creemos un archivo app/code/Marcgento/Office/etc/crontab.xml con el siguiente contenido:
Tenga en cuenta que la ubicación del esquema XSD apunta a crontab.xsd desde el módulo Magento_Cron. El atributo de identificación de un elemento de grupo se establece en el valor predeterminado. En sus módulos, Magento define dos grupos diferentes, a saber, predeterminado e índice. Usamos el valor predeterminado, ya que este es el que se ejecuta cuando se activa el comando estándar php bin/magento cron:run en la consola. Dentro del elemento de grupo, tenemos trabajos individuales definidos bajo el elemento de trabajo. El elemento de trabajo requiere que especifiquemos los atributos de nombre, instancia y método. El atributo de nombre debe ser único dentro del elemento del grupo. El valor de los atributos de instancia y método debe apuntar a la clase de la que se creará una instancia y al método dentro de la clase que debe ejecutarse.
El elemento de programación anidado dentro del trabajo cron especifica el tiempo deseado de ejecución del trabajo. Utiliza la misma expresión de tiempo que la de las entradas en un archivo crontab del sistema operativo. El ejemplo específico que veremos define una expresión (*/2 * * * *) que se ejecuta cada dos minutos.
Una vez que hemos definido el archivo crontab.xml, necesitamos definir el archivo de clase Marcgento\Office\Model\Cron, de la siguiente manera:
El código anterior simplemente define un método logHello utilizado por el trabajo cron. En el método logHello, utilizamos el método logger del que se creó una instancia a través del constructor. El método logger realizará una entrada de registro en el archivo var/log/system.log una vez que se ejecute.
Una vez que se ejecuta el comando, verá el mensaje Ejecutar trabajos por programación en la consola. Además, la tabla cron_schedule debería llenarse con todos los trabajos cron de Magento que se definieron.
En este punto, deberíamos activar el comando php bin/magento cron:run en la consola.
La tabla cron_schedule contiene las siguientes columnas:
- schedule_id: el campo principal de incremento automático.
- job_code: el valor del atributo de nombre del trabajo, tal como se define en el archivo crontab.xml, que equivale a la tabla marcgento_office_logHello en nuestro ejemplo.
- status: El valor predeterminado es el valor pendiente para las entradas recién creadas en la tabla y permite un valor pendiente, en ejecución, exitoso, perdido o de error. Su valor cambia a medida que el trabajo cron recorre su ciclo de vida.
- messages: almacena el mensaje de error de posible excepción si la excepción ha ocurrido durante la ejecución de un trabajo.
- create_at: el valor de la marca de tiempo que indica cuándo se creó un trabajo.
- scheduled_at: el valor de la marca de tiempo que indica cuándo se programó la ejecución de un trabajo.
- executed_at: el valor de la marca de tiempo que indica cuándo comenzó la ejecución de un trabajo.
- finished_at: el valor de la marca de tiempo que indica cuándo finalizó la ejecución de un trabajo.
A menos que ya hayamos configurado el cron del sistema operativo para activar el comando php bin/magento cron:run, debemos activarlo por nuestra cuenta varias veces cada dos minutos para poder ejecutar el trabajo. La primera vez que se ejecuta un comando, si el trabajo no existe en la tabla cron_schedule, Magento simplemente lo pondrá en cola, pero no lo ejecutará. Las ejecuciones cron posteriores ejecutarán el comando. Una vez que estemos seguros de que la entrada del trabajo cron en la tabla cron_schedule tiene el valor de la columna finished_at completo, veremos una entrada que se parece a [2015-11-21 09:42:18] main.INFO: ¡Hola desde el trabajo cron! [] [] en el archivo var/log/system.log.
Mientras desarrollamos y probamos trabajos cron en Magento, es posible que necesitemos truncar la tabla cron_schedule, eliminar el valor var/cache de Magento y ejecutar el comando php bin/magento cron:run repetidamente hasta que lo pruebemos y funcione.
Mensajes de notificación
Magento implementa el mecanismo de mensajes de notificación a través del módulo Mensajes. El módulo Messages se ajusta a \Magento\Framework\Message\ManagerInterface. Aunque la interfaz en sí no impone ninguna relación de sesión, una implementación agrega tipos de mensajes definidos por la interfaz a una sesión y permite el acceso a esos mensajes más adelante. En el archivo app/etc/di.xml, hay una preferencia definida para \Magento\Framework\Message\ManagerInterface hacia la clase Magento\Framework\Message\Manager.
Message\ManagerInterface especifica cuatro tipos de mensajes: error, warning, notice y success. Los tipos de mensajes van seguidos de varios métodos clave en la clase Message\Manager, como addSuccess, addNotice, addWarning, addError y addException. El método addException es básicamente un contenedor para addError que acepta un objeto de excepción como parámetro.
Intentemos ejecutar el siguiente código en el método de ejecución de app/code/Marcgento/Office/Controller/Test/Crud.php:
Una vez ejecutado este código, el resultado, como se muestra en la siguiente captura de pantalla, aparecerá en la página del navegador:
Los mensajes de notificación aparecen tanto en el área de interfaz como en la de administración.
El archivo de diseño de Frontend vendor/magento/module-theme/view/frontend/layout/
default.xml lo define de la siguiente manera:
El archivo de plantilla que representa los mensajes es view/frontend/templates/messages.phtml en el módulo Magento_Theme. Al observar la clase Magento\Framework\View\Element\Messages, verá que el método _toHtml se bifurca en declaraciones if-else, dependiendo de si la plantilla está configurada o no. En caso de que la plantilla no esté configurada, _toHtml llama internamente al método _renderMessagesByType, que representa mensajes en formato HTML agrupados por tipo.
El archivo de diseño de administración view/adminhtml/layout/default.xml en el módulo Magento_AdminNotification lo define de la siguiente manera:
El archivo de plantilla que representa los mensajes es view/adminhtml/templates/system/messages.phtml en el módulo Magento_AdminNotification. Cuando observa la clase Magento\AdminNotification\Block\System\Messages, verá que su _toHtml está llamando al método principal _toHtml, donde el padre pertenece a la clase \Magento\Framework\View\Element\Template. Esto significa que la salida depende del archivo view/adminhtml/templates/system/messages.phtml en el módulo Magento_AdminNotification.
Session y Cookies
Las sesiones en Magento se ajustan a Magento\Framework\Session\SessionManagerInterface. En el archivo app/etc/di.xml, hay una preferencia de definición para la clase SessionManagerInterface que apunta al tipo de clase Magento\Framework\Session\Generic. La clase Session\Generic es solo una clase vacía que extiende la clase Magento\Framework\Session\SessionManager, que a su vez implementa la clase SessionManagerInterface.
Hay un objeto importante del que se crea una instancia en la instancia de SessionManager que se ajusta a \Magento\Framework\Session\Config\ConfigInterface. Al mirar el archivo app/etc/di.xml, podemos ver una preferencia para ConfigInterface que apunta a un tipo de clase Magento\Framework\Session\Config.
Para comprender completamente el comportamiento de la sesión en Magento, debemos estudiar el funcionamiento interno de las clases SessionManager y Session\Config.
Magento utiliza cookies para realizar un seguimiento de una sesión. Estas cookies tienen una vida útil predeterminada de 3600 segundos. Cuando se establece una sesión, se crea una cookie con el nombre de PHPSESSID en el navegador. El valor de la cookie es igual al nombre de la sesión. De forma predeterminada, las sesiones se almacenan en archivos en el directorio var/session de la instalación raíz de Magento.
Si observa estos archivos de sesión, verá que la información de la sesión se almacena en cadenas serializadas que se dividen en grupos como _session_validator_data, _session_hosts, default, customer_website_1 y checkout, como se muestra en la siguiente captura de pantalla:
Esta no es la lista finita de agrupaciones. Los módulos que implementan sus propios bits de manejo de sesiones pueden agregar sus propios grupos.
Podemos almacenar y recuperar información en una sesión simplemente usando expresiones como las siguientes:
Reseñas
Calificación Media
Calificación Detallada
Estrellas 5 |
|
0 |
Estrellas 4 |
|
0 |
Estrellas 3 |
|
0 |
Estrellas 2 |
|
0 |
Estrellas 1 |
|
0 |
Sé el primero en reseñar “Desarrolladores Backend en Magento 2” Cancelar la respuesta
Gratis
Aún no hay reseñas.