En noviembre del año pasado aterrizó PHP 8. Anunciaba algunas mejoras en rendimiento, velocidad y seguridad.
Como todo buen trasteador, corrí a actualizar desde 7.4, concretamente desde 7.4.16, versión que corre ahora en el servidor.
¡Plof! un bonito error 500 me recibe y rompe todo el sitio. Ninguna URL resuelve.
Hice la típica prueba de desactivar todos los plugins y usar plantilla por defecto. El error 500 no se marchaba.
Me escamó, pero pasé del asunto convencido de que aún era pronto para actualizar y, tal y como aconsejaban, lo suyo era esperar a que todos los autores de plugins y plantillas actualizaran su código para hacerlo compatible con PHP 8.
Casi siete meses después volví a intentarlo y el error 500 seguía allí.
La primera pista de que el origen del error está solo en este blog es que en las otras dos instalaciones de WordPress que tengo en el mismo servidor todo funciona correctamente.
Como un error 500 puede aparecer por un montón de historias. El siguiente paso lógico es tirar de los logs de error para intentar saber a qué hay meterle mano. Aparece una ristra de avisos como este :
PHP Warning: Use of undefined constant minor – assumed ‘minor’ (this will throw an Error in a future version of PHP) in /home/xxxxxx/public_html/blog/wp-config.php on line 11
Advertencia de PHP: Uso de la constante indefinida minor - asumida 'minor' (esto arrojará un error en una futura versión de PHP).
Es decir, que se supone que la constante debe llevar comillas. Acudo a wp-config.php y efectivamente, minor aparece sin comillas en esa línea.
define (‘WP_AUTO_UPDATE_CORE’, minor);
Rebuscando en el foro de WordPress encuentro que mucha gente ha tenido este mismo problema actualizando también a versiones anteriores de PHP por conflictos con algún plugin o plantilla.
Tampoco se puede descartar que la movida esté relacionada con la instalación de WordPress que tenga algo escacharrado como me comentaron en su día en un ticket que envié a LucusHost.
En algunas de las respuestas que reciben, se dice que para solucionar el problema basta con añadir las comillas a 'minor', así que por probar no se pierde nada y eso hago-
define (‘WP_AUTO_UPDATE_CORE’, ‘minor’);
WP_AUTO_UPDATE_CORE permite controlar las actualizaciones del núcleo de WordPress para versiones menores, mayores y de desarrollo. Esta constante puede definirse de varias formas. Eliminar esta línea no es buena idea.
#Disables all core updates:
define( ‘WP_AUTO_UPDATE_CORE’, false );
# Enable all updates, including minor and major updates:
define( ‘WP_AUTO_UPDATE_CORE’, true );
# Enables minor updates:
define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );
Una buena noticia y una mala.
La buena es que ahora, corriendo PHP 8, desaparece el error 500.
Todo parece funcionar bien a primera vista, tanto los plugins como los post.
La mala es que se rompe el index y presenta este aspecto.
Decidí atacar primero la plantilla de entradas, hecha con Elementor Pro, por si el builder había dejado alguna basurilla oculta, pero tras repasarla y rehacerla por completo he descartado que el error venga de ahí.
Ahora sigo expurgando la plantilla (GeneratePress Premium) en un entorno de pruebas y al menos sé en qué punto rompe, pero sobre todo busco en WordPress, que es donde creo que está el meollo de la cuestión, algún código rancio arrastrado, algún filtro atascado de grasa o lo que sea.
Dejo esta nota por aquí por si alguien ha tenido un problema parecido y le sirve de algo o le sirve lo escrito aquí o bien sabe la hostia de WP y puede aportar alguna pista más para solucionarlo.
En cuanto encuentre el apaño definitivo y la posible explicación, actualizaré esta entrada.
Actualización
El log de errores, tras activar el DEBUG, da pistas de que GeneratePress está cascando por algún sitio, puede que por algún gancho o filtro que coloqué en su módulo de Elements (o yo qué sé).
Al tener una plantilla hijo (child) de GeneratePress ya me he perdido del todo y no sé bien por dónde seguir, pero como tengo un par de sospechas aún no doy por fracasada la misión.
Fatal error: Uncaught TypeError: Unsupported operand types: string + int in /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169 Stack trace: #0
/home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php(419): generate_do_post_meta_item() #1
/home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php(538): generate_posted_on() #2
/home/ public_html/blog/wp-includes/class-wp-hook.php(292): generate_post_meta() #3
/home/ public_html/blog/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters() #4
/blog/wp-includes/plugin.php(484): WP_Hook->do_action() #5
/blog/wp-content/themes/generatepress/content.php(48): do_action() #6
/blog/wp-includes/template.php(732): require('/home/ ...') #7
/blog/wp-includes/template.php(676): load_template() #8
/blog/wp-includes/general-template.php(204): locate_template() #9
/blog/wp-content/themes/generatepress/inc/theme-functions.php(587): get_template_part() #10
/blog/wp-content/themes/generatepress/index.php(37): generate_do_template_part() #11
/blog/wp-includes/template-loader.php(106): include('/home/ ...') #12
/blog/wp-blog-header.php(19): require_once('/home/ ...') #13
/blog/index.php(17): require('/home/ ...') #14
{main} thrown in /blog/wp-content/themes/generatepress/inc/structure/post-meta.php on line 169
¡Arreglado! Bueno, casi
Afortunadamente la primera línea era la clave, de ahí se desencadenaban todos los errores de esa larga lista:
Fatal error: Uncaught TypeError: Unsupported operand types: string + int in /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169
El misterio del error estaba en alguna operación no soportada del maldito get_the_time.
Atando cabos, se confirman las sospechas. El error lo provocaba este snippet de función que usaba para mostrar el día y hora de actualización como extensión de los meta en la fecha.
Para colmo, no sé cómo, pero se quedaba residente tras desactivar Code Snippets y vaciar caché.
Moraleja, no hay que usar funciones que a otros les rulan bien porque cada página tiene sus historias particulares y es muy probable que terminen estropiciando algo si las olvidas, se actualiza WP, PHP, una plantilla o plugin y dejan de ser compatibles.
Al eliminar este snippet todo funciona bien y el home vuelve a aparecer sano y salvo.
No hay dos sin tres, otro error. Ahora Feedzy
Pero no se vayan todavía, que ahora el plugin Feedzy (supongo) o algo relacionado rompe la página de noticias.
Toca abrir un ticket de soporte, ya que se trata de una versión de pago, para avisar a los desarrolladores del plugin para saber si es 100% compatible con PHP 8 (y si rompe por no serlo) o para que me den alguna pista.
02/07/2021 - Feedly ha replicado el error fatal usando PHP 8 y ha trasladado el problema a sus desarrolladores, ahora hay que esperar a que publiquen una nueva versión del plugin que solucione el problema.
05/07/2021- Ya está la descripción del bug en su Github.
06/07/2021 - Aunque aún no han contestado ni lanzado una nueva versión con el arreglo, en este commit ya están las líneas de código que lo solucionan. Lo he probado y, a falta de trastear todo bien y a fondo, parece que PHP 8 ya no rompe nada.
Recapitulando
No está mal. De tener un error 500 que rompía todo el blog a pasar a tenerlo tenerlo sólo en el home y finalmente en una sóla página "secundaria" para terminar encontrando apaño es suficiente para darme por satisfecho por las horas invertidas en la reparación.
La clave de todo está en las pesquisas, dedica todo tu tiempo a buscar el origen y lo que provoca en otras partes de tu blog. No te lances a probar arreglos rápidos sin las pistas suficientes porque perderás el tiempo o, a las malas, romperás otra cosa.
Volveré a actualizar cuando consiga vencer al nuevo error con Feedzy o lo que carajo sea esta vez.
