Estas semanas atrás hemos tenido algunos problemas en algunos WordPress. Recurrentemente, las páginas web daban resultados en blanco. Era raro pues no teníamos registros de bloqueo. No había saltado el cortafuegos por poner mal las contraseñas. De repente, no teníamos servicio, otra web.. ahora el servicio de correo.. Un compañero de trabajo, luego otro.. Con cuentagotas iban reportando las incidencias. Tirando del hilo, tirando del hilo.. llegamos a la conclusión de que ¡todo en el servidor estaba fallando! ¡no puede ser!
Se trata de un servidor administrado en el que no tenemos que hacer ninguna gestión. El sistema operativo se mantiene actualizado automáticamente por la empresa que nos aloja. Siempre ha ido todo perfecto. El cambio siempre ha sido a mejor de todas las webs aquí alojadas.. Visto esto, y sabiendo que un WordPress sin actualizar puede ser origen de una ingente cantidad de problemas, me pongo manos a la obra. Reviso las actualizaciones de toooodos los WordPress que hay en este servidor. Uno a uno, actualizándolos todos manualmente. Me encontré con algunas actualizaciones que no se habían hecho, incluso teníamos un WordPress a medio actualizar que se había quedado enganchado. Varios proyectos heredados junto con otros nuevos. En fin, tareas rutinarias que hacer para poner todo al día..
Ahora mismo ya está todo arreglado y funcionando perfectamente. Cierto es que hemos tenido algunos problemas de rendimiento a nivel de sistema operativo. Pero por otro lado teníamos algunos WordPress que actualizar y poner al día. Así que, ahora que ya volvió el agua al río, y se arrojó luz sobre el origen de los problemas.. aquí estoy con algo de material nuevo.
Las nubes por definición son sistemas informáticos que crecen o decrecen según la necesidad. Son conjuntos de servidores/servicios que se adaptan a la demanda. Con todo esto, llegamos a una de las cosas más interesantes de AWS, el auto-escalado o la tolerancia a fallos, además de la personalización de los servidores. Podemos controlar la carga de los servidores que haya. Además automatizar el arranque y parada a ciertas horas de algunos de los servidores. O podemos duplicar los sistemas para evitar los ‘single point of failure como una casa’.
En OpsWorks tenemos herramientas muy interesantes relacionadas con esto. Algo rústicas, quizá clásicas dirían algunos. Pero gracias a ello, sin límites en la flexibilidad para configurar. Y si lo llevamos al extremo, este mismo sistema nos puede servir para automatizar la creación de nuestros servidores con herramientas como Chef y Kitchen. Todo esto y mucho más es lo que se puede hacer con el clásico OpsWorks.
Primero tendremos que ver qué son las AMIs. Cómo crear una manualmente o automáticamente. Y finalmente veremos cómo se usan, para hacernos una buena idea de qué podemos hacer en OpsWorks, y si es o no lo que necesitamos. Quizá es interesante ir a Docker con el EC2 Container Service o a CloudFormation, pero esto son otros temas..
No voy a entrar al detalle de cómo hacer cada cosa, no terminaría nunca. Así que si buscas una guía general para enfrentar después cada detalle poco a poco, este es tu post.
Ya puedes tener la estrategia de marketing mejor del mundo, la mejor campaña publicitaria, los mejores anuncios. Unas publicaciones excelentes en blogs, una gran inversión en SEM, o un SEO de contenidos inmejorable. Que si la infraestructura informática subyacente no acompaña de poco servirá. Aquí es donde entra el estar o no en la nube. Y nunca mejor dicho, poner tu aplicación web por las nubes.
¡Hola de nuevo! Continuando con el post anterior sobre el desarrollo de temas para WordPress. Inevitablemente, ya sea más tarde o más temprano, llegaremos a querer desligarnos totalmente de modificar los temas de otros. Todos hemos empezado haciendo pequeños arreglos con el editor que tiene WordPress. Si has seguido el post anterior sobre cómo hacer un theme hijo de otro te habrás quedado con ganas de más, así que continuándolo vamos a crear uno básico 100% tuyo para lo que necesites.
Ahora bien, lo normal es que si estás aquí alguna vez hayas jugueteado con temas de WordPress de otros, modificándolos y llegando a un punto en el que no puedes actualizarlo porque perderías las modificaciones. Por otro lado si haces un tema hijo siempre vas a depender del padre, y también puede que haya actualizaciones del padre que rompan tu diseño. Así que la forma más profesional de solucionar esto es hacer tu propio tema, 100% tuyo, y totalmente desligado de cualquier otro.
¡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.
