Mis cinco peores errores de desarrollo de WordPress

O a todos los servidores en los que me he hundido antes: una mirada retrospectiva a los cinco peores errores de WordPress que he cometido

Como desarrolladores, cometemos diferentes tipos de errores en diferentes puntos de nuestra carrera. En el desarrollo de WordPress, en particular, cometemos diferentes tipos de errores a medida que crece nuestra familiaridad con el código base de WordPress.

Hace algunos años escuché a Matt Mullenweg declarar algo en el sentido de que la mayoría de las personas repiten sus errores, las personas más inteligentes aprenden de sus errores y las personas más inteligentes entre nosotros aprenden de los errores de los demás. Me gusta más esto, y agregaría un corolario: todos cometemos errores, la gente humilde comparte esos errores en privado, y los más atrevidos los escriben y los publican en un blog.

Pero hay tiempo para reflexionar más tarde. Estás leyendo este artículo porque quieres saber sobre un accidente de tren, y yo soy el ingeniero. Sin más preámbulos, únase a mí en una mirada retrospectiva a los cinco errores más vergonzosos que he cometido como desarrollador de WordPress.

La vez que actualicé una versión pirateada de WordPress Core

Me acababa de graduar de hacer conciertos de codificación de CraigsList muy oscuros, a trabajar en una agencia real en vivo. ¡Yo había llegado! Estaba nervioso por estar trabajando desde otro lugar que no fuera mi sofá, en algo que no fuera mi pijama. Pero incluso entonces, en general conocía WordPress directamente de WordPress Doing It Wrong, y me pareció gratamente engreído jactarme de las mejores prácticas de WordPress, como nunca "hackear el núcleo".

Mi primera tarea de desarrollo de WordPress en esta agencia fue reanudar un proyecto estancado, bastante complejo para mi conjunto de habilidades en ese momento. Involucró muchas personalizaciones en el registro de WordPress y el flujo de inicio de sesión. Se decía que el desarrollador anterior había logrado un progreso significativo simplemente editando los archivos principales wp-login .

Sabía que esto era insostenible, por lo que mi primera orden del día fue instalar un complemento de copia de seguridad/restauración y reemplazar el núcleo de WordPress con una versión recién descargada. Estaba seguro de que no se había realizado nada terriblemente impresionante hasta el momento en el proyecto, y que sería capaz de imitar el conjunto de funciones existente a través de filtros.

Cualquier habilidad de codificación que pudiera o no haber tenido en ese momento rápidamente se volvió irrelevante, ya que mi nuevo empleador estaba hirviendo de locura. Ella no entendió el significado de "hackear el núcleo" y yo no era lo suficientemente maduro para explicarlo de una manera digerible. Lo único que la enfrió temporalmente fue cuando le aseguré que podía revertir a través del complemento de copia de seguridad/restauración que instalé.

¿Puedes adivinar a dónde va esto?

Ese complemento, como el destino lo tendría, solo hizo una copia de seguridad de la carpeta wp-content . Cualesquiera que fueran los hacks de WordPress en esos archivos centrales, desaparecieron para siempre. Todavía recuerdo el correo electrónico que le devolví (hace mucho tiempo que me había desterrado a mi oficina en casa en este momento):

Chicos, no puedo hacer la copia de seguridad.

Realmente estaba preparado para completar su conjunto de funciones deseadas a través de filtros y acciones, pero ella no lo escuchó. Me despidió en el acto, me amenazó con demandarme y nunca me pagó por dos semanas de trabajo muy duro. Estaba tan humillado.

Hay muchas cosas (ahora obvias) que podría haber aprendido de esta experiencia. La lección general, que una copia de seguridad no es una copia de seguridad hasta que se ensaya y confirma, es buena. Pero el que me quedó más grabado es una lección específica sobre cómo hacer exactamente las copias de seguridad en WordPress, particularmente con el núcleo de WordPress.

Aprendí a apreciar realmente los entornos administrados como WP-Engine, con un sólido sistema de copia de seguridad/restauración. Muchos hosts boutique tienen varias herramientas de línea de comandos y otras características enfocadas en el desarrollador para realizar copias de seguridad, pero WP-Engine es mi favorito. Es bastante rápido a menos que tengas una red muy grande. La interfaz de usuario es simple. Tiene una interfaz de usuario, punto: cualquiera que sepa cómo usar WordPress puede trabajar con esto. Es decir, en contraste con algún enfoque de CLI que probablemente sea mucho más rápido, o alguna cosa oscura enterrada en Plesk, mis clientes pueden usar esto, entenderlo, monitorearlo y verificar que lo estoy usando. Soy un gran fan.

La vez que arrastré toda nuestra plataforma a su directorio hermano

Todavía era bastante nuevo en el lugar de trabajo profesional y siempre había sido una persona de Windows. Sin embargo, mi nuevo trabajo fue en una tienda de Mac y aprendí a amarlo todo muy rápido. Bueno, casi todo. Parecía tener muchos problemas con el "ratón mágico". Tenía una tendencia a perder mi conexión Bluetooth, lo que provocaba acciones accidentales y, a menudo, aterradoras de arrastrar y soltar una vez que se reconectaba. Más que eso, simplemente era torpe con una nueva habilidad motora fina.

En estos días, nuestro flujo de desarrollo de WordPress aún incluía la implementación en producción a través de FTP. No era raro que pasara días enteros de trabajo escribiendo código, chateando, respondiendo correos electrónicos, generalmente girando de un lado a otro con mi nuevo mouse mágico, con Cyberduck abierto para producción en mi escritorio. ¡Dios, eso suena mal! Pero así fue.

Un día, toda nuestra plataforma desapareció. Nuestro administrador de sistemas asumió rápidamente que se trataba de algún tipo de DDoS o algo en general a su nivel. En cuanto a nosotros, los desarrolladores, confiamos en sus instintos y asumimos que lo descubriría lo suficientemente pronto.

Pasaron las horas. El día vino y se fue. Todavía abajo.

A la mañana siguiente, las cosas se restauraron y nuestro CTO me pidió gentilmente que me uniera a ella en la sala de conferencias. Nuestro administrador de sistemas había identificado el problema. Extrajo los registros de FTP y observó que mi usuario había movido toda nuestra plataforma a un directorio hermano. Es decir, wp-content se había anidado en wp-includes .

Estaba cabizbajo, pero nuestro CTO fue genial al respecto. Ella pudo ver que, en general, yo era un empleado útil y responsable, pero me desafió a ir más allá del mero arrepentimiento y encontrar formas de evitar que esto vuelva a suceder. Encontré dos cosas realmente útiles.

El primero fue ubicar un comando CLI para evitar que Cyberduck permitiera movimientos de archivos de remoto a remoto. Esta fue una buena medida de seguridad y la adoptamos como política de la empresa de inmediato.

La segunda fue que me interesó mucho la implementación a través de Git. Eventualmente, terminé escribiendo un complemento de WordPress para entrelazar nuestro control de versiones de Bitbucket en el flujo de actualización normal wp-admin . Desde entonces, casi no hemos tenido motivos para tener acceso FTP a la producción. Este complemento es uno de mis logros profesionales favoritos. Por supuesto, una afinidad por Git es un requisito previo para los desarrolladores de hoy.

La vez que eliminé todo el contenido de front-end a través add_filter()

Realmente pensé que me había vuelto bastante inteligente con mis prácticas de WordPress en este punto. La solicitud fue agregar una "insignia" a las publicaciones de una determinada categoría. Por alguna razón, tenía en mente que solo los novatos agregarían otro condicional a un archivo de plantilla para algo como esto, así que con gran orgullo implementé el siguiente filtro:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

¿Ves algo malo en esto? Lo probé rápidamente en la puesta en escena para confirmar que se aplicaron las insignias a las publicaciones requeridas. Luego lo desplegué y dejé el trabajo por el día. Como puedes suponer, el universo explotó.

Específicamente, el resultado fue que las publicaciones sin la insignia se mostraban en la parte frontal sin ningún contenido. ¿Puedes ver por qué? El problema era que, en lugar de devolver $content en mi condición de guardia, devolvía false . Pero realmente hay muchas capas de errores aquí.

¿Por qué me contenté con solo probar que las publicaciones recibieron una insignia? ¿Por qué no probé también que otras publicaciones permanecieron ilesas? ¿Por qué estaba implementando la producción tan tarde en el día? ¿Por qué nuestro control de calidad consistía únicamente en hacer clic un poco y actualizar la página?

La respuesta a todas estas preguntas se puede resumir como madurez . Simplemente toma un tiempo cansarse de cometer este tipo de errores, antes de que nos movamos a invertir en cosas como pruebas de regresión visual y pruebas unitarias. Este error en particular fue una gota que colmó el vaso, entre cientos, que eventualmente rompió la espalda del camello y me llevó a invertir mucho en phpUnit y xDebug. A su vez, esas herramientas me han enseñado a escribir código comprobable, lo que probablemente ha evitado más errores que las propias pruebas.

El tiempo que dividí por cero dentro de un bucle infinito

La solicitud del cliente fue reformatear la publicación del blog de WordPress de modo que la fecha dijera "hace XYZ" en lugar de "10 de noviembre de 2011". No estaba exactamente seguro de cómo lograr esto, pero sabía que era un formato de fecha que parecía estar creciendo en popularidad y, de hecho, Dr. Google me proporcionó un fragmento muy rápidamente. ¡Funcionó en mi local! Tenía mucha matemática, en particular, mucha división . No estaba exactamente seguro de por qué funcionaba: había muchos bucles anidados, restos, redondeos y demás. Pero estaba en Google y parecía funcionar, y estaba lo suficientemente feliz como para implementarlo en producción.

Aproximadamente 30 minutos después, recibí un Skype hostil de nuestro administrador de sistemas. La producción estaba baja. Muerto en el agua. Me preguntó si había estado dividiendo por cero últimamente y no tenía ni idea de a qué se refería. Esto es lo que sucedió.

Lo crea o no, el fragmento ilegible "funcionó en mi local" que encontré, dado un tamaño de muestra lo suficientemente grande, era capaz de tener un comportamiento aberrante. Suministrados con algunas combinaciones desafortunadas de días, horas y minutos, los bucles de Rube Goldberg ocasionalmente intentarían dividir un número por cero. Recuerdo de las matemáticas de la escuela secundaria:

En la aritmética ordinaria, la expresión no tiene significado, ya que no hay ningún número que, cuando se multiplica por 0, dé a (suponiendo que a ≠ 0), por lo que la división por cero no está definida. -Wikipedia

Entonces, ¿qué significa esto para las computadoras? Por lo general, solo un mensaje de error en los registros, pero en mi caso, fue peor: el error matemático estaba interfiriendo con mi lógica de bucle, lo que provocó que mis bucles anidados se ejecutaran sin completarse nunca, un bucle infinito que conducía a una pantalla blanca de muerte. ¡Y se pone peor! Debido a que cada iteración del bucle estaba escribiendo un error para dividir por cero, el registro de errores creció en proporciones fantásticas y comenzó a obstaculizar nuestro sistema de archivos. Esto tuvo el efecto de un ataque DDoS, aunque absurdamente autoinfligido.

Lo malo de este error fue que eliminó un sitio de alto tráfico. Lo bueno de este error es que cambió drásticamente mi forma de trabajar. Más que nada, me avergonzaba mi voluntad de implementar sin comprender. Juré nunca volver a pegar un fragmento sin hacer todo el esfuerzo posible por comprender cada línea, incluso haciendo un seguimiento con el autor del fragmento si fuera necesario.

Más que eso, prometí nunca más enviar código que no fuera muy legible para los desarrolladores novatos. Me obsesioné con los estándares de codificación de WordPress, las extensiones del editor de texto, los comentarios en línea y los bloques de documentos, e incluso las pestañas frente a los espacios, ¡ese clásico rito de iniciación! En resumen, decidí preocuparme más por lo fácil que era leer mi código que por lo fácil que era escribirlo . Esta rebelión contra pegar sin comprender me llevó a tomar un profundo interés profesional en la gestión de dependencias de terceros, un tema que me ha dado varias oportunidades para escribir y hablar durante la década siguiente.

Ah, ¿y lo realmente divertido de este error? El núcleo de WordPress tiene una solución de una sola línea para ello.

La vez que dejé que un proyecto se saliera de control hasta que todos se hartaron

Había conseguido un proyecto realmente fascinante. Iba a ser el líder técnico y el ingeniero de desarrollo de WordPress, y tendría un desarrollador de Amazon AWS Lambda y un gran experto en JavaScript que me informarían. Esta fue la primera vez que varias personas me informaron y fue, con mucho, el proyecto más complejo en el que he trabajado. Incluso referirse a él como un proyecto de WordPress fue subestimar en gran medida el asunto, pero WordPress fue el pegamento que mantuvo todo unido, por lo que tenía sentido para mí actuar como líder técnico.

Debido a que mi función principal solía ser estrictamente un técnico, y también porque tengo afinidad por el minimalismo, nunca se me ocurrió implementar algo como Jira o Basecamp o cualquier plataforma real para la gestión de tareas. Las cosas procedieron bastante bien durante la primera iteración del proyecto. Pudimos trabajar en nuestros propios componentes individuales, referirnos al documento de especificaciones del cliente como nuestra hoja de ruta del producto y simplemente hacer ping entre nosotros a través de Slack cuando necesitábamos unir las cosas.

El problema comenzó cuando comenzamos a mostrar el progreso al cliente e implementar sus comentarios. Lo que comenzó como un equipo de tres personas sintió instantáneamente que había sido llevado a un nuevo orden de magnitud: no estaba claro quién era responsable de qué parte de la retroalimentación, cuál era el estado de implementación de esa retroalimentación, o incluso quién estaba hablando con quién. . ¡Excedimos varias veces el límite de Gmail de 100 respuestas por conversación!

Las cosas empezaron a ponerse incómodas. Creo que el cliente sintió que había perdido el control de la dirección del proyecto e, igualmente importante, sintió que había perdido la visibilidad del estado del proyecto. Mi desarrollador de Amazon mencionó un día: "Me pregunto si deberíamos usar Trello".

Eh , pensé. ¿Un equipo de tres personas necesita una plataforma como esa? Una vez más, mi tendencia habitual es preferir menos herramientas, menos gastos generales, menos complejidad. Pero el proyecto ya nos estaba arrastrando a todos a la tierra, entonces, ¿cuál era el daño en intentarlo?

Revisé todos nuestros correos electrónicos, todos nuestros documentos de especificaciones, todos nuestros hilos de comentarios dispares, y los mapeé en los tableros de Trello. Inmediatamente, el proyecto resucitó de su tumba digital porque podíamos comunicarnos con mucha menos sobrecarga mental. En lugar de buscar texto en la bandeja de entrada de mi correo electrónico o en un documento de especificaciones en su mayoría obsoleto, teníamos hermosos tableros, listas y tarjetas. Era fácil ver el estado de cualquier función, incorporar comentarios y repartir nuevas tareas. Se sentía como si nos hubiéramos quedado ciegos gradualmente, tan lentamente que no nos dimos cuenta, y luego de repente pudimos ver de nuevo.

Por supuesto, el código no se escribió solo, aún era un proyecto muy desafiante y aún teníamos que emplear cada gramo de nuestra habilidad técnica. Pero ese es el punto: debido a que finalmente teníamos una infraestructura para comprender el proyecto, ahora teníamos la libertad de aplicar nuestra habilidad técnica.

Me complace decir que ese proyecto se completó a plena satisfacción del cliente. Hoy en día, considero que Trello o Jira son un requisito de facto para equipos de dos o más.

Avanza y aprende de los errores de los demás

Esta es una de las cosas más inteligentes que escuché enseñar durante mi tiempo en el ejército: “Está bien que los tenientes cometan errores de tenientes y está bien que los capitanes cometan errores de capitanes. Lo que no está bien es que los capitanes cometan errores de tenientes, o que los tenientes cometan errores privados”.

En otras palabras, está bien cometer los errores comunes que son normales para su nivel actual de responsabilidad. Lo que es más importante es cómo creces a partir de ellos.

Espero que nosotros, como desarrolladores, aprendamos a ser compasivos con los demás cuando cometen errores, como esperamos que otros hayan sido con nosotros. Espero seguir siendo curioso y responsable cuando cometo errores para seguir innovando y superarlos. Espero estar siempre rodeado de una comunidad inspiradora de expertos en WordPress, personas de cuyos errores pueda aprender y evitar cometerlos. Y no menos importante, espero que otros puedan aprender de mi experiencia, como los errores de WordPress que he compartido aquí.