Los 12 peores errores que cometen los desarrolladores avanzados de WordPress

WordPress es una forma muy popular de poner en marcha un sitio rápidamente. Sin embargo, en su prisa, muchos desarrolladores terminan tomando decisiones terribles. Algunos errores, como dejar WP_DEBUG establecido en true , pueden ser fáciles de cometer. Otros, como agrupar todo su JavaScript en un solo archivo, son tan comunes como los ingenieros perezosos. Independientemente del error que logre cometer, siga leyendo para descubrir los 12 errores más comunes de WordPress que cometen los desarrolladores nuevos y experimentados. Si te encuentras cometiendo uno de estos errores, no te desesperes. Cada error es una oportunidad para aprender.

1. Colocar el código JavaScript del tema de WordPress en un archivo principal

Una vez, mientras optimizaba la velocidad de la página para los sitios web de un cliente, noté que estaban usando un tema premium que tenía todas las bibliotecas que estaban usando, incluido el código personalizado, en un solo archivo llamado main.js , theme.js o custom.js . Esta práctica es mala por las siguientes razones:

1. El archivo, con el tiempo, puede volverse realmente grande ya que el tema, que se está desarrollando activamente, crecerá en funciones y, a veces, verá archivos de hasta 1 MB de tamaño. El archivo se cargará en todo el sitio incluso si solo se necesita el 10% del código del archivo en algunas páginas. Esto hará que las páginas tarden más en descargarse y más lentas en renderizarse, especialmente si se trata de un código de bloqueo de renderizado dentro de la sección principal de la página.
2. Hace que administrar el código dentro del archivo sea más difícil, ya que no puede usar funciones como wp_dequeue_script() para descargar parte del código en algunas páginas para mejorar la velocidad de la página o para evitar un conflicto con otro código JavaScript que podría ser cargado por uno de los complementos activos. Claro, el archivo se puede dividir en varios y poner en cola en WordPress, pero si en algún momento posterior, el administrador del sitio web realiza una actualización del archivo main.js del tema, entonces todo el proceso debe comenzar de nuevo.

2. Uso de nombres que son demasiado comunes para variables, funciones, constantes o clases

Al desarrollar un complemento, es mejor usar una convención de nomenclatura que evite conflictos de código en caso de que haya otros complementos que usen el mismo nombre. Es por eso que muchos desarrolladores anteponen sus variables y nombres de funciones con algo único y relacionado con el propio complemento. Además de eliminar el conflicto de código, también facilita encontrar las cosas cuando tiene muchos complementos habilitados.

Hay desarrolladores, por otro lado, que prefieren usar espacios de nombres de PHP para encapsular elementos y resolver los dos problemas que encuentran los autores de bibliotecas y aplicaciones al crear elementos de código reutilizables, como clases o funciones:

1. Colisiones de nombres entre el código que crean y PHP interno o de terceros, clases, funciones o constantes
2. Capacidad de alias (o acortar) Extra_Long_Names diseñado para solucionar el primer problema o mejorar la legibilidad del código fuente. Este es mi favorito ya que a menudo desarrollo temas o complementos que tienen mucho código. Con esto, puedo leer y administrar el código fácilmente sin tener que preocuparme mucho por tener nombres largos y únicos.

Recomendaría una buena comprensión de los espacios de nombres antes de usarlos, ya que a menudo se pueden usar de manera incorrecta.

Dependiendo del proyecto que tomará a bordo, es probable que tenga que ceñirse al estilo de codificación existente, a menos que su trabajo esté mayormente separado del existente. En caso de que tenga que ampliar un complemento o tema existente que ya sigue los estándares de codificación de PHP para WordPress, entonces es mejor ceñirse a ellos para tener un estilo consistente para que el código sea limpio y fácil de leer. Tenga en cuenta que algunas reglas se aplican universalmente para mejorar el rendimiento, sin tener en cuenta el estilo de codificación. Por ejemplo, siempre es mejor usar comillas simples (en lugar de dobles) si no está evaluando nada en la cadena. Además, el código debe estar sangrado para poder leerlo, especialmente si tiene código anidado (por ejemplo, IF dentro de IF , FOREACH y FOR s anidados).

3. No aprovechar la funcionalidad principal existente de WordPress en su verdadero potencial

Como WordPress viene con un conjunto de bibliotecas actualizadas periódicamente a las que solo se pueden llamar en nuestros complementos y temas, es mejor hacer el mayor uso posible de la funcionalidad principal existente. He visto temas y complementos de WordPress que tenían archivos en su directorio de activos que ya estaban en los archivos principales de WordPress (por ejemplo, jQuery o Color Picker). Además del hecho de que el paquete se hará más grande y tardará más en cargarse a través de la red, también debe asegurarse de que todas las bibliotecas de terceros se actualicen regularmente, lo cual es solo otra cosa a tener en cuenta.

Aproveche lo que WordPress ya tiene para ofrecer, ya que el equipo central de desarrollo de WordPress ya actualizó las bibliotecas y puede tener un proyecto liviano y más fácil de mantener. Al realizar actualizaciones periódicas de WordPress, obtiene acceso a más funciones (ya sea un complemento, un tema o el propio núcleo de WordPress, ya que su Panel de control se mejora constantemente) y hace que el sitio web sea más seguro en caso de que se encuentren vulnerabilidades en las versiones de código antiguas.

4. No hacer que el complemento o el tema sean fáciles de modificar a través de acciones y filtros

Editar un complemento o tema de WordPress directamente es una mala idea, a menos que, por supuesto, esté directamente involucrado en el desarrollo de ese paquete y contribuya a su código. Si se realiza una actualización automática del complemento o del tema, se perderán todos los cambios directos en el paquete y tendrá que editar los archivos nuevamente.

Es por eso que el uso de acciones y filtros, así como la creación de un tema secundario (que amplía el tema principal) son los enfoques más efectivos para modificar un tema, ya que puede modificar la funcionalidad existente sin editar el tema principal o el complemento en sí. Además, si está ofreciendo un complemento para descarga gratuita en WordPress.org y más adelante desea crear una extensión premium que dependa del complemento principal, entonces debe desarrollar el complemento gratuito de tal manera que ser fácil de extender y agregar extensiones premium.

5. Desarrollando con WP_DEBUG Establecido en false

De forma predeterminada, la constante WP_DEBUG se establece en 'falso' para evitar la impresión de errores, advertencias y avisos de PHP. En un entorno en vivo, esta es una opción recomendada, ya que mantiene las rutas del servidor privado y los scripts ocultos a la vista del público, lo cual es excelente por razones de seguridad. Sin embargo, durante la etapa de desarrollo, es mejor configurarlo como "verdadero", ya que nos notificará cualquier error en nuestro código. Incluso si los errores no afectan directamente la funcionalidad, a menudo lo obligarán a escribir mejor código y desarrollar mejores hábitos de codificación. Me pasó a mi. Esto también garantizará que el complemento o el tema que desarrolle no genere errores de PHP en ninguna instalación de WordPress.

Si bien esto es algo que hacen la mayoría de los desarrolladores experimentados, sucede, especialmente cuando hay prisa. No importa cuán urgente sea el trabajo, los desarrolladores siempre deben tratar de mantener los estándares de codificación de WordPress, con un ojo obvio en las mejores prácticas de PHP.

6. Escribir código PHP sin tener en cuenta que la página podría almacenarse en caché algún día

Este es un error común de PHP y, al igual que el anterior, es relativamente fácil de evitar si se apega a los estándares de codificación de PHP.

Algunos desarrolladores tienen la costumbre de implementar fragmentos de PHP en temas y complementos que solo son válidos si el código PHP se activa todo el tiempo. Por ejemplo, una función de PHP que responda al agente de usuario HTTP con ciertas acciones debe tomarse o no (por ejemplo, secuencias de comandos en cola que están destinadas solo a usuarios móviles).

Si su cliente instala un complemento que almacena en caché la página (por ejemplo, W3 Total Cache o WP Rocket) sin activar los condicionales en su tema o complementos, su código PHP se volverá inútil. Si la intención es hacer que las páginas respondan, entonces esto debe hacerse en el lado frontal a través de consultas de medios y JavaScript. Esto último, sólo si realmente se requiere. Idealmente, desea evitar el uso de JavaScript para que su sitio responda.

7. No realizar un seguimiento de los cambios realizados de forma profesional a través de un sistema de control de versiones como Git

Los archivos que están codificados de forma personalizada, como un tema secundario o un complemento personalizado, idealmente deberían estar bajo control de versión. Git crea un registro de lo que se cambió y permite a los desarrolladores trabajar juntos en el mismo proyecto de WordPress o volver a una versión anterior fácilmente cuando algo sale mal en el sitio web. Además, los clientes pueden usar Git para realizar un seguimiento de todo el historial de trabajo realizado por todos los desarrolladores que fueron contratados para ese proyecto en particular, especialmente si se trataba de un sitio web personalizado de WordPress grande y a largo plazo.

Aunque puede ser intimidante al principio, especialmente para los desarrolladores junior, comprender Git valdrá la pena y un software de GUI de Git como SourceTree (uno de mis favoritos) sería simplemente la forma en que interactúa con sus repositorios de Git, haciendo que todo curva de aprendizaje más agradable. Una vez que comprenda cómo funciona, considere consultar las mejores prácticas y consejos de Git de los desarrolladores de Toptal que explican con más profundidad algunas formas de usar Git.

8. Poner en cola archivos CSS y JavaScript cuando no se necesitan

Tener muchas solicitudes HTTP haría que el sitio web fuera más lento para cargar, por lo que tendría una puntuación más baja en Google PageSpeed, lo que probablemente afectaría el ranking de búsqueda. También podría generar errores de JavaScript debido a conflictos entre complementos. Por ejemplo, podría haber dos complementos que usen una biblioteca jQuery común, que se puede cargar dos veces y podría causar problemas. Y realmente, este es el mejor ejemplo, ya que jQuery se carga muy comúnmente en sitios web en vivo varias veces. Esto probablemente sucede debido a complementos o temas mal escritos.

9. Uso de archivos .php para generar código CSS o JavaScript en lugar de archivos estáticos .css y .js

He visto temas e incluso complementos de WordPress que tenían archivos como style.php que se usaban solo para generar código CSS personalizado e imprimirlo. Cosas como los colores, los tamaños de fuente y el espaciado alrededor de los elementos se establecieron en la configuración del tema y luego se guardaron en la base de datos. Luego se lee style.php (p. ej., <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) y genera el código CSS basado en la configuración personalizada que se actualizaron en el tablero.

Esta es realmente una mala práctica en términos de rendimiento de WordPress. Aquí están las principales desventajas que vienen con él:

1. Como el archivo CSS se carga dentro de la etiqueta head (lo cual es normal y la mayoría de ellos se cargan así), hay un problema de rendimiento que viene con esto, ya que el navegador tiene que descargar el archivo por completo antes de mostrar la página. Si el entorno de WordPress es lento debido a algunos complementos, esto retrasará considerablemente el tiempo de carga. Incluso si se utilizan técnicas de almacenamiento en caché o solo se carga una parte del entorno de WordPress para recuperar los valores de la base de datos. En su lugar, es mejor usar un archivo .css estático.
2. En el archivo PHP, el código (reglas CSS mezcladas con variables PHP y cláusulas condicionales) será más difícil de leer para los desarrolladores cuando necesiten revisar algo. Claro, el archivo se puede ejecutar en el navegador (aunque estoy seguro de que cuando se imprima, ni siquiera tendrá una sangría ni se verá bien), pero si tiene una copia local del proyecto y navega por el código del tema y necesita para encontrar una sintaxis de CSS o JavaScript (en caso de que se use script.php), entonces dificultaría la legibilidad.

La solución: guarde cualquier CSS personalizado fuera del directorio de complementos. Ejemplo: /wp-content/uploads/theme-name-custom-css/style-5.css . De esta manera, en caso de que el tema o el complemento se actualicen, el archivo personalizado no se perderá.

10. No usar la arquitectura correcta (organización del código) para los complementos y temas de WordPress

Según el tamaño y la naturaleza del complemento (por ejemplo, un complemento independiente o una extensión de complemento que funciona solo si se activa un complemento principal, como WooCommerce), se debe configurar la arquitectura y la organización del código correctas.

Si tiene que crear un complemento de WordPress de un solo propósito para un cliente y tiene una interacción limitada con el núcleo de WordPress, los temas y otros complementos, no es efectivo diseñar clases complejas a menos que esté seguro de que el complemento se expandirá considerablemente más adelante. en.

Si el complemento se va a presentar con mucho código, entonces tendría sentido usar un enfoque de codificación de Programación orientada a objetos (OOP) (con muchas clases). Por ejemplo, si tiene muchos códigos abreviados, puede guardarlos todos en un archivo de clase separado, como class.shortcodes.php , o si hay archivos CSS y JavaScript que deben cargarse en el panel y en la vista frontal. entonces se puede usar una clase como class.scripts.php y poner en cola los archivos front-end dentro de un método como enqueue_public_scripts() mientras se ponen en cola los archivos destinados a cargarse en el área de administración dentro del método enqueue_admin_scripts() .

En lugar de mezclar HTML con el código PHP, es mejor mantenerlo separado implementando el patrón MVC en los complementos y temas. Un buen ejemplo es el complemento WooCommerce. Tiene plantillas para varios diseños que también se pueden sobrescribir fácilmente a través del tema o varios filtros solo porque la lógica está separada del diseño. La plantilla que contiene el diseño HTML se utiliza principalmente para imprimir la información ya procesada. Tener código HTML dentro de los métodos PHP suele ser una mala práctica (hay excepciones, por supuesto, para pequeños fragmentos de código HTML), especialmente para un complemento que es mantenido por más de un desarrollador a medida que crece en tamaño.

De acuerdo con el Manual de complementos de WordPress, si bien hay una serie de posibles patrones de arquitectura, se pueden agrupar ampliamente en tres variaciones:

• Archivo de complemento único, que contiene funciones
• Archivo de complemento único, que contiene una clase, un objeto instanciado y, opcionalmente, funciones
• Archivo de complemento principal, luego uno o más archivos de clase

11. No tomar en serio la seguridad de WordPress al escribir código

La seguridad a menudo no se toma en serio en el desarrollo de WordPress, ya que muchos desarrolladores novatos se enfocan más en los resultados que el cliente desea. Todo está bien hasta que el sitio web del cliente es pirateado o su complemento publicado en WordPress.org tiene una vulnerabilidad, lo que deja a miles de sitios web afectados. Estas cosas suceden a veces e incluso el núcleo de WordPress ha lidiado con una buena cantidad de vulnerabilidades de seguridad desde los primeros días del CMS. Es nuestra responsabilidad hacerlo lo más seguro posible y, en caso de que suceda algo, actuar con prontitud y asegurarnos de lanzar un parche sólido y bien probado.

Algunos de los consejos de seguridad más importantes son:

Vulnerabilidades XSS: para evitar esto, se deben hacer dos cosas: desinfectar la entrada de datos y desinfectar los datos de salida. Según los datos y el contexto en el que se utilicen, existen varios métodos en WordPress para desinfectar el código. No se debe confiar en ningún dato de entrada, ni en ningún dato que se vaya a imprimir. Una función común para desinfectar la entrada de datos es sanitize_text_field() . Comprueba caracteres UTF-8 no válidos, convierte caracteres < únicos en entidades HTML, elimina todas las etiquetas, elimina saltos de línea, tabulaciones y espacios en blanco adicionales y elimina octetos. En cuanto a la impresión de datos, un buen ejemplo para generar enlaces es la función esc_url() , que rechaza URL no válidas, elimina caracteres no válidos y elimina caracteres peligrosos.

Evite el acceso directo a sus archivos: se puede acceder directamente a los archivos ya que la mayoría de los hosts lo permiten. Sin embargo, si esto sucede y el código no está escrito correctamente para tratarlo, es posible que se impriman algunos errores (por ejemplo, funciones que faltan o variables que no están declaradas) que contendrían información valiosa para posibles atacantes. Un fragmento de código común que suele ver en complementos y temas es:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Si la constante ABSPATH no está definida (que debería ser para cualquier instalación de WordPress), el script se cerrará y no imprimirá nada.

Use Nonces: como se indica en la documentación de WordPress, un nonce es un "número que se usa una vez" para ayudar a proteger las URL y los formularios de ciertos tipos de uso indebido, malicioso o de otro tipo.

Por ejemplo, la siguiente URL dentro del tablero se usaría para eliminar una publicación: http://example.com/wp-admin/post.php?post=123&action=trash —Al acceder a esta URL, WordPress validará la información de la cookie de autenticación y si tiene el permiso adecuado (por ejemplo, es un administrador con todos los privilegios), esa publicación se eliminará.

Lo que un atacante podría hacer es hacer que su navegador acceda a esa URL sin su conocimiento creando un enlace en una página de terceros como en el siguiente ejemplo: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Al realizar esta solicitud a WordPress, el navegador adjuntará automáticamente su cookie de autenticación y WordPress considerará la solicitud como válida.

Ahí es cuando aparece un nonce, ya que el atacante no podrá obtener el valor del nonce (generado para el administrador que en realidad está conectado a WordPress) tan fácilmente. La nueva URL de solicitud se vería así: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Sin un nonce válido, WordPress enviaría una respuesta 403 Prohibida al navegador con el conocido mensaje de error: "¿Estás seguro de que quieres hacer esto?"

Aunque la mayoría de las personas no se toman en serio la seguridad de WordPress, piensan que su sitio web nunca será pirateado, confían en el alojamiento (que puede ser útil, pero solo hasta cierto punto) y en el hecho de que compraron complementos/temas comerciales (que a menudo llevan asumiendo que son muy seguros), siempre debemos hacer pruebas de penetración para nuestros sitios web con el fin de identificar vulnerabilidades explotables antes de que cualquier hacker pueda identificarlas y explotarlas.

Tenga en cuenta que una gran cantidad de pirateos no los realiza una sola persona con la intención de piratear específicamente su sitio web. A menudo, hay bots que escanean los sitios web de WordPress automáticamente de manera constante y, en el momento en que se encuentra una vulnerabilidad conocida, se explota y el servidor se usa para enviar spam, obtener información privada de la base de datos, colocar enlaces ocultos dentro de ciertas páginas del sitio web que conduciría a todo tipo de sitios web dudosos (por ejemplo, pornografía, drogas ilícitas). A veces, los hacks se ocultan tan bien que necesita un análisis adecuado de su sitio web y ver la fecha en que se actualizaron archivos específicos para detectar el código pirateado. Es por eso que es bueno incluso reinstalar WordPress (sí, la misma versión si tiene la última) para que los archivos originales de WordPress sobrescriban cualquier archivo pirateado.

12. Usar funciones de WordPress y fragmentos de código sin entenderlos

A menudo, cuando los desarrolladores se atascan y encuentran una solución en lugares como StackOverflow, simplemente están contentos con el hecho de que lograron hacer que algo funcione sin molestarse en comprender la lógica detrás de ese código o si ese código se puede modificar para cargar más rápido o tener menos. líneas de código.

He visto esta práctica tantas veces cuando se copian fragmentos de código dentro de scripts PHP cuando solo se usa un tercio de ese código.

Esto puede tener algunas desventajas, que incluyen:

1. El código no usa el mismo estilo que el código del proyecto existente. Sí, es cómodo simplemente copiar y pegar fragmentos que funcionan de inmediato y, aunque están bien para un pequeño proyecto personal (podría convertirse algún día en un gran proyecto, quién sabe), esta práctica a menudo no es buena cuando se trata de al trabajo comercial donde se debe mantener una consistencia de estilo.
2. Aunque el código hace su trabajo, podría contener funciones ineficaces que no son recomendables para la tarea que se necesita lograr. Si el código no está optimizado, esta práctica de "copiar y pegar" puede conducir a un sitio web lento y más difícil de mantener, especialmente si se usa más de un fragmento en varias ubicaciones dentro del proyecto.
3. Es posible que el código no tenga licencia para su reutilización, e incluir el código en el proyecto de un cliente puede generar muchos problemas legales.

Mejora constante

Todos cometemos errores, y cada error es una oportunidad para mejorar. Como desarrolladores de WordPress, nuestra industria se mueve a un ritmo muy rápido, y nunca hay una "manera correcta" establecida de hacer las cosas. Sin embargo, cuanto más practiques y aprendas, mejor te volverás.

¿No estás de acuerdo con alguno de los errores que señalé o crees que me perdí uno? Déjame saber en los comentarios y lo discutimos.