♻️ Maximizando la compatibilidad PHP para WordPress 6.4 y el directorio de plugins
Se ha lanzado WordPress 6.4 "Shirley". Se recomienda ejecutarlo usando PHP 8.1 o 8.2, pero la versión mínima soportada de PHP sigue siendo 7.0.
Por lo tanto, nuestros plugins de WordPress necesitan (tanto como sea posible) soportar PHP hasta 7.0, y ser compatibles con PHP 8.1 y 8.2.
La forma más lógica de hacerlo es programar nuestros plugins usando PHP 7.0, mientras:
- No usamos características que han sido deprecadas en PHP 7.x, ya que esas se habrán eliminado en PHP 8.x
- No usamos características que han sido deprecadas en PHP 8.x, ya que estas lanzarán warnings
Para asegurarnos de que el código del plugin es compatible, necesitamos probarlo a fondo en varios entornos, ejecutando las distintas versiones de PHP.
Programar en PHP 7.x tiene una clara desventaja: El código del plugin debe ser compatible con PHP 8.x, sin embargo no puede usar ninguna de sus características, como union types, la expresión match, el operador nullsafe, y muchas otras.
Hay una alternativa mejor.
Hacer downgrade del código PHP de 8.x a 7.x
En lugar de programar en PHP 7 y asegurarnos de que funciona con PHP 8, podemos hacer lo inverso: Programar el plugin en PHP 8, y hacer downgrade a PHP 7.
Esto es posible gracias a Rector, una herramienta para automatizar el refactoring del código PHP.
Rector proporciona reglas para hacer downgrade de código desde PHP 8.1 a PHP 7.2. Esto significa que podemos usar estas características modernas en nuestros plugins de WordPress, ya que estas pueden degradarse a código PHP 7.2.
Por ejemplo, la regla DowngradeMatchToSwitchRector convierte el operador match en un operador switch:
class SomeClass
{
public function run()
{
- $message = match ($statusCode) {
- 200, 300 => null,
- 400 => 'not found',
- default => 'unknown status code',
- };
+ switch ($statusCode) {
+ case 200:
+ case 300:
+ $message = null;
+ break;
+ case 400:
+ $message = 'not found';
+ break;
+ default:
+ $message = 'unknown status code';
+ break;
+ }
}
}Fíjate que las reglas solo sirven para hacer downgrade hasta PHP 7.2, no hasta PHP 7.1 y 7.0. Sin embargo, esto no es un gran problema, ya que estas dos versiones de PHP combinadas representan solo el 3 % de los sitios WordPress.
Hacer downgrade del código es un mejor enfoque, porque:
- Al programar en PHP 8.1, estamos absolutamente seguros de que nuestro código será compatible con PHP 8.1 y 8.2.
- Siempre que usemos características PHP para las que existan reglas de downgrade, el código también funcionará en PHP 7.2, 7.3 y 7.4.
- Podemos hacer uso de las características de PHP 8.x, como union types, la expresión match, el operador nullsafe, y muchas otras.
Fíjate que no todas las características de PHP 8.x están disponibles. Por ejemplo, no hay regla (aún) para hacer downgrade de enumerations, por lo tanto no podemos usarlas.
Respecto a las pruebas, no hay diferencia: También debemos probar a fondo el plugin en varios entornos, ejecutando las distintas versiones de PHP, para estar del lado seguro.
Cómo hacer downgrade del código
Gato GraphQL se desarrolla con PHP 8.1, y se degrada a PHP 7.2 para producción.
Hacer downgrade del código y probarlo, y luego lanzar el plugin para producción, está todo automatizado vía workflows de GitHub Actions:
downgrade_php_tests.yml: Hace downgrade del código y lo analiza usando PHP 7.2generate_plugins.yml: Genera el plugin para release, haciéndole downgrade a PHP 7.2integration_tests.yml: Instala el plugin recién generado en un conjunto de instancias de InstaWP ejecutando distintas versiones de PHP, y ejecuta tests de integración
Para saber más, he escrito unos cuantos artículos sobre este tema:
- 🦸🏿♂️ Gato GraphQL ahora se transpila de PHP 8.0 a 7.1
- Transpiling PHP code from 8.0 to 7.x via Rector
- Coding in PHP 7.4 and deploying to 7.1 via Rector and GitHub Actions
Espero que te resulte útil 🙏