WordPress se ha convertido en una de las plataformas para construir un blog más populares que existen. Aunque hay un montón de plataformas que le hacen competencia directa, la verdad es que con cada actualización que hacen ganan más terreno. Por eso quiero compartir con ustedes los errores al desarrollar en WordPress más comunes.
Me siento orgulloso de ver de cerca la evolución que han tenido con el pasar de los años que llevo haciendo temas y plugins para mis clientes.
Hablé anteriormente sobre la popularidad que ha alcanzado y por qué en el post El futuro de wordpress en las ecommerce ¿cual es?.
WordPress no solamente es la opción más popular en plataformas CMS,, sino la forma más eficiente y rápida de crear un sitio web en 2019.
Cuando uno tiene 8 años -¿o quizás más?- trabajando con wordpress termina descubriendo lo mejor y LO PEOR de la herramienta. Y creeme cuando te digo que ha evolucionado un montón. He visto cosas que no creerías en el código fuente de todo tipo de temas y plugins (incluso de pagos).
Cuando se compra o paga una membresía de un plugin tema uno pudiera pensar que ya se está libre de cualquier problema de rendimiento o falla de seguridad. Si no me crees puedes leer un poco sobre los ataques más comunes en internet de 2019.
Lamento decirte, NO TE CONFÍES.
A continuación arrojaré un poco de luz sobre los errores más comunes que he encontrado en sitios web avanzados y no tan avanzados a lo largo de mi carrera, que aún siguen existiendo en 2019 con las versiones más recientes.
1. Usar pedazos de código sin entenderlos
Creo que este es un problema común no sólo en el ambiente de WordPress. Es una maldición del desarrollador que nos persigue. Desde que existe Stackoverflow, buscar y encontrar la solución a un problema se convirtió en un Copy/Paste de pedazos de código.
He visto memes de «teclados perfectos para un desarrollador» donde sólo aparecen las teclas Ctrl, C y V 😂. La cuestión es que muchos de estos pedazos podrían contener código de más, incompatiblidades con el lenguaje, malas prácticas, etc, etc. Asústate. Cosas que pueden hacer estallar tu sitio o el de tus clientes 😱.
Y si tienes tiempo trabajando con desarrollo web o de software, sabes que no es la experiencia más grata. Menos si tu sitio estalla en la noche o un fin de semana.
Como profesional no puedes vivir dejando a la suerte el funcionamiento de un sitio web por facilismo o comodidad. Ojo, tampoco estoy diciendo que no se deben usar éstas soluciones que nos salvan la vida y nos ahorran mucho tiempo, pero tómate el tiempo de analizar, de pensar, de entender qué hace y como optimizar. Ese tiempo que uses, a la larga te ahorrrá mucho tiempo en bugs y correcciones.
2. Colocar scripts y hojas de CSS en un sólo archivo en el tema o plugin
Lo más estresante de trabajar con WordPress puede ser la optimización de tiempos de carga para Pagespeed y las herramientas SEM. Si has intentado subir el score de un sitio en esta herramienta de Google en un sitio creado con WordPress es un dolor de cabeza.
Se debe principalmente a que cuando estás creando tu plugin, tema o tema hijo, comienzas a colocar todos los scripts que necesitas en un main.js, theme.js o custom.js por ejemplo. Te mantienes tan enfocado en que todo funcione a la perfección que terminas colocando en tu wp_enqueue_script un archivo de 1Mb que tarda una eternidad en cargarse, disminuyendo la velocidad de carga y el buen performance del sitio entero. Es un problema conocido como Bloqueo de renderizado.
Obviamente el sitio necesita todas las funcionalidades que están allí, pero de verdad es necesario todo en cada página? Algunas páginas o templates ni siquiera consumirán el 20% del código allí contenido, pero wordpress igual lo renderizará todo, bloqueando el renderizado sobre todo para personas con conexión a internet lentas.
Mi solución para eso es, crear múltiples hojas de estilo o scripts con una funcionalidad específica bien separada y codificada. Luego con un simple if/else decirle a wordpress qué archivos y cuales no renderizar en que situación. Esto aligera la carga enormemente de la cantidad de archivos que se deben descargar y renderizar y mejora el tiempo de carga. Además que de esta forma puedes usar plugins como Asset CleanUp que recomiendo muchísimo porque ayuda a separar los scripts y estilos que no son necesarios.
3. No tomar en serio la seguridad al momento de programar para WordPress
WordPress es un CMS genial, muy popular y poderoso. Pero no es muy conocido por ser súper seguro. Al ser tan popular, una multitud de hackers intentan día y noche encontrar vulnerabilidades para explotarlas. La mayoría de las veces estos hackeos son realizados por bots que están scaneando constantemente la web en busca de errores y vulnerabilidades. Al encontrarlas, insertan código malicioso que hace spam, hace redirecciones a sitios sucios de pornografía, drogas, etc.
Son vulnerabilidades comunes de la plataforma que han sido aseguradas, pero otras siguen allí. Muchos plugins y temas tienen vulnerabilidades insólitas que están allí, esperando a ser encontradas. Me he encontrado con errores y he aprendido a fortalecer y desarrollar siempre pensando en la seguridad primero.
Algunas de las vulnerabilidades más comunes que son responsabilidad de los desarrolladores de plugins y temas son:
Ataques XSS: Hay un término en WordPress y la web en general conocido como Sanitize (desinfectar) y se usa en wordpress por medio de las funciones sanitize_text_field()esc_url() entre muchas otras que vale la pena considerar para evitar éste ataque. Un desarrollador siempre debe programar de forma defensiva, nunca confiando en los datos que envía un usuario. Sea por un error del usuario enviando caracteres incorrectos o por una mala intención.
Lo que hacen éstas funciones de desinfección es buscar caracteres inválidos de UTF-8, símbolos <>, remover exceso de espacios en blanco, remover saltos de línea, etc. Sin éstas funciones cualquiera podría inyectar código javascript o php y hacer fallar o descontrolar nuestro sitio.
4. No prevenir acceso directo a los archivos en tu plugin
Para tratarse de un sistema CMS hecho con PHP, y funcionando en Apache, WordPress ha mejorado bastante la seguridad en general. Pero aún siguen quedando muchos huecos de seguridad en los que puedes ser atacado si no tomas las precauciones.
La mayoría de servidores y servicios de hosting en sus configuraciones tienen unos archivos de acceso llamados .htaccess. Este archivo lo que hace es ayudar a acceder de forma amigable archivos como index.php, etc. Supongo que ya conoces su función.
Por ejemplo, digamos que creas un archivo llamado phpinfo.php y colocas una función como ésta:
<?php phpinfo(); ?>Esa función lo que hace es mostrarte toda la información completa del servidor. El Sistema Operativo, el lenguaje, las configuraciones de PHP que estés usando y sus valores, etc. Este archivo luego de creado lo podrás acceder con una url como tu-sitio.com/phpinfo.php. Si lo haces te mostrará algo como esto:
Ok, hasta aquí no hay ningún problema. Nada va a pasar.
Pero ¿que tal si ahora un posible atacante o un usuario por error coloca tu-sitio.com/wp-content/plugins/tu-plugin/archivo.php?
Aquí si se pone grave la cosa porque al hacer eso, PHP automáticamente intentará ejecutar funciones, procesos y demás por lo que saltarán errores muy feos por los aires. Y estos errores traerán con ellos información muy sensible de tu servidor, como por ejemplo la ruta raíz del sitio y otros datos.
Creeme que NO quieres que un potencial atacante vea la información contenida en un error fatal o warning de PHP.
Para solucionarlo, puedes usar este fragmento de código en el top de los archivos de tu plugin que no quieres que sean accedidos directamente. Seguramente si haces plugins ya lo habrás visto revisando el código de otros plugins.
// Exit if accessed directly
if ( ! defined( 'ABSPATH' ) ) exit;
Básicamente el fragmento dice que si el archivo es accedido directamente desde una solicitud http, bloquee el mismo y retorne un exit. Tambien puedes mejorar ese fragmento con una redirección al homepage de tu página o botar un bonito u odioso mensaje de ¡Vete malhechor! 😂
Cuidado, nadie con buenas intenciones quiere acceder a la ruta directa de un archivo en un sitio web del cual no es el dueño. 😜
5. Usar nombres de variables, funciones, constantes o clases demasiado comunes
En una oportunidad leí el libro de The Pragmatic Programmer y en muchas oportunidades el autor menciona que es vital que los nombres de las funciones, variables y clases sean totalmente descriptivas y de fácil comprensión de lo que hacen.
Pero ¿qué podemos hacer con WordPress? A menos que estés usando una estructura MVC con Namespaces, Clases y Objetos, estás arriesgándote a explotar el sitio por un problema conocido como colición de nombres.
Este problema no es único de WordPress (de hecho por eso se crearon los estándares PSR-4). La solución que se implementó por parte de los mantainers de PHP fué crear las estructuras conocidas como Namespaces y PSR-4. Pero en WordPress se acostumbró a desarrollar de una manera un poco desordenada.
Si colocas una función que se llame por ejemplo mi_funcion_para_cualquier_cosa(), no hay ningún problema en lo absoluto. De hecho es el estándar para WordPress. Pero ahora imagina que tu o tu cliente instala un plugin que tiene una función con ese mismo nombre 🤖. Lo que vendrá después de la instalación y activación será una colisión de nombres, y consecuentemente la explosión de un error fatal en tu sitio, que si no tienes experiencia desarrollando, tardarás mucho tiempo en encontrar o solucionar.
6. No usar los Actions y Filters existentes de forma adecuada
Uno de los casos más típicos que me encuentro de este error es con Woocommerce. Cada vez que los desarrolladores de Woocommerce lanzan una actualización, me dan ataques de pánico cuando un sitio no lo mantengo yo. Modestia aparte pero es que ya tengo muchos años trabajando en esto y se con qué me encuentro y con qué no.
Siguiendo con el ejemplo de woocommerce, lo primero que un cualquiera hace cada vez que quiere modificar plantillas de Woocommerce es copiar la carpeta template en su tema o plugin y comenzar a cometer el sacrilegio innecesario.
Ojo, no digo que no se deba hacer, pero casi el 99% de los casos, si usas bien los hooks internos del plugin, podrás hacer magia y dominar casi cualquier característica del plugin sin tocar la prohibida carpeta template.
¿Cual es la solución? Hacer uso de los hooks. Podrás encontrar las mejores prácticas y consejos para editar las características en la propia documentación de Woocommerce.
7. Usar WP_DEBUG mientras desarrollas y desplegar tu sitio con el valor en true
WordPress tiene una constante interna asombrosa y muy útil para cuando intentas detectar el origen de un error o desarrollas. Esta herramienta es WP_DEBUG. Se usa colocando su valor en true, y sólo (enserio, sólo) en caso de desarrollo o debuggeo. Nunca debe estar en true si no es un ambiente de desarrollo o pruebas.
Incluso si estás intentando debuggear un error, sería mejor clonar el sitio en un lugar solo de pruebas y activarla allí. Esta variable puede generar Logs, o mostrarlo en pantalla del usuario si no tienes cuidado.
Se puede usar junto a otras 2 constantes que nos sirven para desarrollo o debuggeo. WP_DEBUG_DISPLAY hará que el error se muestre en pantalla mientras programas. WP_DEBUG_LOG hará que el error se guarde en un archivo dentro de wp-content/ con los errores más detallados.
WordPress es genial, la verdad. Es lo más potente, flexible y popular estos días. Tiene una comunidad desarrollando y fortaleciendo la plataforma cada día. Personalmente cuando intento hacer trabajos de blogging, WordPress es mi preferido.
Sólo cuando quiero llevar a cabo un proyecto de ecommerce y dependiendo de las necesidades uso Shopify.
Procuremos crear una generación nueva que sepa aprovechar mejor la potencia de WordPress. Últimamente wordpress dejó de ser un mal CMS para ser cada vez mejor. Diría que sólo le falta tener más facilidades para crear plugins y temas con Angular o React en su plataforma, sin embargo con los conocimientos adecuados podrás.
Haz la tarea completa y ponte a investigar cómo desarrollar en WordPress de forma ordenada, segura y escalable. Evitemos los errores al desarrollar en wordpress para que seamos mejores profesionales. Dejame en los comentarios si conoces otro error común. Así podemos nutrirnos como comunidad. Saludos y un abrazo.
