10 consejos para hacer que el mantenimiento de WordPress sea fluido

Como desarrollador de WordPress que ha trabajado en varios tipos de proyectos, me gustaría discutir algunos de los puntos débiles que he experimentado personalmente al tomar un sitio web de WordPress existente para editar o corregir errores. Los consejos y sugerencias enumerados en este artículo están destinados a minimizar o incluso deshacerse de estos dolores.

Por qué es importante el mantenimiento adecuado de WordPress

La mayoría de las veces, los sitios web no son un asunto de "establecer una vez y dejar en paz", y esto es cierto para todos los sitios, no solo para los de WordPress. De vez en cuando, tendrá que lidiar con ediciones, actualizaciones o correcciones de errores, de las que se encargará su desarrollador favorito. Sin embargo, en algunos casos, es posible que deba confiar en varios desarrolladores diferentes a lo largo de la vida útil de su sitio web.

En el último caso, las cosas a menudo no salen bien para el desarrollador entrante, especialmente si los desarrolladores anteriores no se adhirieron a las mejores prácticas al manejar sus tareas de mantenimiento.

Veamos algunos de los puntos más importantes a considerar en su futuro trabajo de mantenimiento en proyectos de WordPress para que pueda hacer la vida de su próximo desarrollador más fácil y hacer que les encante trabajar en su sitio. Obviamente, hacer que el trabajo de su desarrollador sea más fácil también ahorrará algunas horas de trabajo y dinero en el proceso, lo que siempre es un buen punto de venta para sus clientes potenciales.

1. ¡Haz una copia de seguridad!

Esto puede sonar demasiado obvio, ¡pero lo primero es lo primero! Debe hacer una copia de seguridad de su sitio de WordPress de manera adecuada y regular.

Esta es una de las cosas más fundamentales que debe hacer, incluso si no está realizando ningún cambio en su sitio en este momento. Puede hacerlo manualmente tomando todos los archivos más el volcado de la base de datos y almacenándolo en un lugar seguro, o puede usar una opción de copia de seguridad automática, cortesía de un complemento de copia de seguridad de WordPress. Hay muchos complementos gratuitos y de pago que puede encontrar en el repositorio de complementos de WordPress. También puede hacer un buen uso de la opción de copia de seguridad a nivel de servidor, ya que la mayoría de los proveedores de alojamiento ofrecen opciones de copia de seguridad; esto es algo que debe consultar con su proveedor de alojamiento.

Con copias de seguridad periódicas, tiene la tranquilidad de que su sitio volverá a estar en funcionamiento después de un bloqueo o un error. También podría ayudar a su nuevo desarrollador a solucionar problemas sin demasiados problemas, especialmente si está tratando de corregir un error que sospecha que podría haber ocurrido durante el mantenimiento en el pasado. Las copias de seguridad periódicas deberían ayudar a los nuevos desarrolladores a identificar y abordar problemas persistentes, que ocurrieron meses o años antes de que se hicieran cargo del proyecto.

2. Instale su sitio de WordPress localmente

No estoy orgulloso de admitir que yo mismo cometí este error en mis primeros días, y desde entonces he notado que muchos desarrolladores realizan ediciones directamente en el servidor remoto. A menos que le preocupe tener datos confidenciales y todos los archivos del sitio a merced de su desarrollador, debe evitar este error para siempre. Es muy ineficiente ir y venir entre la máquina local del desarrollador y el servidor después de cada edición.

Incluso si se trata de un pequeño cambio, como una edición menor para cambiar un poco de texto en su sitio, el desarrollador tiene que navegar al archivo/carpeta correspondiente en el cliente FTP (si está usando FTP para cargar archivos), espere los archivos a cargar, y espero que no haya fallas ocasionales en la conexión FTP. No olvidemos que algunos sitios web de WordPress tienen demasiados datos para mover prácticamente, sin perder demasiado tiempo y ancho de banda. Y, después de que todo se haya cargado correctamente, deben ir al navegador y actualizar la página que, nuevamente, depende de la velocidad y el estado de la red/servidor en ese momento. Puede parecer que estamos hablando de meros minutos y segundos que se pueden ahorrar con cada cambio, pero en el transcurso de su proyecto, estos minutos pueden sumar horas de trabajo innecesario.

Las ediciones son mucho más rápidas si sus desarrolladores tienen el sitio instalado en su máquina local: solo tendrán que hacer las ediciones, actualizar la página y listo. Incluso si viven dentro de una cueva sin conexión a Internet, aún pueden trabajar y cargar sus cambios en un momento posterior.

¿Qué sucede si tiene datos confidenciales que le preocupan o si hay algunas razones legales que le impiden compartir todos sus datos con los desarrolladores? En ese caso, puede preparar algunos datos ficticios específicamente para este propósito. También puede guardar estos datos para mantenimiento futuro.

3. Ir Git

Una de las mejores cosas que suceden en el mundo del desarrollo de software es el comienzo del control de versiones en línea. Menciono este punto porque hay muchos sitios que aún se ejecutan con el método tradicional cPanel/FTP para manejar archivos. O bien no saben lo bueno que es el control de versiones, o lo saben, pero dudan en implementarlo debido al esfuerzo de configuración inicial. Sin embargo, en realidad no es mucho trabajo y es cualquier cosa menos una tarea difícil.

El control de versiones viene con una gran cantidad de beneficios cuando se trata de administrar archivos, que incluye el seguimiento de cambios de varios autores, revertir ediciones fácilmente, la capacidad de tener ramas separadas para cada tarea independiente para asegurarse de que los cambios de cada tarea no interfieran con los demás.

Debe configurar Git en un servidor externo, que la mayoría de las veces está preinstalado por su proveedor de alojamiento. Es posible que necesite a alguien con cierta experiencia en servidores para iniciar el repositorio y configurar el flujo de trabajo, que no voy a discutir aquí porque está más allá del alcance de este artículo.

¡Y sin mencionar que en realidad no estás "git'ing" si no haces uso de las ramas! Haga al menos dos ramas para desarrollo y producción para que los desarrolladores puedan hacer todo el trabajo en la rama de desarrollo, probar el sitio y luego, si todo está bien, pasar a la rama de producción asegurándose de que nada salga mal en el sitio en vivo.

4. Eliminar archivos, códigos y complementos innecesarios

Es común dejar archivos y complementos que ya no son necesarios. Esto se convierte en un problema una vez que los archivos se acumulan con el tiempo a lo largo del ciclo de vida de su sitio web. Si a su desarrollador no le importaba eliminar los archivos no deseados que se agregaron con el tiempo, es difícil rastrear de dónde provienen y si alguna parte del sitio los usa actualmente o no. Esto causa un dolor de cabeza adicional ya que el sitio debe probarse una vez más para asegurarse de que nada se rompa después de eliminar esos elementos sospechosos.

Esto se puede eliminar eliminando los archivos no deseados de inmediato por parte del desarrollador correspondiente que trabajó en ellos. Puede enfatizar esta práctica a todos sus desarrolladores.

Además de los archivos y complementos de PHP, los archivos de medios no utilizados también pueden llenar su carpeta wp-content con el tiempo, lo que puede causar problemas a sus desarrolladores cuando trabajan con cualquier funcionalidad relacionada con los medios. Puede encontrar varios complementos para simplificar esta tarea. Un ejemplo es Media Cleaner.

El complemento presenta una papelera interna, que mueve los archivos allí temporalmente para asegurarse de que los archivos no estén realmente en uso; una vez marcadas, puedes eliminarlas permanentemente. Asegúrese de seguir el punto número 1 de este artículo (es decir, hacer una copia de seguridad) antes de limpiar cualquiera de sus archivos.

5. Comentar

Probablemente esté familiarizado con el meme de programación que dice algo así: cuando se escribió el código, el autor que lo escribió, sus compañeros de trabajo y Dios lo entendieron. Después de un tiempo, solo el autor y Dios sabían lo que hace, y ahora solo Dios sabe lo que hace, ¡a menos que el autor agregue los comentarios apropiados!

Algunos desarrolladores pueden ser reacios o francamente perezosos cuando se trata de comentar, pero es una práctica imprescindible en un buen entorno de desarrollo. Reduce el tiempo de edición y corrección de errores que, de lo contrario, los nuevos desarrolladores o incluso el mismo desarrollador dedicarán a descubrir qué hace un bloque de código en particular.

Se deben agregar comentarios siempre que la función/clase o el bloque de código no sea algo obvio, tome la siguiente función, por ejemplo:

 function stripWhiteSapaces(str) { … Return str; }

El nombre de la función anterior habla por sí mismo y tampoco es necesario que el usuario ingrese a la función para ver cómo funciona, solo está haciendo un trabajo, eliminando espacios en blanco, ¡eso es todo! Entonces, en este caso, los comentarios pueden no ser necesarios.

Pero, por ejemplo, si hay una función que acepta múltiples parámetros y devuelve una lista filtrada de publicaciones, entonces esto no es algo tan obvio como lo anterior. Debe haber comentarios que describan los parámetros y sus tipos. También podría ser necesario describir los bloques de código dentro de esta función.

Para una revisión rápida, puede tomar un archivo del núcleo de WordPress y ver cómo lo han comentado los expertos de WordPress. O, para obtener información más detallada, puede consultar la guía oficial de WordPress que lo ilustra bien.

6. Pelusa

Linting es otra característica interesante que hace cumplir las reglas sobre la forma en que escribimos el código y, a veces, corrige el formato del código en sí mismo, lo cual es interesante y útil. La mayoría de los IDE en uso hoy en día vienen con opciones de linting, que puede mejorar o personalizar aún más agregando varias configuraciones de linting.

Por ejemplo, cuando usa Visual Studio Code como su IDE, VS Code usa el linter oficial de PHP ( php -l ) para el diagnóstico del lenguaje PHP. Puede configurar reglas/restricciones para cada idioma por separado (es decir, PHP, JavaScript, CSS, etc.). Puede echar un vistazo a los estándares de codificación de WordPress para obtener más detalles.

• https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
• https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/

Una vez que tenga una configuración de pelusa, debe aplicarla. Todos sus desarrolladores actuales y futuros necesitan integrar esta configuración de linting en sus IDE para que su código también se adhiera a las mismas reglas/restricciones. De lo contrario, gran parte de su esfuerzo será en vano.

7. Nombres de variables y archivos

Diseñe un estándar que trate sobre cómo se nombran las cosas. Esto incluye nombres de funciones/clases, nombres de variables, nombres de archivos e incluso los nombres de medios/imágenes si es parte de la plantilla porque también ayudará a comprender para qué sirven.

Considere algunos de los puntos vitales:

1. Evite los nombres inequívocos
2. Sea breve cuando sea posible
3. A veces es realmente útil agregar el "tipo" al nombre del archivo. Por ejemplo, si es un ícono, puede tener algo como BlackArrowIcon.png o si es una imagen de fondo grande, puede ser algo como FrontYellowBG.jpg. O si se trata de un archivo de código, a veces es muy fácil saber qué significa ese archivo cuando se trabaja con varios archivos abiertos en varias pestañas del IDE. Por ejemplo, si hay una clase con funciones auxiliares, será útil si se llama HelperClass.php en lugar de Helper.php.

Para obtener más información, consulte la sección Convenciones de nomenclatura en la guía de mejores prácticas de WordPress.

8. Depuración de WordPress

La depuración puede llevar una cantidad significativa de tiempo y tiende a tener una gran participación en la cantidad total de tiempo de desarrollo, especialmente cuando se trata de ediciones o corrección de errores. Esto significa que debe tener en cuenta si sus desarrolladores lo están haciendo de la manera más eficiente posible. La mayoría de los desarrolladores son propensos a hacer esto var_dump manualmente las variables en alguna parte de la página web, lo cual no es el método más eficiente. Esto también puede causar dolores de cabeza a los desarrolladores que se unan al proyecto más adelante, ya que terminarán con líneas de código basura aquí y allá si el código de depuración no se limpia correctamente después de que se haya realizado el trabajo.

Hay algunos complementos para ayudar con esta tarea de depuración. Los siguientes son algunos ejemplos de complementos de depuración populares para WordPress.

• Depurador de Kint
• Barra de depuración
• Supervisión de consultas

9. Tener mejor CSS

Cuando se trata de desarrollo web, diseñar con CSS es una de las actividades más básicas. Desafortunadamente, eso significa que con frecuencia se pasa por alto y se le presta menos atención que JS, PHP, etc. Pero, lo crea o no, CSS puede causar una gran cantidad de problemas si no se diseña correctamente cuando intente agregar o editar algo en el futuro. a menos que su sitio sea básico y pequeño.

Si está interesado en saber más acerca de por qué esta técnica de estilo relativamente básica es propensa a problemas, puede buscar en Google por qué CSS es molesto, o puede leer más sobre las 5 cosas más molestas con CSS.

Aquí hay algunos consejos rápidos de mi parte sin muchos detalles:

• Hacer cumplir una buena práctica de nomenclatura. Use una metodología de nomenclatura como BEM (Block Element Modifier)
• Evite el estilo en línea. Utilice hojas de estilo externas en su lugar.
• Siempre que sea posible, intente idear patrones reutilizables comunes, sin solo aumentar los estilos cuando sea necesario.
• Divide los estilos en varios archivos según las características o áreas del sitio web. Si le preocupa que una mayor cantidad de archivos de estilo pueda afectar el rendimiento de la carga, puede solucionar esto utilizando un buen complemento de almacenamiento en caché que consolidará varios archivos en un solo archivo.
• Utilice el preprocesador CSS como SASS, LESS, etc.

10. Obtenga comentarios de los desarrolladores actuales

Como pensamiento final, y para completar la lista, puede obtener comentarios de sus desarrolladores sobre los problemas que enfrentaron al trabajar en su sitio. Es posible que puedan dar algunos buenos consejos, ya que son ellos los que se han ensuciado las manos en su sitio. También pueden señalar fallas o código sucio que dejaron los desarrolladores anteriores.