Aquí estoy de nuevo dejando mi granito de arena en todo esto de la informática. Hoy traigo un howto para la optimización de servidores web. Simplemente, son unas propuestas de configuraciones totalmente estándar y disponibles en las documentaciones oficiales. Pero que mejoran mucho el rendimiento de aplicaciones web, hechas en lenguajes como HTML, CSS, Javascript, PHP, Java, Python, SQL, DQL.. Este post es para optimizar aplicaciones web del tipo WordPress, Prestashop, Magento, Drupal, Symfony.. etcétera. Es una visión general de cómo funcionan las cosas a bajo nivel. Digo a bajo nivel, porque están muy de moda las arquitecturas server-less, o los servidores auto-administrados, que también necesitan su optimización. Pero aquí nos remangaremos la camisa, y nos embarraremos hasta el cuello mientras que vamos investigando, aprendiendo y aplicando, para cada proyecto en concreto. Este es un post para los que nos gusta trabajar los servidores, para los que nos gusta ponernos manos a la obra, para experimentar nosotros mismos con los proyectos, rascando cada milisegundo para conseguir que todo vaya lo más rápido posible..
Magento
Ahora es mucho más sencillo arrancar un nuevo módulo para Magento 2. Aquí que dejo unos sencillos pasos para crear un módulo propio. Luego es cuestión de ir añadiendo las configuraciones que quieras, menús en backend, zonas en frontend, plantillas, controladores, tareas programadas, y un largo etcétera.. La idea es la misma que en muchos otros CMS, al modo de Vendor/Modulo que vamos a seguir estructurando los códigos.
Aquí estoy de nuevo compartiendo un truco sobre Magento 1. Magento 1 es un proyecto Open Source, con lo que navegando por el código fuente, o preguntando por foros por Internet que podemos llegar a encontrar cómo hacer esto. Pero aquí que lo dejo porque me ha costado un poco encontrar cómo hacerlo, y ha sido útil como técnica de mejora de proyectos en Magento 1. Digo que me ha sido útil ya que a veces, me he encontrado los proyectos sin activar la caché. Esto hacía que los proyectos corrieran mucho más lento, ya que Magento en general, sin la caché activada, es realmente lento.
Estar participando en grandes proyectos con Magento 2 es todo un privilegio, un honor. Con esto, que últimamente estoy investigando sobre cómo programar en Magento 2. Así que antes de entrar al tajo con el desarrollo de los módulos, programación de la plantilla (frontend), o programación para el panel de control (backend).. podemos empezar a juguetear con scripts externos a Magento que bootstrapean toda la aplicación para tenerlo todo disponible. Me explico, el hacer scripts externos a Magento es la mejor manera de comenzar a probar los fragmentos de código que vamos a necesitar después en módulos, frontend y/o backend. Es decir, si vamos a necesitar una sección, que te liste ciertos tipos de productos/pedidos/categorías/usuarios.. lo mejor es probar estos listados en otra parte. Mejor probamos en estos scripts externos, para luego incluirlos con toda su cáscara de frontend o backend, según proceda.
¡Hola de nuevo! Últimamente estoy jugueteando mucho con Magento 2, poniéndome al día con todas las nuevas mejoras que trae. Cierto es que la gente por los foros habla de muchos problemas con las versiones 2.0, 2.1, 2.2.. Pero pienso que es normal, ya que se ha hecho un remake total de todo el código fuente de Magento. Magento es un CMS para eCommerce enorme, tiene una gran cantidad de funcionalidades ya incorporadas de casa. Por otro lado, necesitas de un servidor potente para hacerlo correr. Pero tienes un punto de partida muy muy bueno, comparado por ejemplo con Prestashop, Sylius o WordPress con Woocommerce. Quizá incluso te puedes evitar un desarrollo a medida o la instalación de muchos módulos con sus correspondientes personalizaciones si es que Magento 2 ya dispone de las funcionalidades que necesitas.
¡Hola de nuevo! Como siempre que puedo, trabajo con Open Source, pues aquí que sigo con la filosofía del Open Source, compartiendo algo más de código fuente Open Source. La verdad es que nunca me planteo alternativas que no sean Open Source, con lo que tengo incluso la obligación de compartir códigos Open Source, ya que tanto me beneficio de los proyectos Open Source, en lo laboral y en lo personal, valga la redundancia.. Se nota que me gusta el Open Source ¿verdad? xDDD
Continuando con el post anterior sobre los índices de Magento, dejo aquí unas pocas explicaciones por si a alguien le sirve de cómo funcionan las tablas de reindex por dentro. El post anterior introducía el concepto de los índices de Magento, qué son, para qué sirven. Vamos a ver un poco más con unos casos de uso.
Magento es un gran CMS para montar tiendas online. Está muy desarrollado teniendo en cuenta el SEO, el marketing, para tener muchos dominios con la misma web, muchas configuraciones de impuestos, de precios distintintos por web, distintas plantillas para cada sitio web.. todo desde un mismo panel de control. Es tan flexible desde el mismo panel de control, que ha llegado a extremos de tal forma de que necesita todo tipo de cacheados, tablas temporales donde guardar indexada la información, así como también Varnish y Redis. Todo esto junto es una combinación explosiva y todo un reto hacerlo funcionar todo. Así que en este post vengo a hacer una review del funcionamiento de estos índices de datos.
Aquí estoy de nuevo compartiendo otro CODE-KATA, ahora para hacer una tarea muy interesante conectando dos sistemas informáticos. Es decir, tenemos un Magento 1 en algún lugar, y vamos a permitir conectarnos desde otra plataforma en PHP para la creación de pedidos de forma remota. Lo primero que necesitamos tener es la información del pedido por completo. Necesitamos saber los datos del cliente, direcciones de envío y facturación, en este caso el correo electrónico del cliente registrado en Magento, y de los productos necesitamos el SKU y la cantidad que queremos pedir.
Otra vez, de nuevo, me repito más que el ajo xDD vengo a traer otro CODE-KATA o HOWTO. Esta vez sobre la API Soap de Magento. Se trata de un pequeño script para ver la información de un pedido. El punto de partida es que tenemos ya configurada la API Soap de Magento, con un usuario de la API, con los suficientes privilegios para hacer peticiones de información sobre los pedidos. Entonces conectamos a dicho proyecto, a su endpoint, con las credenciales de acceso, y obtenemos los datos del pedido.
He tenido problemas para poner un popup de Mailchimp en esta web. Así que aquí estoy compartiendo la solución. He tratado de usar la utilidad que viene en el panel de control de Mailchimp. Pero todo apunta a que tengo algún conflicto entre los Javascripts de Mailchimp, los Javascripts de mi plantilla, algún plugin de cacheado o del minificado del código fuente. En fin, que no funcionaba y he terminado antes haciendo el popup artesanal que se puede ver en la barra lateral derecha de la web. Si has tenido el mismo problema, aquí dejo mi solución, que espero que funcione en el 100% de las webs. Simplemente necesitas tener instalado en la web jQuery, el resto viene todo en el código de abajo. Se puede copiar y pegar en el widget de WordPress donde lo quieras y adaptarlo para tu web.
Estos últimos días me han pedido sacar informes de un Magento. Ha sido muy interesante porque no me esperaba tener esta información en el CMS, pero sí, ahí estaba. Resulta que Magento viene con un atributo de coste de los productos, que es de sistema. Dicho atributo de producto tiene el código cost. Además, en la información que se guarda en cada pedido tenemos el precio original, este coste del sistema en el momento de la venta, y más información. Con esto podremos saber el margen de beneficio que hubo en el momento de la venta. Es importante notar que supongo que ya usas el atributo de coste del sistema, o que tienes un ERP enganchado a Magento que te lo está manteniendo actualizado con cada pedido de compra.