8 de junio de 2018.
Empiezo escribiendo este artículo con la fecha de hoy porque voy a explicar qué ha ocurrido con los dominios .es que los gestiona la entidad publica Red.es, del Ministerio de Energía, Turismo y Agenda Digital, y cómo podemos evitar en gran medida un desastre como el que han vivido hoy muchas webs y muchos usuarios con un correo con dominio .es. (Información sobre el incidente en este artículo)

¿Qué es lo que ha ocurrido? Sencillamente que la gestión de las zonas de dominios se les ha caído. Por ahora no se sabe mucho más de por qué ha sido, y las webs de red.es y dominios.es que serían las encargadas de informar, aún no muestran nada. Dominios.es a través de su Twitter ha informado escuetamente del problema:

Por otra parte, era de esperar, ya que la gestión de los dominios .es es mucho peor que la de un .info o un .com, por poner ejemplos.

Pero, ¿cómo podríamos evitar estos problemas, o por lo menos, paliarlos? Realmente hay muchas soluciones, por ejemplo, no depender sólo de un dominio .es únicamente. Personalmente suelo recomendar a un cliente cuando compra el dominio .es, que compre el homólogo .com y que redirija el .es al .com. Y que gestione el correo desde el dominio .com. ¿Por qué dar prioridad el .com? Pues porque la gestión de los .com recae sobre una organización más grande y fiable que la de .es. También está la idea de trabajar con varios dominios, y que el principal de todos ellos no sea un .es, sino un .net, .com, .info.

Pero aparte del problema que puede ocasionarnos el que una entidad de gestión de dominios se caiga o de problemas, podemos tener otros tipos de errores y contratiempos, por ejemplo, que nuestro servidor tenga que gestionar mucho contenido (archivos, imágenes) y servirlo internacionalmente. Entonces lo mejor es contar con un servicio CDN que sea el encargado de servir nuestros contenidos, descargando a los servidores web de ese trabajo.

Otro problema que podemos tener es un ataque de denegación de servicio por DNS. Si tenemos un problema como este, aparte de tener los servidores preparados para ello, y realizar las medidas consecuentes para paliarlo, nos vendría bien tener la web gestionado por distintos DNS, ya que el denegación de servicio se hace contra uno o varios servidores normalmente de la misma raíz de NS, por lo que si tenemos DNS en distintos países o distintos hostings, el ataque se verá disminuido.

Y estas son algunas de las reglas que solemos recomendar a los clientes para tener garantizado más del 90% de disponibilidad tanto de servicio web como de mail.

El 3 de junio saltaron las alarmas entre los clientes de PcComponentes: se estaban realizando compras fraudulentas con sus tarjetas. Por lo que se cuenta en esta noticia (ver noticia), parece ser que PcComponentes ha tenido un problema de seguridad y las cuentas de usuarios se han visto comprometidas, aunque más tarde la empresa ha querido desmentirlo. Lo que llama la atención es que se hayan visto implicados clientes de PcComponentes.

Este supuesto robo de información no debería haber supuesto un problema más allá de haber hecho público los datos de los usuarios, si no fuera porque al parecer, PcComponentes guardaba sus números de tarjetas en sus propias bases de datos, lo que ha llevado a los clientes a pensar que ha habido alguna filtración.

Llevamos años insistiendo en contra de guardar los datos bancarios de los usuarios a los clientes que nos piden guardar ellos mismos los números de tarjetas y de CCC con el objeto de hacer más cómoda la compra para sus clientes cuando éste repite. Y nuestra respuesta siempre ha sido la misma: hace falta tener una seguridad muy alta en los sistemas que custodian esos datos (no sólo implican una encriptación de datos, también una seguridad perimetral mayor, un técnico dedicado a los servidores, backups y la seguridad de la plataforma, etc), y esa seguridad es una inversión demasiado cara, por lo menos para un comercio electrónico medio, ya que hoy día no genera tanto margen de beneficio como para costear ese incremento en la seguridad. Un cliente no va dejar de comprar en un comercio electrónico simplemente porque tenga que meter su tarjeta cada vez, sobretodo si se le escribe una nota aclarando que es una medida de seguridad pasiva muy efectiva “¿Por qué no guardamos tu tarjeta bancaria? Porque en caso de hackeo, tus datos bancarios no se verán comprometidos”. Al contrario, si se le explica, el comprador se sentirá más seguro en un comercio electrónico que no guarda la tarjeta frente al que sí lo guarda.

Si al entrar en el detalle de cada cliente en el backend de Magento 1.9 os devuelve el mensaje:

error: error in [unknown object].fireEvent():

event name: address_country_changed error message:

cannot read property ‘show’ of undefined.

Lo que debéis hacer es ir a la administración de bases de datos que tengáis (PHPMyAdmin, Adminer, etc) la tabla de eav_attribute y buscar el elemento postcode. Lo editáis y cambiáis el valor del campo is_required de 0 a 1, ya que es un campo necesario para los envíos.

Para actualizar una plataforma Magento 1.X en producción, seguiremos los siguientes pasos:

  1. Descargaremos el archivo desde la página de Magento mediante wget, o nos los descargamos en local y subimos el archivo por FTP o SCP.
  2. Descomprimimos el archivo
    tar -zxvf magento-1.9.X.tar.gz
    o
    unzip magento-1.9.X.zip,
    donde X es la versión que nos hemos descargado
  3. Como se habrá descomprimido en un directorio llamado magento, entramos en él:
    cd magento
  4. Y copiamos todos los archivos descomprimidos sobre los actuales, machacando los anteriores:
    cp -rf * ../
  5. Salimos del directorio magento y lo borramos:
    cd ..
    rm -rf magento
  6. Y nos cercioramos que los permisos y propietarios de directorios y archivos son los correctos:
    find -type f -name ‘*.*’ -exec chmod 644 {} \;
    find -type d -exec chmod 755 {} \;
    chown -R username:groupname *, donde username será www-data o el usuario propietario en cada caso, y lo mismo para groupname

Al crear una regla o promoción de carrito en el que queráis hacer un descuento a un grupo de clientes, podéis encontraros con el problema de que el cliente se loga, pero el carrito sigue mostrando los precios sin el descuento por ser de un grupo determinado con promoción y descuento. Esto es debido a que habéis marcado a Sí la opción “Habilitar asignación automática al grupo de clientes”. Debéis marcarla a No si vais a tener varios grupos de clientes con descuentos y promociones según su grupo, o en la página de checkout se asignará al cliente al grupo General, aunque esté logado correctamente.

La opción “Habilitar asignación automática al grupo de clientes” está en Sistema->Configuración->Clientes->Configuración de cliente.

A veces sucede que cuando se instala un plugin en MAgento, o lo desinstalamos, o actualizamos la plataforma de alguna forma, la parte del front se ve perfectamente y funciona todo, pero al intentar entrar en el backend, no podemos acceder al mismo.

Nos ponemos un poco nerviosos, porque aunque no es la pantalla de mantenimiento, no podemos acceder al backend de nuestro comercio electrónico. Si después de hacer lo que te recomiendan en foros y webs, que suele ser “borrar el contenido del directorio de var/cache de Magento”, “borrar el contenido del directorio var/sessions de Magento” y ver que sigue igual, y después de poner el código correspondiente al modo desarrollador:

[crayon-5b4ec58bb1106779299770/]

y comprobar que seguimos sin ver nada, ni en los archivos de log propios de Apache ni en los de var/log y var/reports de Magento, y tampoco has conseguido ver qué ocurre al desactivar la compilación, es que ha llegado el momento de utilizar este código, que devolverá qué clase es la que da el error, y por lo tanto, nos dará pistas de qué está ocurriendo (por ejemplo, que no se ha instalado / desintalado el plugin correctamente, o que la instalación ha encontrado algún problema a la hora de volcar todos los archivos de la actualización, y alguno no lo ha hecho, o se ha corrompido algún archivo, etc).

[crayon-5b4ec58bb110f514421181/]

Esta minientrada servirá para ayudaros a resolver un problema como el que tuvimos recientemente con una instalación de un módulo en un Magento. A pesar de seguir las instrucciones al pie de la letra al instalar (volcar carpetas y archivos, limpiar cachés, desactivarlas, activarlas…), nos daba un error 500 al activarlo, así que dimos estos pasos para encontrar el error y solucionarlo fácilmente:

Primero nos metimos por ssh al servidor, y fuimos al directorio de logs del apache (distinto del log de Magento). Allí hicimos un tail -f al archivo de error, y nos devolvió el error:

PHP Fatal error:  Class ‘empresa_modulo_Model_Mysql4_Setup’ not found in includes/src/Mage_Core_Model_Resource_Setup.php on line 234

Como no podíamos tener la web con un error 500 mientras realizábamos la búsqueda, borramos el archivo XML que está en app/etc/modules que activa al módulo, y empezamos a investigar. Como las soluciones que proponían en Internet no nos surtían efecto, decidimos borrar los archivos antiguos (más de 4 horas) de sesiones de var/sessions/, activamos de nuevo el plugin, y todo funcionó a la primera.

Espero que os sirva de ayuda.

Cuando, después de una actualización vía código de los productos y/o sus categorías y atributos, necesitamos reindexar de nuevo las tablas implicadas en el proceso, podemos hacer:
[crayon-5b4ec58bb12bf218458708/]
para reindexar todas las tablas, o bien, si sólo necesitamos reindexar un conjunto determinado de tablas, podemos hacer:
[crayon-5b4ec58bb12c6818100887/]