Un usuario preguntó 👇
Hola, no estoy seguro de si ese problema está resuelto, pero ocurre con demasiada frecuencia en las instalaciones que administro.
El caso: el WP original se instaló hace algún tiempo en una base de datos con soporte para utf8mb4 y utf8mb4_unicode_general_ci.
La coordenada (DB_COLLATE) la establece ese blog en un cable vacío.
Una vez que el proveedor actualiza la base de datos, si se instalan nuevos plugins, sus tablas (usan la variable $ charset_collate) se crean con utf8mb4_unicode_520_ci, pero las tablas WP estándar NO se actualizan para esa coordinación. Entonces, todas las posibles devoluciones de SQL utilizan campos de texto de coincidencia de errores.
¿No sería una buena opción, cuando no se especifica la garantía, si WP cambia sus propias tablas? De lo contrario, existe incluso una discrepancia entre la garantía devuelta por $ wpdb y la tabla real.
Para un caso específico, una nueva instalación de WooCommerce tiene todas las tablas (extra) con 520 colesterol y el blog tiene coordinación general.
Gracias, Stefano.
(@pento)
Hace 2 años, 1 mes
¡Gracias por la sugerencia, @satollo! Abrí un ticket para investigarlo más, creo que podemos hacer que la situación que estás describiendo sea mucho más indulgente. 🙂
Sería muy útil si pudiera escribir sobre su experiencia actual en el ticket: ¿qué tamaño de tablas necesita convertir y cuánto tiempo lleva? ¿Qué versiones de MySQL está actualizando desde / hacia? ¿Existen plugins específicos que generan estos fallos? JOIN Preguntas?
(@satollo)
Hace 2 años, 1 mes
Hola, el plugin es un componente comercial que genera el error, por lo que no está disponible en el repositorio de WP.org, pero es compatible con la tabla de publicaciones (para el tipo de publicación del producto WooCommerce) y una tabla personalizada de WooCommerce con metadatos de elementos ordenados. .
Intentaré eliminar la consulta exacta, sin embargo, la discrepancia colateral es el valor meta de los elementos ordenados que está conectado con la coordenada unicode_520.
Quiero profundizar en este blog para entender el caso general del mismo. Parece que el wp-config.php estándar que contiene utf-8 por defecto como juego de caracteres y cadena vacía para la compilación, podría generarlo cuando se actualice la versión de mysql y posteriormente instalar un nuevo plugin que cree sus propias tablas.
Una pregunta: ¿no debería WP cambiar todas las tablas a la coordenada unicode_520 cuando detecta soporte para esa función? ¿Como el antiguo «maybe_convert_to_utf8mb4 ()»?
Alternativamente, el wp-config.php, cuando se crea, podría completarse con la primera coordenada de instalación seleccionada para mantenerlo estático.
Gracias, Stefano.
¿Solucionó tu problema??
0 / 0