Erreur de base de données WordPress : La clé spécifiée est trop longue

Ce problème a été résolu dans MM 2.2.7+.

Télécharger la version la plus récente et apprendre à mise à niveau manuelle

Question

Je reçois cette erreur de base de données Erreur de base de données WordPress La clé spécifiée était trop longue ; la longueur maximale de la clé est de 767 octets pour la requête...

Brève explication du problème

Ce problème résulte de la collation utilisée sur vos tables de base de données, qui est définie sur utf8mb4_unicode_ci ou quelque chose de similaire. Le problème est que ce style de collation particulier limite la longueur des clés des tables de la base de données, ce qui fait que certaines tables MemberMouse ne sont pas installées lors de l'activation du plugin. 

Si vous consultez les journaux d'erreurs de votre base de données, vous verrez ces erreurs se refléter comme suit :

Erreur de base de données WordPress : [La clé spécifiée était trop longue ; la longueur maximale de la clé est de 1000 octets].

Comme vous pouvez l'imaginer, lorsque des tables sont absentes de la base de données, le problème se manifeste de différentes manières en fonction des tables manquantes. Dans le cas présent, vous rencontrez un problème lors de la création d'un produit, qui résulte spécifiquement du fait que la table mm_affiliate_providers n'est pas installée. 

Cependant, lorsque la collation utf8mb4_unicode_ci est utilisée, voici la liste complète des tables qui ne seront pas installées :

mm_affiliate_providers

mm_affiliate_rebill_commissions

mm_email_service_providers

mm_log_events

mm_social_login_linked_profiles

mm_stripe_customer_links

Étapes de la solution (suivez ces étapes si vous commencez à peine à utiliser MemberMouse)

Si vous débutez et que vous n'avez pas de données dans MemberMouse, ou très peu, le moyen le plus simple et le plus sûr de résoudre ce problème est de procéder comme suit : 

1. Suivez les étapes pour Désinstaller MemberMouse.

2. Via phpMyAdmin, naviguez jusqu'à la base de données utilisée pour votre installation WordPress. Il s'agit de la table de base de données indiquée dans votre fichier wp-config.php.

3. Définir la collation par défaut de la base de données vers utf8_unicode_ci

4. Effectuer un nouvelle installation du plugin MemberMouse

Ensuite, toutes les tables MemberMouse auront été installées.

Explication avancée du problème

Ce problème est dû à une tempête parfaite de conditions qui se conjuguent pour créer un environnement d'hébergement incompatible avec les versions actuelles de MemberMouse. Ces conditions sont très techniques et de bas niveau, mais ce qui suit est une explication de ce qui se passe ainsi que des solutions potentielles.

La base de données que vous utilisez (et avec laquelle MemberMouse est compatible) est la base de données MySQL. La base de données MySQL peut être configurée avec différents "moteurs de stockage" qui contrôlent la manière dont les données sont stockées et récupérées. Chaque moteur présente certains avantages et compromis, de sorte que le meilleur moteur à utiliser dans un environnement particulier est très subjectif. Le moteur de stockage utilisé par votre base de données est InnoDB. L'un des inconvénients du moteur InnoDB est que la longueur maximale de son index est de 767 octets, ce qui n'est normalement pas un problème car, dans la plupart des cas, les index ne sont pas créés pour être aussi volumineux (un index est un objet de base de données utilisé pour accélérer les requêtes).

La base de données MySQL dispose également d'un paramètre appelé "collation". La collation définit essentiellement le type de caractères que la base de données peut stocker. Les caractères ne faisant pas partie du jeu de caractères attendu sont généralement rejetés. Il est donc préférable d'utiliser une collation capable de stocker tous les caractères que votre application est susceptible de produire. Nous recommandons généralement une collation connue sous le nom de utf8_unicode_ci, qui est conçue pour stocker les caractères UTF8, qui couvrent la plupart des langues internationales que vous pouvez normalement rencontrer. utf8_unicode_ci permet d'utiliser 3 octets pour stocker les caractères, ce qui signifie que les index peuvent être utilisés sur des champs contenant jusqu'à 255 caractères (255 * 3 = 765). Comme la taille maximale d'un champ indexé dans MemberMouse est normalement de 255 caractères, cela fonctionne généralement bien.

Votre base de données est configurée pour utiliser une collation connue sous le nom de utf8mb4_general_ci, qui permet d'utiliser jusqu'à 4 octets pour stocker des caractères. Si j'ai bien compris, utf8mb4_general_ci permet de stocker tous les caractères stockés par utf8_unicode_ci, mais aussi les emojis, les caractères spéciaux utilisés dans les langues asiatiques, etc. Le problème se pose lorsque l'on utilise utf8mb4_general_ci avec le moteur InnoDB. Un champ de base de données de 255 caractères nécessite désormais 4 octets par caractère pour créer un index. (255 * 4 = 1020 octets). Le maximum autorisé par InnoDB est de 767, ce qui provoque une erreur SQL, comme celle que vous voyez.

En fonctionnement normal, MySQL émet un avertissement lorsque l'index InnoDB maximal est dépassé, puis ajuste l'index à 767 octets. Cependant, il existe un mode appelé "mode strict" dans lequel MySQL peut fonctionner et qui traite toutes les erreurs/mauvaises configurations comme des erreurs difficiles et refuse de traiter le code SQL. 

La combinaison de la collation utf8mb4_general_ci, du moteur de stockage InnoDB et de l'exécution de MySQL en mode strict a donc créé un environnement dans lequel MemberMouse ne peut pas installer ses tables. 

Solutions potentielles avancées 

(Suivez ces instructions si vous avez déjà utilisé MemberMouse et que vous avez des données que vous ne voulez pas perdre)

1. Désactivez le mode strict. Cette opération, suivie du redémarrage de la base de données MySQL et de la désactivation/réactivation de MemberMouse, devrait permettre de créer les tables MemberMouse avec votre collation actuelle et d'ajuster silencieusement la taille des index. C'est probablement la solution la plus simple.

2. Changez la collation par défaut de votre base de données en utf8_unicode_ci, puis désactivez/réactivez MemberMouse. Vous devrez probablement faire appel à un développeur ou à votre hébergeur pour effectuer cette opération. Le paramètre de collation par défaut de la base de données n'affecte que les tables nouvellement créées, de sorte que vos tables existantes conserveront leur collation actuelle, ce qui pourrait poser des problèmes. Le moyen le plus sûr de résoudre ce problème serait d'exporter toutes vos tables et données sans paramètres de collation, de supprimer les tables existantes dans la base de données, de définir la collation par défaut de la base de données sur utf8_unicode_ci, puis de réimporter vos données. Cette tâche pourrait s'avérer fastidieuse, mais nous ne disposons d'aucune donnée sur les effets du mélange des collations de différentes tables. Par conséquent, le simple fait de définir la collation par défaut sur utf8_unicode_ci et de laisser MemberMouse recréer les tables manquantes pourrait ne pas suffire. 

3. Modifier le moteur de stockage utilisé par MySQL. Il s'agit d'une tâche non triviale qui pourrait entraîner des problèmes avec les données existantes ; cette voie ne devrait être suivie que si vous avez accès à quelqu'un qui connaît très bien MySQL et les différents moteurs de stockage, ainsi que les subtilités de ce type de conversion.

L'option #1 est celle qui offre le moins de résistance, mais si vous ne voulez pas ou ne pouvez pas désactiver le mode strict, n'importe laquelle de ces solutions devrait fonctionner. Vous devrez sauvegarder votre base de données actuelle et mettre le site en mode maintenance avant d'effectuer l'une de ces actions.