Estás utilizando mal Contact Form 7 … y lo sabes

Aunque el plugin Contact Form 7 es, con enorme diferencia, el plugin de formularios de contacto para WordPress más utilizado, la mayoría de la gente que lo usa no aprovecha todo su potencial, y de hecho me encuentro en muchas ocasiones que hay usuarios que ni siquiera saben utilizarlo medianamente bien.

Bien es cierto que no es un dechado de usabilidad y simplicidad, pues su interfaz espartana, en modo HTML, no ayuda a que los usuarios más noveles se enamoren del plugin, y mucho menos cuando ven que hay que usar shortcodes para insertar formularios en sus páginas, pero algo tendrá para ser el rey ¿no?

Yo apuntaría 3 motivos:

  1. Que WordPress – por algún extraño motivo que no alcanzo a descubrir – no tiene ninguna funcionalidad por defecto para crear formularios de contacto, así que te toca instalar un plugin para esto sí o sí.
  2. Que Contact Form 7 ofrece gratis, bien directamente o mediante ampliaciones, todas las características avanzadas que otros plugins de formularios de contacto solo ofrecen de pago.
  3. Que Contact Form 7 es enormemente ampliable y configurable, precisamente por su sencillez.

Y mira que he escrito en el blog sobre Contact Form 7, pero nunca había explicado cómo crear formularios, ni cómo configurarlo, los básicos vaya.

¡Reto superado!

Esto se acabó, porque hoy te traigo un vídeo tutorial de más de 25 minutos en el que explico paso a paso desde la instalación de Contact Form 7, cómo crear formularios personalizados avanzados, cómo solucionar errores y hasta cómo ampliarlo.

Así que no te pierdas esta guía en vídeo, y luego ya me cuentas si te ha servido, y si a partir de hoy empezarás a aprovechar bien Contact Form 7…

La entrada Estás utilizando mal Contact Form 7 … y lo sabes la publicó primero Fernando Tellado en Ayuda WordPress. No copies contenido, no dice nada bueno de ti a tus lectores.

ADSLZone recomienda encarecidamente no usar WooCommerce – ¿El motivo? te sorprenderá

Hay veces que cuesta no enfadarse cuando uno lee titulares que o bien los provocan el desconocimiento, la desinformación, falta de comprensión lectora, mala leche o qué.

El artículo de marras

Este es el caso del artículo del blog ADSLZone cuyo titular dice: «Consiguen robar tu tarjeta al visitar una web con un simple icono»

Bueno, como se explica realmente en la fuente no es algo tan sencillo, y quise explicarme en un tuit, pero no es el medio, así que sigamos.

El artículo empieza diciendo que:

…una tienda que usaba un plugin de WordPress llamado WooCommerce estaba infectado con un script de Magecart para robar tarjetas

Luego, tras explicar muy resumidamente la información del artículo original sobre la técnica de Web Skimming utilizada  –  esta sí realmente detallada y técnica –, el autor del artículo en ADSLZone llega a la siguiente conclusión:

Esta no es la primera vez que un plugin malicioso de WordPress ha estado involucrado en este tipo de ataques. Hace unos meses, se descubrió también un bug en WooCommerce que permitía a los atacantes ejecutar cargas XSS para crear cuentas con permisos de administrador en los dominios vulnerables. Por tanto, os recomendamos encarecidamente que no utilicéis ese plugin.

La fuente original

Te aseguro que he leído 3 veces entero el artículo técnico original y EN NINGUNA PARTE se alude a que la inyección de código sea debida a WooCommerce, ni se dice que WooCommerce sea un «plugin malicioso», y por supuesto, no se recomienda no utilizar el plugin que impulsa la mayoría de las tiendas online en el mundo.

Solo indican, en el artículo original, que encontraron el script malicioso inyectado en los datos EXIF de un favicon, que sí, mediante sistemas de ofuscación y envío de datos privados de los usuarios de «esa» tienda online desde una carpeta en la que se habían inyectado varios archivos, desde el favicon hasta un PHP, todos con la oscura intención de robar datos, por descontado.

Y solo se alude a que la web comprometida – sin especificar el motivo – está creada con WooCommerce, el software de creación de tiendas online más extendido.

Cualquier usuario recién aterrizado en WordPress sabe que WordPress es seguro, y que WooCommerce es seguro, si se cumplen unos básicos, que por supuesto afectan a cualquier software:

  1. Software base actualizado: WordPress en este caso.
  2. Software adicional actualizado: WooCommerce en este caso.
  3. Medidas básicas de seguridad: Seguridad en las contraseñas, seguridad en el sistema de archivos, un hosting seguro.

Las «conclusiones»

Y, ciertamente, no sabemos, porque no se explica siquiera en el artículo original, el origen de la «infección», así que me parece como poco aventurada la declaración/conclusión final del autor del artículo resumen de ADSLZone de que «… un plugin malicioso de WordPress» y de que «… os recomendamos encarecidamente que no utilicéis ese plugin».

Bueno, que no merece la pena ni seguir.

Solo espero, es más me ofrezco, a que cuando un bloguero quiera publicar algo sobre WordPress, se informe correctamente, consulte a fuentes que sepan de WordPress, pero sobre todo espero que no se inventen titulares donde no los hay, ni suelten afirmaciones no extraídas de ninguna fuente, sino de algún malentendido.

Y, ya puestos, que no convierta sus opiniones personales en recomendación editorial, poniendo en plural sus conclusiones, pues supongo que no todo ADSLZone firmaría eso de que «… os recomendamos encarecidamente que no utilicéis ese plugin».

Conozco a mucha y buena gente de ADSLZone y no solo no son anti-WordPress, sino que ADSLZone está creado con WordPress, así que no creo que la opinión del autor de ese artículo represente a todo ADSLZone, ni siquiera al equipo de redacción.

Pero ese tipo de afirmaciones, mira, hasta las entiendo cuando hables de marcas que ganan millones escamoteando prestaciones a los usuarios, pero si hablas de WordPress, un software gratuito y de código abierto, comprometido con la filosofía GPL, que mantienen altruistamente miles de usuarios, esperaría al menos que se dignen a informarse un poco más, pues con esos «sanbenitos», esas opiniones dichas a la ligera a una audiencia quizás no muy bien informada, se hace mucho daño a algo que está democratizando la web, y que incluso a tu medio le está facilitando su publicación, sin coste alguno de licencia, soporte gratuito por parte de usuarios y actualizaciones gratis por parte de la comunidad WordPress.

Actualización: La rectificación

Después de plantear mi queja el autor me indicó que se había modificado el artículo, en concreto el último párrafo, para subsanar los errores, quedando así:

Y, salvo la «recomendación», sinceramente, se siguen haciendo afirmaciones que no salen en ningún caso del artículo fuente. Vamos, una rectificación a medias creo yo, muy a medias.

La entrada ADSLZone recomienda encarecidamente no usar WooCommerce – ¿El motivo? te sorprenderá la publicó primero Fernando Tellado en Ayuda WordPress. No copies contenido, no dice nada bueno de ti a tus lectores.

El asombroso caso del código que ralentizaba mi web más de 5 segundos – No imaginas lo que pasó después…

¿Te acuerdas que ayer te contaba que descubrí lo de WooCommerce Analytics buscando solución a otro problema? Pues hoy te contaré de qué iba la cosa.

El misterioso caso de 4 webs iguales pero una era más lenta que el resto

Resulta que tengo varias webs asociadas al blog que son donde ofrezco los distintos servicios WordPress. Pues todas tienen el mismo tema (Divi, sí, lo uso mucho y me encanta), prácticamente el mismo diseño unificado y casi los mismos plugins, pero una de ellas destacaba por ser excesivamente lenta, la web de servicios de consultoría y desarrollo web.

He de decirte que en alguna de las otras, como en la de mantenimientos WordPress, hay incluso más plugins y más consumidores de recursos, pero todas estas webs suelen cargar en torno a 1 segundo, a veces incluso menos, pero no la de servicios, que tardaba más de 6 segundos en cargar, algo que sin ser terrible no es mi ideal, todo sea dicho.

Huelga decir que en todas aplico las mismas estrategias de optimización, así que por ahí no había diferencias.

Pero lo más sorprendente es que la cosa no era de siempre, había sido algo repentino, a partir de una fecha concreta.

Es más, si te fijas en la captura los tiempos de carga se habían disparado pero la web pesaba lo mismo y generaba la misma cantidad de peticiones, raro raro.

Anteriormente a esa fecha los tiempos de carga eran muy similares al resto de webs, incluso a la de cursos WordPress, que además de WooCommerce tiene todo un LMS, Sensei, y varios plugins más para ofrecer una academia online a mis alumnos.

Llamando al C.S.I.

Pues bien, revisando las webs en detalle caí en la cuenta de que la única diferencia entre ambas era que en la web de servicios tengo activo JetPack para usar su módulo de formularios, pues me facilitaba mucho las cosas.

Luego, un repaso al informe de rendimiento en GTMetrix, me confirmó que todo el problema venía de un JavaScript que cargaba JetPack, y el solito generaba hasta 2 instancias, cada una de más de 1 segundo de tiempo de carga.

Sin saber aún de la existencia de WooCommerce Analytics, investigué un poco y encontré en el GitHub de JetPack un informe de este problema, en el que se daba una solución para evitarlo.

Y es que parece ser que el dichoso JavaScript, de nombre

s-202026.js

, perteneciente a las estadísticas de JetPack, incluso había provocado errores 500 en algunas webs.

¡Espera! ¿He dicho «perteneciente a las estadísticas de JetPack»? En este momento no me di cuenta de ello, pero luego si caí, más abajo te cuento.

Bueno, llegado a este punto probé el siguiente código, añadido a mi plugin de personalizaciones (también funciona en el archivo functions.php del tema activo):

/**
 * Fix the path of Woo script.
 *
 * @param string $url The URL to the file.
 * @param string $min_path The minified path.
 * @param string $non_min_path The non-minified path.
 */
function jetpackcom_fix_woo_script_path( $url, $min_path, $non_min_path ) {
	if ( wp_startswith( $min_path, 'https://stats.wp.com/s-' ) ) {
		return $min_path;
	}
	return $url;
}
add_filter( 'jetpack_get_file_for_environment', 'jetpackcom_fix_woo_script_path', 10, 3 );

Y el cambio de rendimiento fue bastante bueno, no constante, pero sí se notaba que bajaban los tiempos, aunque a veces el mismo JavaScript daba errores en alguna de sus instancias de carga, pero sobre todo, seguía cargándose.

Así que, aunque algo había mejorado el rendimiento, estaba aún lejos de mis estándares, sobre todo del más importante: comprender por qué pasan las cosas que pasan.

JetPack y la madre que lo parió

Así que, a lo tonto, se me encendió la lucecita y, repasando la página de GitHub caí en que esto venía de un módulo llamado WooCommerce Analytics, que ni sabía que existía porque en ninguna actualización se había pedido consentimiento alguno para esta recogida de datos, y esto te lo puedo asegurar porque JetPack lo traduzco a cada versión.

Lo más gordo del asunto es que a ti, como propietario de una tienda online no te aporta nada, ese módulo solo sirve para enviar información de tu Ecommerce, de tus productos, comportamiento de los usuarios y procesos de compra, a Automattic.

Dicho y hecho, miré en la instalación de JetPack, y al no encontrar el módulo en los ajustes «normales» (visibles más bien) busqué en la lista completa de módulos ocultos de JetPack, y ahí estaba el bicho.

Pero, me extrañaba haber leído que era algo que tenía que ver con las estadísticas de JetPack, que nunca activo, pero bueno, me puse a ello y desactivé el maldito módulo.

Dicho y hecho, probé la carga de la página, y a simple vista ya se notaba la diferencia, así que volví a analizarla y el cambio era sorprendente…

Haciendo una comparación con los resultados de justo antes de desactivar el módulo de WooCommerce Analytics se hacía más patente aún.

Y, por supuesto, ni rastro ya del JavaScript

s-202026.js

de las estadísticas de JetPack.

Repasando los cambios realizados, había pasado la web de cargar en más de 6 segundos a menos de 1 segundo.

¿Qué aprendo yo de esto?

No se tú, pero yo he aprendido algunas cosas de esta experiencia:

  1. Tengo que repasar todas las webs en las que tenga JetPack para desactivar cagando leches el módulo de WooCommerce Analytics. A mi no me aporta nada, solo sirve para enviar datos a Automattic.
  2. Nunca actualizar ningún plugin sin comprobar si la actualización ha afectado de algún modo a los tiempos de carga de la web. Es algo que hacía de vez en cuando pero ahora lo hago siempre, nada más actualizar.
  3. No volver a fiarme de JetPack, y por extensión de Automattic, y su no cumplido compromiso con la privacidad.
  4. Se confirma una vez más que el compromiso de las empresas no europeas con la privacidad de los usuarios es mero postureo, a la que te descuidas te meten en un lío legal con los visitantes y clientes de tu web, recopilando datos sin informarte, y en consecuencia sin que tú puedas informar a los usuarios de TU web.

Nota: Si quieres saber las implicaciones de privacidad del módulo WooCommerce Analytics de JetPack te recomiendo leer este otro artículo que publiqué.

La entrada El asombroso caso del código que ralentizaba mi web más de 5 segundos – No imaginas lo que pasó después… la publicó primero Fernando Tellado en Ayuda WordPress. No copies contenido, no dice nada bueno de ti a tus lectores.