Error en la base de datos de WordPress: La clave especificada era demasiado larga

Esto se ha resuelto en MM 2.2.7+.

Descargar la versión más reciente y aprenda a actualizar manualmente

Pregunta

Recibo este error de base de datos Error de la base de datos de WordPress La clave especificada era demasiado larga; la longitud máxima de la clave es de 767 bytes para la consulta...

Breve explicación del problema

Este problema se debe a la intercalación utilizada en las tablas de la base de datos, que está configurada como utf8mb4_unicode_ci o similar. El problema es que este estilo de intercalación restringe la longitud de las claves de las tablas de la base de datos, lo que provoca que algunas tablas de MemberMouse no se instalen durante la activación del complemento. 

Si revisas los registros de errores de tu base de datos verás reflejados estos errores de la siguiente manera:

Error en la base de datos de WordPress: [La clave especificada era demasiado larga; la longitud máxima de la clave es de 1000 bytes].

Como se puede imaginar, cuando faltan tablas en la base de datos, esto se manifestará de diferentes maneras dependiendo de las tablas que falten. En este caso, estás experimentando un problema al crear un producto que es específicamente el resultado de que la tabla mm_affiliate_providers no está instalada. 

Sin embargo, cuando se utiliza la intercalación utf8mb4_unicode_ci, la siguiente es la lista completa de tablas que no se instalarán:

mm_proveedores_afiliados

mm_comisiones_de_facturación_de_afiliados

mm_email_service_providers

mm_log_events

mm_social_login_linked_profiles

mm_stripe_customer_links

Pasos de la solución (siga estos pasos si acaba de empezar a utilizar MemberMouse)

Si está empezando y no tiene ningún dato en MemberMouse, o muy pocos, la forma más fácil y segura de solucionarlo es hacer lo siguiente: 

1. Siga los pasos para Desinstalar MemberMouse.

2. A través de phpMyAdmin, vaya a la base de datos que se está utilizando para la instalación de WordPress. Esta es la tabla de base de datos que aparece en su archivo wp-config.php.

3. Establecer la intercalación por defecto de la base de datos a utf8_unicode_ci

4. Realice una nueva instalación del plugin MemberMouse

A continuación, se habrán instalado todas las tablas MemberMouse.

Explicación avanzada del problema

Este problema está causado por una tormenta perfecta de condiciones que se juntan para crear un entorno de alojamiento incompatible con las versiones actuales de MemberMouse. Estas condiciones son muy técnicas y de bajo nivel, pero lo que sigue es una explicación de lo que está sucediendo junto con posibles soluciones.

La base de datos que está utilizando (y con la que MemberMouse está diseñado para ser compatible) es la base de datos MySQL. La base de datos MySQL puede configurarse con diferentes "motores de almacenamiento" que controlan cómo se almacenan y recuperan los datos. Cada motor tiene ciertas ventajas y desventajas, por lo que el mejor motor a utilizar en un entorno particular es muy subjetivo. El motor de almacenamiento que utiliza tu base de datos es InnoDB. Una de las desventajas del motor InnoDB es que tiene una longitud máxima de índice de 767 bytes, lo que normalmente no es un problema porque en la mayoría de los casos los índices no se crean para ser tan grandes (un índice es un objeto de base de datos que se utiliza para acelerar las consultas).

La base de datos MySQL también tiene una configuración conocida como "intercalación". La intercalación define esencialmente qué tipo de caracteres puede almacenar la base de datos. Los caracteres fuera del conjunto de caracteres esperados suelen ser rechazados, por lo que generalmente es mejor utilizar una intercalación que sea capaz de almacenar todos los caracteres que usted puede esperar que su aplicación produzca. Normalmente recomendamos una intercalación conocida como utf8_unicode_ci, que está diseñada para almacenar caracteres UTF8, que cubre la mayoría de los idiomas internacionales que se pueden encontrar normalmente. utf8_unicode_ci permite utilizar 3 bytes para almacenar caracteres, lo que significa que se pueden utilizar índices en campos con hasta 255 caracteres (255 * 3 = 765). Dado que normalmente el tamaño máximo de un campo indexado en MemberMouse es de 255 caracteres, esto suele funcionar bien.

Su base de datos está configurada para utilizar una intercalación conocida como utf8mb4_general_ci, que permite utilizar hasta 4 bytes para almacenar caracteres. Según tengo entendido, utf8mb4_general_ci permite todos los caracteres almacenados por utf8_unicode_ci, pero además emojis, caracteres especiales utilizados en idiomas asiáticos, etc. El problema surge cuando se utiliza utf8mb4_general_ci con el motor InnoDB. Un campo de base de datos de 255 caracteres requiere ahora 4 bytes por carácter para crear un índice. (255 * 4 = 1020 bytes). El máximo permitido por InnoDB es 767, por lo que esto provoca un error SQL, como el que estás viendo.

MySQL durante la operación normal emitirá una advertencia cuando se exceda el índice máximo de InnoDB, y luego ajustará el índice a 767 bytes, sin embargo hay un modo llamado "modo estricto" en el que MySQL puede ejecutarse y que tratará todos los errores/malas configuraciones como errores duros y se negará a procesar el SQL. 

Así que la combinación de la colación utf8mb4_general_ci, el motor de almacenamiento InnoDB y MySQL ejecutándose en modo estricto ha creado un entorno en el que MemberMouse no puede instalar sus tablas. 

Posibles soluciones avanzadas 

(Siga estos pasos si ya ha estado utilizando MemberMouse y tiene datos que no quiere perder)

1. Desactive el modo estricto. Hacer esto y luego reiniciar la base de datos MySQL seguido de una desactivación/reactivación de MemberMouse debería permitir que las tablas de MemberMouse se creen con su colación actual, y ajustará silenciosamente los tamaños de índice. Esta es probablemente la solución más sencilla.

2. Cambie la intercalación predeterminada de su base de datos a utf8_unicode_ci y, a continuación, desactive/reactive MemberMouse. Es probable que tenga que contratar a un desarrollador o a su proveedor de alojamiento para hacerlo. La configuración de cotejo por defecto para la base de datos sólo afecta a las tablas de nueva creación, por lo que las tablas existentes mantendrán sus cotejos actuales, lo que podría causar problemas. La forma más segura de solucionar este problema sería exportar todas las tablas y datos sin la configuración de intercalación, eliminar las tablas existentes de la base de datos, establecer la intercalación predeterminada de la base de datos en utf8_unicode_ci y, a continuación, volver a importar los datos. Esto podría ser potencialmente una tarea onerosa, pero no tenemos datos sobre los efectos de mezclar las colaciones de diferentes tablas, por lo que simplemente establecer la colación por defecto a utf8_unicode_ci y dejar que MemberMouse recree las tablas que faltan puede no ser suficiente. 

3. Cambiar el motor de almacenamiento utilizado por MySQL. Esta es una tarea no trivial y podría causar problemas con los datos existentes; esta vía sólo debe seguirse si tiene acceso a alguien muy familiarizado con MySQL y los diversos motores de almacenamiento y las complejidades de hacer este tipo de conversión.

El camino de menor resistencia es la opción #1, pero si no quiere o no puede desactivar el modo estricto, cualquiera de estas soluciones debería funcionar. Usted querrá hacer una copia de seguridad de su base de datos actual y poner el sitio en modo de mantenimiento antes de realizar cualquiera de estas acciones.