PHP 8.2: ¿Qué significa para WordPress, complementos y desarrolladores?

Publicado: 2022-12-14

PHP 8.2.0 hizo su debut el 8 de diciembre de 2022. Como una actualización importante, trae mejoras de rendimiento, una sintaxis más simple y una mayor seguridad de tipos con nulo , falso y verdadero como tipos independientes. Uno de los mayores cambios que probablemente desafiará a los desarrolladores de WordPress es la introducción de clases de solo lectura , que no permiten propiedades dinámicas.

Las propiedades dinámicas están obsoletas y producirán un error fatal en PHP 9 o posiblemente en PHP 10. Si bien es potencialmente doloroso, especialmente para el núcleo de WordPress, la obsolescencia es una característica clave y un regalo para los desarrolladores de PHP.

Echemos un vistazo a la evolución reciente de PHP y también cómo los desarrolladores de WordPress mantienen la compatibilidad con versiones anteriores mientras aprovechan las nuevas características cuando más beneficiarán a los usuarios finales.

Mantenerse al día con el desarrollo de PHP en WordPress

Debido a que el núcleo de WordPress mantiene una importante compatibilidad con versiones anteriores sin fechas planificadas de fin de vida cuando las versiones anteriores no serán compatibles, corresponde a las empresas de WordPress determinar su propio ciclo de vida del producto o servicio y las versiones de PHP que admitirán.

A diferencia de WooCommerce, que requiere un mínimo de PHP 7.4, el núcleo de WordPress actualmente solo recomienda PHP 7.4 o superior. “También funciona con” PHP 5.6.20, que llegó a su fecha de finalización a fines de 2018. El proyecto de WordPress señala esto y advierte que el uso de versiones de PHP no compatibles “puede exponer su sitio a vulnerabilidades de seguridad”. (Requisitos de WordPress.org)

Afortunadamente, solo el 5,1% de todos los sitios de WordPress actualmente usan PHP 5.6, y solo el 2% usa una versión aún más antigua. El 20% usa PHP 7.0 a 7.3, y el grupo más grande (56.7%) usa PHP 7.4. (Estadísticas de WordPress.org)

Desafortunadamente, PHP 7.4 acaba de llegar a su fecha de EOL a fines de noviembre de 2022. A PHP 8.0 le queda menos de un año para su soporte de seguridad oficial durante la mayor parte de 2023. La versión actual y con soporte activo, PHP 8.1, vencerá al final. de 2024. PHP 8.2, que acaba de tener su primera versión estable, tendrá soporte de seguridad hasta diciembre de 2025.

Este es un ciclo de lanzamiento rápido, y no sorprende que el ecosistema de WordPress luche por mantenerse al día. Con más de la mitad de la web ejecutándose en WordPress, es un gran barco que no puede girar rápidamente. Es mucho más un acto de equilibrio que una carrera hacia la vanguardia. Sin embargo, el salto a PHP 8 tiene muchos beneficios, con grandes funciones que mejoran el rendimiento, como la compilación PHP Just-in-Time (JIT) en tiempo de ejecución para una ejecución más rápida con menos uso de memoria.

La compensación entre retrocompatibilidad y estabilidad, visión de futuro e innovación

La compensación entre atender a la audiencia más amplia posible de usuarios y mantener la vigencia con PHP siempre ha planteado un dilema para los desarrolladores, hosts y empresas de productos de WordPress. Las agencias y los autónomos con clientes a largo plazo y sitios heredados enfrentan el mismo problema: la actualización de los requisitos mínimos puede obligar a los clientes existentes a realizar cambios significativos en sus sitios o ver cómo se rompen.

Por un lado, los beneficios de mantenerse actualizado con PHP son seguridad y rendimiento mejorados y los últimos conceptos y capacidades de programación para desarrolladores. Por otro lado, el principal beneficio de retrasar el PHP mínimo requerido es una base de clientes feliz (aunque complaciente) y amplia. Es una situación de "págame ahora o págame después". En algún momento, tienes que arrancarte la tirita.

Los buenos datos y la telemetría sobre los entornos de los usuarios pueden ayudar a determinar el momento menos disruptivo para aumentar el requisito mínimo de versión de PHP. La mayoría de los desarrolladores de complementos vigilan esos números con sus propias herramientas, ya que no forman parte de los datos de instalación activa del repositorio de complementos de WordPress.org. Inevitablemente, se garantiza que cualquier cambio potencialmente importante que afecte a muchas personas dará como resultado una avalancha de tickets de soporte.

Priorizar la compatibilidad con versiones anteriores también implica un alto trabajo de mantenimiento. La compatibilidad con una base de usuarios muy grande y diversa es excelente para el usuario final, pero significa que los desarrolladores deben mantener su código funcionando en muchos entornos diferentes. "Me encanta admitir versiones anteriores de PHP a medida que se agregan nuevas funciones", dijo ningún desarrollador, ¡nunca!

No solo tienen que preocuparse por el PHP heredado, sino también por las bases de datos heredadas y docenas de otras variaciones en la pila de WordPress. Los casos extremos surgen y confunden incluso a los expertos cuando existe un amplio espectro de entornos de servidor de WordPress con elementos obsoletos.

El mejor momento para aumentar su requisito mínimo de PHP

El lanzamiento de iThemes Security Pro 7.2 es un buen ejemplo de cómo aumentar el requisito mínimo de PHP de un producto de WordPress para brindar innovación y estabilidad a los clientes existentes.

A partir del lanzamiento de la versión 7.2, iThemes Security Pro requiere PHP 7.3 o superior y admite hasta 8.1. La decisión de actualizar el requisito de PHP para iThemes Security Pro se tomó para implementar el marco WebAuthn. La implementación requería bibliotecas que necesitan PHP 7.3+ para administrar el cifrado y las claves públicas. Las funciones de inicio de sesión 2FA, clave de paso y biométrica introducidas en iThemes Security Pro 7.2 son el resultado directo de esta decisión. En un momento en que sus contraseñas claras están rotas, el equipo de seguridad de iThemes trajo el inicio de sesión sin contraseña a WordPress por primera vez como la experiencia de autenticación de usuario principal.

Habría sido posible crear estas funciones reescribiendo las bibliotecas de WebAuthn para que sean compatibles con versiones anteriores de PHP. Por supuesto, eso sería mucho más trabajo y crearía código adicional para mantener. Lo más inteligente fue mantenerse al día con la comunidad de PHP a un ritmo moderado mediante la adopción de dependencias que requieren PHP 7.3 o superior. La mayoría de sus usuarios ya estaban allí. Es por eso que el equipo de desarrollo de iThemes Security decidió aumentar el requisito mínimo de PHP para usuarios nuevos y existentes.

Para los productos de WordPress que están fuertemente invertidos en el editor de bloques de Gutenberg, como GiveWP, administrar el cambio puede ser aún más desafiante. La estabilidad y la lenta tasa de cambio en el núcleo de WordPress pueden ser frustrantes para los desarrolladores PHP de back-end, pero está permitiendo que los desarrolladores de JavaScript/React de front-end impulsen la plataforma.

Jason Adams, gerente de desarrollo de GiveWP, señala que no tienen que ser compatibles con versiones anteriores porque pueden migrar usuarios entre versiones a medida que evoluciona el editor del sitio. Sin embargo, “no existe tal cosa como una migración para PHP”, comentó. Eventualmente, tendrán que adaptarse a la arquitectura de PHP 9 y alejarse de las nuevas características obsoletas de PHP 8.2.

No existe un único "momento adecuado" para que todos los productos del ecosistema de WordPress actualicen los requisitos mínimos de PHP. “No es un problema que puedas resolver filosóficamente”, me dijo Adams. Realmente depende de un criterio basado en cuántos usuarios se verán afectados negativamente por el cambio. Si el 90% o más están en PHP 7.2 o 7.4, es viable aumentar el requisito mínimo a ese nivel.

Esos números pueden variar ampliamente según la base de usuarios específica de un producto, dice Adams. Un producto utilizado por clientes con más conocimientos técnicos tenderá a estar más cerca de las versiones de PHP compatibles actualmente. Un producto como GiveWP, con muchas organizaciones sin fines de lucro que lo utilizan, deberá poner más peso en la compatibilidad con versiones anteriores. Otra forma de avanzar es dejar que el código heredado y sus usuarios se ramifiquen en una versión a largo plazo que será compatible pero que no agregará nuevas funciones. Cuando los usuarios estén listos para realizar la actualización, podrían migrar a una nueva versión principal creada para compatibilidad con PHP en el futuro.

Los avisos de obsolescencia impulsan el desarrollo

WordPress.com acaba de implementar PHP 8.2 como una opción para sus planes Business y Ecommerce con funciones de alojamiento activadas, y en el ecosistema de WordPress.org, es poco probable que un código antiguo razonablemente bien diseñado se rompa o se vuelva inseguro con la próxima versión importante de PHP. liberar. Aunque el código base principal de WordPress.org ofrece oficialmente solo soporte "beta" para PHP 8.0, generalmente funciona bien con las últimas versiones de PHP, al igual que los complementos bien compatibles. No arrojarán errores fatales o de análisis. Ni siquiera debería ver muchas advertencias con la depuración activada. Es posible que vea muchos avisos de funciones obsoletas, que aún no son errores.

Las frustraciones de un ciclo rápido de lanzamiento de PHP tienen mucho que ver con los desarrolladores que se atascan en la maleza al refactorizar su código y ponerse al día con los aspectos obsoletos de PHP. Este trabajo crítico puede dejarles menos tiempo para explorar e innovar con nuevos conceptos y capacidades que trae la última versión de PHP.

Hay otra forma de ver esta situación. Tratar con las funciones obsoletas de PHP es en realidad una visión de futuro y obliga a los desarrolladores a dominar las próximas iteraciones de un lenguaje en evolución. Sin este ejercicio algo forzado, el conocimiento existente se asentaría más fácilmente en viejos hábitos que se volverán malos cuando sean obsoletos.

Los avisos de obsolescencia señalan cosas que funcionan ahora pero que fallarán en futuras versiones de PHP. Esto es bueno para ti si eres un desarrollador, como explica Brent Roose. Si los desarrolladores prestan atención a esos avisos, tendrán mucho tiempo para controlar cualquier código obsoleto. Y no debería ser un obstáculo para las actualizaciones de versiones menores.

Timothy Jacobs, desarrollador líder de seguridad de iThemes y responsable principal de WordPress, dice que es bueno tener advertencias de obsolescencia. Impulsan a los desarrolladores para que adopten un código "más correcto" y "menos frágil" que será cada vez más seguro, eficaz, a prueba de errores y más capaz de hacer frente a los casos extremos. En esta vista, los avisos E_DEPRECATED que llenan su registro de errores son "como un sistema de alerta temprana de que las cosas se romperán en el futuro, pero no están rotas ahora".

Prescindir de las propiedades dinámicas después de PHP 8.2

La justificación de Nikita Popov para eliminar gradualmente las propiedades dinámicas en PHP 9 es un buen ejemplo del impulso evolutivo de PHP hacia un código y convenciones de programación más resistentes:

La motivación de este cambio es doble: para evitar errores (debido a errores tipográficos o cambios de nombre) en el caso común, y para hacer explícitos los usos intencionales. El problema central es que la lectura de una propiedad inexistente emite un diagnóstico que hace que el problema sea evidente de inmediato, mientras que la escritura en una propiedad inexistente es completamente silenciosa. PHP no da ninguna indicación de que el programador haya cometido un error.

El video de dos minutos de Brent Roose sobre la evolución de PHP 5.6 a 8.2 es una ilustración visual brillante y simple de cuán lejos ha llegado PHP desde 2014 hasta el presente. Usando el ejemplo de un objeto de transferencia de datos simple, Roose muestra cómo el código PHP 5.6 se reduce drásticamente a un bloque de código mucho más simple, más delgado y, en general, más elegante en el camino a PHP 8.2.

Como señala Roose en sus consejos para lidiar con las propiedades dinámicas (que están en desuso en PHP 8.2), los desarrolladores deberían tener suficiente espacio para actualizar su código existente antes de que las advertencias de desuso se conviertan en errores fatales. Sin embargo, esa pista disminuirá rápidamente y WordPress es un caso especial. Tonya Mork tiene una propuesta aceptada en Trac para manejar las depreciaciones de propiedades dinámicas desconocidas en el núcleo de WordPress. A ella y a Juliette Reinders Folmer les preocupa que los desarrolladores de WordPress no tengan suficiente tiempo para refactorizar su código, sin mencionar los desafíos especiales de mantener la compatibilidad futura para un proyecto de veinte años. Mork, Reinders Folmer y Sergey Biryukov han sido los héroes en gran parte anónimos de esta tarea de enormes proporciones.

En su discusión sobre propiedades dinámicas y métodos mágicos en PHP 8.2, Mork y Reinders Folmer señalan que las raíces de WordPress en PHP 3 y 4 lo mantienen en un universo de programación sólidamente procedimental mientras que PHP continúa avanzando como un lenguaje orientado a objetos. Los desarrolladores principales deben encontrar una manera de mantener el comportamiento del código heredado en PHP actual sin romper la compatibilidad con versiones anteriores "y aún así hacer que el código sea mejor y más seguro y mitigar la desaprobación de las propiedades dinámicas de PHP 8.2", como dice Reinders Folmer. “De hecho, nos estamos haciendo la vida muy difícil con la regla de no [compatibilidad con versiones anteriores] de [WordPress Core]”, señala en el video.

“Hay una buena razón para ello”, responde Mork: “es para los usuarios. Los usuarios confían en que pueden presionar ese botón y actualizar, y que hemos pensado en la compatibilidad con versiones anteriores, que le hemos dado prioridad. Es una piedra angular para nosotros... para que los usuarios puedan tener la confianza de actualizarse”.

Todo Desarrollo es Mantenimiento…

Es un desafío único tratar de adaptar PHP "moderno" para que funcione con las dos versiones principales anteriores de PHP en aras de mantener la compatibilidad con versiones anteriores en el núcleo de WordPress. Los desarrolladores de complementos tienen una tarea mucho más fácil de actualizar su código de manera que puedan aprovechar las nuevas funciones, como las clases de solo lectura de PHP 8.2 y la desaprobación de propiedades dinámicas. Gran parte de este trabajo es en gran parte una forma de mantenimiento también.

Arquitectónicamente, los cambios de PHP 8+ se centran en conceptos de programación como la inmutabilidad. Las estructuras de datos inmutables "no solucionan inherentemente los problemas de seguridad", pero ayudan a que el código de los desarrolladores sea menos propenso a errores y más correcto, según Jacobs:

No diría que una estructura de datos inmutable es innatamente segura y una estructura de datos mutable es insegura. Más bien, las estructuras de datos inmutables pueden ayudar a eliminar los errores de programación que pueden generar problemas de seguridad. Al reducir la cantidad de estados diferentes en los que puede existir nuestro código, podemos reducir la complejidad de nuestro código y, por lo tanto, reducir las posibilidades de cometer errores.

La mejor razón para mantener el código en el estándar de las versiones de PHP con soporte activo es para reducir los riesgos de seguridad. PHP 8.2 trae comodidades útiles y "barandillas" en opinión de Adams, pero poco que entusiasmará a los programadores o se verá como un cambio de juego. Algo como el atributo #[\SensitiveParameter] podría ser más significativo desde el punto de vista práctico, ya que permite filtrar los datos confidenciales de los seguimientos de la pila que a menudo van a servicios de terceros. Introducidos en PHP 8, los atributos son la elección de Adams para la última innovación que le llamó la atención por permitir algo que no podía hacer antes: "describe algo [como clases, variables, métodos, etc.] desde una meta-perspectiva".

Aprovechar las nuevas funciones de PHP 8.0 a 8.2 y versiones futuras es donde la creatividad de los desarrolladores puede brillar, pero simplemente admitir esas versiones, para que los complementos y el núcleo de WordPress no se rompan, es práctico y vital.

…Y Todo Mantenimiento es Arte

Jeff Atwood tiene una publicación de blog antigua pero destacada titulada "El noble arte de la programación de mantenimiento" que leí recientemente, gracias al Hacker Newsletter de Kale Davis. “La programación de mantenimiento es ampliamente vista como un trabajo de limpieza”, escribe Atwood. Esto me recordó a la artista Mirele Laderman Ukeles, cuyo “Manifiesto de arte de mantenimiento” siempre me ha parecido muy relevante para la programación y el desarrollo web:

Dos sistemas básicos: Desarrollo y Mantenimiento. El amargo de toda revolución: después de la revolución, ¿quién va a recoger la basura el lunes por la mañana? […] Los sistemas de desarrollo son sistemas de retroalimentación parcial con gran espacio para el cambio. Los sistemas de mantenimiento son sistemas de retroalimentación directa con poco espacio para modificaciones.

Laderman Ukeles era una joven artista y madre primeriza en 1969 cuando escribió el manifiesto y declaró que el mantenimiento es arte. Estaba frustrada con la forma en que las obras de arte de vanguardia y el trabajo de alto nivel se separan del trabajo que los hace posibles: crianza de los hijos, enseñanza de habilidades y tradiciones artísticas, o simplemente montar un espectáculo de arte. Hizo una exhibición memorable basada en ella misma actuando como conserje de museo. Luego pasó la mayor parte de su carrera (en curso) como artista residente del Departamento de Saneamiento de la Ciudad de Nueva York. Su primer proyecto en ese puesto fue agradecer personalmente a los 8500 trabajadores sanitarios “por mantener vivo a Nueva York”.

Atwood tiene una visión similar de la programación. Cita a varias figuras importantes de la ingeniería de software que dicen que la denigración del trabajo de mantenimiento está mal. Robert L. Glass sintió que “el mantenimiento es un desafío intelectual importante, así como una solución y no un problema”, por lo que debe considerarse una tarea importante para las personas más capacitadas. Joel Spolsky escribió hace mucho tiempo que los desarrolladores son perezosos, y la razón por la que "siempre quieren tirar el código y empezar de nuevo" es que "es más difícil leer el código que escribirlo".

En una conversación con Andy Hunt, Dave Thomas argumentó: “Toda la programación es programación de mantenimiento porque rara vez se escribe código original. …. Pasa la mayor parte de su tiempo en modo de mantenimiento. Por lo tanto, también puede morder la bala y decir: "Estoy manteniendo desde el primer día". Las disciplinas que se aplican al mantenimiento deben aplicarse a nivel mundial”. Hunt estuvo de acuerdo: “Son solo los primeros 10 minutos que el código es original cuando lo escribes por primera vez. Eso es todo."

Atwood finalmente se inclina hacia este punto de vista, pero se hace eco de la perspectiva común de los desarrolladores de WordPress que escuché de Jason Adams y Timothy Jacobs. ¿El arte especial del desarrollo/mantenimiento de WordPress?

“Es un acto de equilibrio”.

¡El mejor complemento de seguridad de WordPress para asegurar y proteger WordPress ahora con un 35 % de descuento!

Actualmente, WordPress funciona en más del 40% de todos los sitios web, por lo que se ha convertido en un objetivo fácil para los piratas informáticos con intenciones maliciosas. El complemento iThemes Security Pro elimina las conjeturas de la seguridad de WordPress para que sea más fácil asegurar y proteger su sitio web de WordPress. Es como tener un experto en seguridad a tiempo completo en el personal que supervisa y protege constantemente su sitio de WordPress por usted.

¡Ahorra un 35% ahora!