[Escalado a 2º nivel] Consumo de memoria crítico en relación a volumen de posts e idiomas.

Hola Paola,

Reproducir el problema ha sido dificil, porque sólo lo veíamos en debug.log de WordPress pero no sabíamos de donde venía, pero si deseas verificarlo, solo visita:
enlace oculto
Y luego abres debug.log en el ftp (pesará muchisimo) y veras fatal error junto con el log custom que hemos añadido a WPML.

Analizando el stack trace del error, hemos identificado que el problema no es un conflicto genérico, sino un desbordamiento de memoria provocado específicamente por el addon WPML SEO (la extensión de compatibilidad para Yoast SEO) cuando se generan los sitemaps.

Para diagnosticarlo, hemos modificado el método set en sitepress-multilingual-cms/classes/utilities/class-wpml-wp-cache.php para monitorizar el crecimiento de la caché interna en tiempo real. Este es el código que hemos utilizado para capturar la traza:

public function set( $key, $data, $expire = 0 ) {
$keys = $this->get_keys();
if ( ! in_array( $key, $keys, true ) ) {
$key_log = is_scalar( $key ) ? (string) $key : wp_json_encode( $key );
$group_log = is_scalar( $this->group ) ? (string) $this->group : wp_json_encode( $this->group );
$trace = function_exists( 'wp_debug_backtrace_summary' )
? wp_debug_backtrace_summary( null, 0, false )
: '';

if ( ! is_string( $trace ) ) {
$trace = wp_json_encode( $trace );
}

error_log( sprintf(
'WPML cache grow group=%s count=%d key=%s trace=%s',
$group_log,
count( $keys ),
$key_log,
$trace
) );
$keys[] = $key;
wp_cache_set( self::KEYS, $keys, $this->group );
}
return wp_cache_set( $key, [ 'data' => $data ], $this->group, $expire );
}

Resultados del Log custom que hemos añadido:
Al intentar cargar el sitemap, el grupo de caché convert_url crece de forma masiva. Justo antes de alcanzar el límite de 1GB de RAM, el log registra lo siguiente:

WPML cache grow group=convert_url count=72213 key=d632ebd9dd4ce884d03e9dcc3e2e7e93 trace=["WPML_WP_Cache->set","WPML_URL_Cached_Converter->convert_url","WPML_URL_Filters->home_url_filter","WP_Hook->apply_filters","apply_filters('home_url')","get_home_url","home_url","get_permalink","WPML\\WPSEO\\Shared\\Sitemap\\BaseAlternateLangHooks->WPML\\WPSEO\\Shared\\Sitemap\\{closure}","array_map","WPML\\Collect\\Support\\Collection->map","WPML\\WPSEO\\Shared\\Sitemap\\BaseAlternateLangHooks->addAlternateLangData","WP_Hook->apply_filters","apply_filters('wpseo_sitemap_entry')","WPSEO_Post_Type_Sitemap_Provider->get_sitemap_links","WPSEO_Sitemaps->build_sitemap"]

Nuestra conclusión:
La traza indica que la función addAlternateLangData de WPML SEO entra en un bucle para procesar los 43 idiomas de cada entrada del sitemap. Esto provoca que WPML_URL_Cached_Converter intente almacenar decenas de miles de URLs en el array global de caché de PHP en una sola ejecución, disparando el Fatal Error.

Consultas para el equipo de Nivel 2:

¿Cómo podemos limitar el crecimiento del grupo convert_url en procesos pesados como la generación de sitemaps?

Dado que tenemos 43 idiomas, ¿existe alguna forma de evitar que WPML SEO intente procesar todos los alternate lang de golpe en memoria?

¿Tenéis constancia de este comportamiento de "memory leak" por acumulación de caché en el addon WPML SEO al escalar a este número de idiomas?

Quedo a la espera de vuestro análisis para ver cómo proceder sin tener que asignar cantidades irreales de RAM (2GB+) por cada hilo de PHP.

Un saludo.