[Resuelto] Problema con redireccion a idioma secundario en post personalizado

Hola,

Los campos están habilitados.

Hola,

Hemos intentado reproducir el problema en múltiples ocasiones, tanto en un entorno local como en la copia en staging, pero no hemos podido replicarlo. En la versión de staging no se ha presentado el fallo, lo que podría indicar que está relacionado con condiciones específicas del entorno en producción, como el tráfico real, la configuración del servidor o algún sistema de caché/CDN.

En los registros que nos enviaste, se confirma que la redirección es ejecutada por WordPress, pero no contamos con suficiente información para identificar la causa exacta. Dado que el problema ocurre de forma intermitente, seguimos sin un patrón claro que nos permita reproducirlo bajo control.

Te sugerimos:

1. Confirmar que en Yoast SEO no esté habilitada la opción de eliminar el slug del tipo de contenido.

Lo lamento, pero no tenemos nuevas sugerencias o información.

Hola,

Gracias por tu paciencia durante toda esta investigación. Sabemos que este problema ha sido difícil de reproducir y ha requerido mucho tiempo, tanto de tu parte como de la nuestra.

Después de varios intentos, finalmente pudimos reproducir el comportamiento inesperado en la página de listado enlace oculto
, especialmente al filtrar por salas y cambiar el idioma repetidamente. Esta fue una pista clave para entender lo que está ocurriendo.

El problema parece estar relacionado con una lógica personalizada en el código del tema, donde se utiliza la constante ICL_LANGUAGE_CODE para modificar enlaces dependiendo del idioma activo. El inconveniente es que esta constante se define más tarde en el flujo de ejecución de WordPress, y en ciertos casos, cuando ya se ha generado el enlace con el slug correcto (/salas/), el código aún considera que el idioma activo es "en", y reemplaza incorrectamente el slug por /room/. Esto termina generando URLs mal formadas y, en consecuencia, errores 404.

El enfoque actual, que consiste en modificar manualmente los permalinks usando str_replace, es bastante frágil. Funciona en la mayoría de los casos, pero no es confiable, ya que depende de un orden de ejecución muy específico que puede variar según la carga del servidor o la secuencia de acciones del usuario. Por esa razón, y aunque comprendemos que esta lógica se ha implementado con una intención clara, no es una solución robusta.

Ejemplo:

		foreach ($salas as $auxsalas) { 
			$auxlink = get_the_permalink($auxsalas->ID);
			switch (ICL_LANGUAGE_CODE){
				case 'es':
					$auxlink = str_replace('/room/','/salas/',$auxlink);
					break;
				case 'en':
					$auxlink = str_replace('/salas/','/room/',$auxlink);						
				break;
			}

Dado que este comportamiento depende completamente de código personalizado, lamentablemente se encuentra fuera del alcance del soporte de WPML. Aun así, queremos ayudarte a resolverlo de la mejor forma posible. Nuestra recomendación es que no se manipulen directamente los slugs dentro de los permalinks. En lugar de depender de ICL_LANGUAGE_CODE, sugerimos utilizar el filtro wpml_current_language, que es más seguro y confiable en este tipo de escenarios: https://wpml.org/wpml-hook/wpml_current_language/
.

Un saludo cordial,
Lucas

Hola,

como mi compañero Lucas no está disponible en este momento, soy yo quien te escribe hoy.

Hemos revisado tu código y nos preguntamos por qué manipulas las URLs de esa manera, cuando en realidad WPML gestiona automáticamente los slugs traducidos al obtener el permalink.

Veamos también el caso del tipo de contenido "salas": dado que el slug del tipo de contenido es salas, no esperaríamos verlo en WPML > Ajustes para este tipo de contenido. ¿Por qué no registrar simplemente el tipo de contenido con su slug en español (salas) y usar los ajustes de WPML para traducirlo a room en inglés, dejando que WPML maneje las URLs de forma normal?

Parece que estás duplicando parte del trabajo que WPML ya hace mediante código personalizado, lo cual está generando efectos secundarios no deseados.

Saludos,
Marcel

Hola,

Gracias por esperar. Si esto está ocurriendo en tu sitio en vivo, no hay ningún problema. Fue simplemente algo que el segundo nivel notó y nos llamó la atención.

Déjame explicarte: no ofrecemos soporte para código personalizado – esto se debe a que WPML no está funcionando incorrectamente; de hecho, lo que causa el problema es el código y no algo ofrecido por nosotros. En este caso, como se trata de código personalizado, puedes proceder de la siguiente manera:

1. Primero, intenta reproducir el comportamiento en el sitio en vivo. Visita la página enlace oculto y cambia de idioma varias veces hasta que ocurra el error (puede que no ocurra, ya que es una incidencia rara y depende del ciclo de vida).

2. Si logras reproducirlo, elimina el código que modifica el slug y vuelve a intentarlo. Así podrás identificar qué parte del código está causando el problema.

3. Si no consigues reproducir el error en el paso #01, elimina el código y continúa analizando los registros (logs).

Lo que ofrecemos es solo una recomendación. Como se trata de código personalizado y el problema ocurre de forma rara, será necesario que hagas los ajustes tú mismo (o tu desarrollador), o elimines el código completamente. WPML gestiona los slugs automáticamente. Tal vez puedes remover el codigo y ver si es que de verdad hace algo que ya WPML u otros plugins del sitio no lo hacen por default.