¡Hola de nuevo! Estoy trabajando últimamente mucho con WordPress, así que he pensado que sería bueno ponerse al día indagando un poco más en cómo está hecho WordPress y cómo funcionan los llamados themes. Los themes son diseños que se pueden instalar en tu WordPress y lo hacen más atractivo a la vista, mejorando cosas de UI/UX que llaman los expertos. Es decir, mejoran el diseño, la interfaz de usuario, la usabilidad, la accesibilidad.. Estas materias en el desarrollo de software son principales para todos los que trabajamos con software con interfaz de usuario. Por esto que en la mayoría de estudios relacionados hemos tenido asignaturas destinadas única y exclusivamente a esta materia (Diseño web, Programación en Internet, Interfaces, Gráficos por computador..), algunas más hueso y otras más de sentido común.
Una de las bondades que tienen Magento es su flexibilidad. En este post vamos a ver el tema de los atributos de producto, cual es su scope o alcance. En general, esto se facilita mucho con su uso interno del modelo de datos EAV. Gracias a EAV que podemos gestionar muchos valores de atributos de cada elemento sin tener que modificar la base de datos. Es decir, no tenemos que hacer una columna nueva para cada atributo nuevo. Sino que se da de alta el atributo en una tabla, y en otra se guardan los valores de los atributos sin haber hecho absolutamente ninguna modificación en la estructura de la base de datos.
Disponemos de tres niveles de configuración normalmente, aunque realmente hay cuatro, para configurar muchas de las cosas que hay dentro de un Magento. Tenemos el nivel de website, de store y de store view. Traducidos son sitio web, tienda, y vista de tienda; y además tenemos el nivel global. Por ejemplo, si vamos a las configuraciones de tiendas podemos tener varios nombres de dominio (uno por website), cada uno con sus configuraciones, plantillas distintas, productos distintos, incluso clientes distintos asignados a cada website o compartidos entre todos los websites. Dentro de un website podemos tener varias tiendas o stores. Y de cada tienda podemos tener varias vistas de tienda, incluso pudiendo cambiar las plantillas o muchas de sus configuraciones de productos, categorías, etc..
El caso de los productos
Volviendo a los productos, primero tenemos que los podemos asignar a cada website. Es decir, un producto puede publicarse en uno de los websites mientras que en otro no. Si vamos al listado de productos nos encontramos en un Magento 1.9 arriba con un desplegable como el de la imagen de al lado, donde podemos configurar los productos a nivel de store view.
Los productos se trabajan al más bajo nivel, al de store view. Esto es así porque el nivel de store view se suele usar para traducir la web. Es decir, publicamos un producto en un website, y configuramos a nivel de vista de tienda cómo lo va a ver el usuario. Si tenemos una vista de tienda por cada idioma, podremos configurar su nombre, descripción, características, etc.. traduciéndolas para cada idioma.
El nivel de los atributos de producto
Podemos dar de alta y configurar nuevos atributos, en la zona de gestión de atributos. Un listado de atributos de ejemplo podría ser tal que así:
Si el valor del atributo es el mismo en todas las tiendas o vistas de tienda, entonces debería de ser global. Si el valor es distinto, traducible para cada store view, debe de tener el nivel de store view. Es importante saber que todas las etiquetas que se muestran siempre se pueden traducir para cada store view, independientemente de los valores que tome dichos atributos. Es decir, no confundamos las etiquetas que podemos traducirlas con los valores que también podemos traducirlos, no te lleve a confusión.
El atributo de producto ‘status’ es de sistema
Todos los atributos del listado anterior no son de sistema, con lo que no tienen limitación para configurarlos como queramos. Pero los de sistema sí que están limitados. Para este post vamos a trabajar con un atributo que ya viene configurado en Magento que es el estado (status). El estado puede estar habilitado o deshabilitado, y viene configurado a nivel de sitio web. Este atributo puede configurarse para que esté a nivel de website o nivel global. Si lo tenemos a nivel de website entonces podremos habilitar o deshabilitar un producto independientemente en cada website de nuestro Magento.
Esta flexibilidad está bien, pero sólo en ciertos casos. Si tenemos varios websites, de cada uno por lo menos una store, y dentro de cada store podemos tener varias store views para traducir las tiendas.. se puede reducir la cantidad de configuraciones si ponemos el nivel adecuado para cada atributo. Volviendo al caso del atributo status, si me interesa que cuando deshabilite un producto lo haga para todos los websites, entonces debemos de tenerlo a nivel global. De lo contrario, si tenemos 3 sitios web, para estar seguros de que deshabilitamos o habilitamos correctamente el productos en todos los websites deberemos de entrar en la configuración de producto varias veces y comprobarlo.
Así que vamos a ponerlo a nivel global y asegurarnos de que no quedan valores personalizados a nivel de website. Y en tal caso los borramos. Así evitaremos esta excesiva navegación por las fichas de producto. Y así nos aseguramos de que un producto deshabilitado, lo está realmente en todos los websites.
Finalmente, pasando a global el atributo status
Entramos en la configuración del atributo y lo modificamos para que sea global:
Sólo nos falta entrar a la base de datos y, en este caso, borrar todas las configuraciones del atributo a nivel de website que se hayan hecho para que sólo se aplique la configuración global en cada producto. Si se nos quedara en la base de datos algún valor personalizado sin borrar, Magento cogería dicho valor personalizado, en caso de no encontrar valores personalizados de nivel más bajo entonces cogería el valor global.
Encontrando el identificador del atributo
Para esto no tenemos más que entrar a la base de datos e ir a la tabla eav_attribute. Aquí tenemos definidos los atributos que gestionamos en el panel de control. De forma que, tenemos dos columnas con las que identificamos el atributo status: la columna attribute_code, y la columna attribute_id. Aquí buscamos el código que le hemos puesto al atributo, en este caso ‘status’, que no lo hemos creado nosotros porque es de sistema y ya viene configurado.
Ya hemos encontrado el identificador del atributo, que es el 96. Ahora ya podemos ir a revisar los valores que ha ido tomando el atributo para las distintas vistas de tienda. Para esto vamos a la tabla catalog_product_entity_int que es donde se guardan los ‘valores enteros de los atributos de entidades de productos’ como su nombre indica en inglés.
Como podemos ver en la imagen, el atributo 96 está cogiendo los valores 1, 2.. para el status el valor 1 es de producto habilitado, el 2 es deshabilitado. Según vemos en la imagen y haciendo un par de consultas podemos ver que la store_id es cero siempre en mi caso. A saber, la store_id cero es el valor del atributo global, es el que coge Magento en caso de encontrar ninguno personalizado. Si tenemos guardados valores distintos para las vistas de tienda, entonces habrían valores con store_id distintos, donde cada store_id corresponde con el identificador de la store.
Cómo listar los stores de una tienda lo cité en el post este, en donde se listan primero los store_id para luego ir recorriendo los productos y asignándolos a todas las stores. Podemos coger aquel script y listar los store_id y así poder editar o simplemente borrar las configuraciones de algunas de las stores.
Borrando valores de atributo personalizados
En este caso, si quisiéramos borrar todas los valores de status personalizados en cada store view bastaría con ejecutar la consulta siguiente y vemos si hay dichos valores personalizados:
SELECT * FROM magento_maxmovil.catalog_product_entity_int
WHERE attribute_id = 96 AND store_id != 0;
Si los hay simplemente modificamos la anterior consulta para borrarlos:
DELETE FROM magento_maxmovil.catalog_product_entity_int
WHERE attribute_id = 96 AND store_id != 0;
Con esto ya nos aseguramos que no vaya a haber problema y hemos pasado el atributo status a scope global. Esto mismo se puede hacer para cualquier otro atributo.
Con esto queda terminado 🙂 otro día más 😉 Un saludo!
Hoy traigo un pequeño HOWTO para limitar en el tiempo la cantidad de tareas a realizar. Necesitaba hacer un pequeño script para hacer 200 000 pequeñas tareas. El servicio sobre el que actúan éstas tareas está limitado a 12 por segundo, con lo que estábamos obligados a hacer algo para limitarlo en el tiempo y no ser bloqueados.
Este script puede servir para enviar una cola de emails transaccionales, para hacer un mailing a tus suscriptores sin pasarte de la cuota que tengas contratada con tu proveedor de hosting, también es útil para limitar la cantidad de veces por segundo que consumes de una API de algún servicio.
Las API REST son cada vez más habituales. Con HTTP tenemos las instrucciones básicas de listar, editar, crear o borrar. Es cada vez más habitual encontrarnos con estos servicios, o los antiguos Webservices o SOAP.. Habrá APIs con las que también si te pasas de tareas por segundo también te cierran para que no colapses el sistema y puedan dar servicio al resto. Así que pienso que si estás aquí te puede ser útil..
En una reunión en un café con unos colegas de trabajo estábamos hablando de CMSs, citando Magento, llegaron algunas preguntas como: ¿qué tiene Magento de especial? Pues una de las peculiaridades que le dan una gran potencia a Magento es la gestión de tareas programadas.
Magento nos obliga a disponer de un servidor en el que podamos configurar un programa, en este caso el cron de Magento, para que se ejecute cada x tiempo. Yo lo estoy instalando para que se ejecute a cada minuto. Este programa interno de Magento se llama cron igual que en Linux tenemos también el cron. Es el programador de tareas, no es el Crom de Conan el bárbaro que me comentaba un compañero de trabajo xDD
En las últimas versiones se ha pasado incluso el envío de emails transaccionales como tarea programada. Es decir, los emails transaccionales se envían a una cola de envío de emails y en la siguiente ejecución del cron se envían los que haya encolados. Estas tareas llevan un seguimiento, registro, etc.. A cada ejecución del cron de Magento le llamamos los desarrolladores heart beat en inglés, que significa el latir del corazón. Es decir, que Magento tiene un corazón, que late, y en cada latido puede que haga muchas cosas.. qué freak que suena esto, pero así es..
Hola de nuevo. Esta semana he seguido avanzando sobre todo esto de Magento. Creando unos trabajos de cron, después de haber probado las tareas cron a ejecutar mediante scripts externos a Magento. Me he encontrado con que las fechas no me funcionaban como yo esperaba dando malos resultados.
Probando probando, llegué a la conclusión de que tratando las fechas mediante cadenas de caracteres podía aplicarles las modificaciones que necesitaba.
La primera tarea que debemos abordar a la hora de comenzar a programar dentro de Magento es la creación de un módulo. Es muy práctico y sencillo atacar a los componentes de Magento desde simples scripts que importan el autocargador y así poder trabajar con los datos. Pero tarde o temprano necesitaremos integrarlo todo dentro de Magento y así quedará más limpio. Podremos modificar el comportamiento de Magento desde dentro, aumentando sus funcionalidades si es que lo necesitamos.
PHP 5.5 dejó de tener soporte en enero del 2016, las actualizaciones de seguridad acaban de dejarse en junio de 2016. Así que a partir de ahora julio del 2016 deberíamos mínimo de tener PHP 5.6 en cualquier servidor para mantenernos al día por lo menos en los parches de seguridad.
Todavía en Ubuntu 14.04 LTS tendrá soporte hasta el próximo 2019. Desde su lanzamiento en 2014, serán 5 años de Long Time Support (LTS). Los ciclos de vida de las librerías incluídas son otra cosa. Aunque se puede pensar que dado el fin del soporte de seguridad para PHP 5.5 se debería de traer ya de casa PHP 5.6 en Ubuntu 14.04. Pero sería forzar a los usuarios a migrar sus aplicaciones a la nueva versión y si hubiera alguna incompatibilidad sería forzar a compatilibilizarlo, algo que puede ser bastante complejo dependiendo de cada aplicación.
¡Hola de nuevo! Cada loco con su tema, así que yo sigo escudriñando cada día más las entrañas de Magento. Mientras voy compartiendo mis pequeños pinitos en el tema. Ahora traigo un pequeño HOWTO, un pequeño tutorial para recorrer los websites, stores y store views que tengamos en nuestro Magento.
Dentro de un Magento podemos tener varios sitios web, cada uno con su nombre de dominio. A su vez, dentro de cada website podemos tener varias tiendas, con su catálogo raíz de productos. Y a su vez también podemos tener dentro de cada tienda sus vistas de tienda, que normalmente se usan para traducir dichas tiendas.
Es decir, dentro de un mismo Magento, con un mismo panel de control, podemos tener varios dominios con distintos productos, distintas plantillas, distintas configuraciones, etcétera. Es algo que nunca había visto en ningún CMS y llevarlo hasta el extremo de que cada website, store o store view puede tener muchas de sus configuraciones independientes. Lo que quiero decir es que Magento es muy flexible lo mires por donde lo mires. Poder tener todos los productos, las ventas, centralizado en un mismo panel de control es muy práctico.
De gracias recibisteis, dad de gracia.. Compartir es vivir dicen otros.. Es habitual en el mundo del desarrollo del software que se compartan los conocimientos. Los pinitos personales de cada uno en el día a día. Esas cosas que tanto nos han costado alcanzar, tras búsquedas y búsquedas leyendo a compañeros del desarrollo y al final reuniendo toda la información acabas construyendo la solución que necesitas.
No os comparto código del trabajo, ya que seguro que no es tan interesante como este ejemplo general de aquí abajo. Para que construyas el script que necesitas 😉
Creo que nunca dejaré de aprender los entresijo de Magento. Ahora estoy recorriendo los pedidos para obtener informes. Esto está probado sobre un Magento 1.9, no debería de haber muchas diferencias con otras versiones.
Ya tenemos entre nostros Ubuntu 16.04 LTS, la versión con soporte para mucho tiempo de Ubuntu más nueva hasta la fecha. Me instalé en los ordenadores de escritorio la actualización que me los pasó de la versión 14.04 LTS a la 16.04 LTS sin ningún problema.
Ahora disfruto de todas las novedades y mejoras que trae Ubuntu 16. El problema me ha llegado cuando he querido actualizar un servidor de Ubuntu 14 al 16. Resulta que en las versiones de escritorio de Ubuntu tenemos una sencilla interfaz para actualizar el sistema, mientras que en los servidores no. En las versiones de escritorio nos sale prácticamente todos los días las nuevas actualizaciones que tenemos disponibles, se pueden instalar automáticamente o seguir las instrucciones. Cuando ha salido la nueva versión de Ubuntuo 16.04 LTS nos salió junto con las actualizaciones la actualización a Ubuntu 16.04, simplemente seguimos las instrucciones y a correr.
Este estupendo CMS orientado a la venta online de productos hace las delicias de los vendedores, de igual modo de los maquetadores, y cómo no, también de los programadores.
Como analista programador llevaba ya un tiempo queriendo meterle mano a las entrañas de Magento. Así que poco a poco, he ido cogiendo los manuales para el usuario, luego el del diseñador, y ahora tengo entre manos el del programador. Ahora según van surgiendo las necesidades voy haciendo incursiones cada vez más a fondo en el código fuente de esta humongous web application.
La verdad es que lo estoy disfrutando porque Magento está desarrollado con una buena estructura y sobre un gran framework de desarrollo PHP, el Zend Framework. Incorporando técnicas de programación que le dan una gran flexibilidad sin añadir demasiada complejidad.
Este es otro pequeño how to para hacer una tarea rutinaria. Simplemente, como indica el título de la entrada, se hace lo que dice, en este caso mediante PHP. Esta tarea se puede programar en línea de comandos para ejecutarse todos los días. Es algo habitualmente necesario, y ya que PHP es un lenguaje de scripting muy sencillo y a la par potente, vamos a ver cómo hacer esto sin complejos sistemas intermedios.
Para este manual se usa Linux, y se ha probado sobre Ubuntu 14.
