Dies wurde in MM 2.2.7+ behoben.
Laden Sie die neueste Version herunter und lernen, wie man manuell aktualisieren
Frage
Ich erhalte diesen Datenbankfehler WordPress-Datenbankfehler Der angegebene Schlüssel war zu lang; die maximale Schlüssellänge beträgt 767 Bytes für die Abfrage...
Kurze Erläuterung des Problems
Dieses Problem ist auf die für Ihre Datenbanktabellen verwendete Sortierung zurückzuführen, die auf utf8mb4_unicode_ci oder etwas Ähnliches eingestellt ist. Das Problem dabei ist, dass diese besondere Sortierreihenfolge die Länge der Schlüssel in den Datenbanktabellen einschränkt, was dazu führt, dass bestimmte MemberMouse-Tabellen bei der Plugin-Aktivierung nicht installiert werden können.
Wenn Sie Ihre Datenbank-Fehlerprotokolle überprüfen, werden Sie diese Fehler wie folgt sehen:
WordPress-Datenbank-Fehler: [Angegebener Schlüssel war zu lang; maximale Schlüssellänge ist 1000 Bytes]
Wie Sie sich vorstellen können, äußert sich das Fehlen von Tabellen in der Datenbank auf unterschiedliche Weise, je nachdem, welche Tabellen fehlen. In diesem Fall haben Sie ein Problem bei der Erstellung eines Produkts, das speziell darauf zurückzuführen ist, dass die Tabelle mm_affiliate_providers nicht installiert ist.
Wenn jedoch die Kollation utf8mb4_unicode_ci verwendet wird, folgt die vollständige Liste der Tabellen, die nicht installiert werden:
mm_affiliate_provider
mm_affiliate_rebill_commissions
mm_email_service_provider
mm_log_events
mm_social_login_verlinkte_profile
mm_stripe_Kunden_links
Lösungsschritte (Folgen Sie diesen Schritten, wenn Sie gerade erst mit MemberMouse anfangen)
Wenn Sie gerade erst anfangen und noch keine oder nur sehr wenige Daten in MemberMouse haben, ist es am einfachsten und sichersten, wie folgt vorzugehen:
1. Folgen Sie den Schritten zu MemberMouse deinstallieren.
2. Navigieren Sie über phpMyAdmin zu der Datenbank, die für Ihre WordPress-Installation verwendet wird. Dies ist die Datenbanktabelle, die in Ihrer wp-config.php-Datei aufgeführt ist.
3. Einstellen der Standard-Sortierreihenfolge für die Datenbank zu utf8_unicode_ci
4. Durchführen einer Neuinstallation des MemberMouse-Plugins
Danach sind alle MemberMouse-Tabellen installiert.
Erweiterte Erläuterung des Problems
Dieses Problem wird durch einen perfekten Sturm von Bedingungen verursacht, die zusammenkommen, um eine Hosting-Umgebung zu schaffen, die mit aktuellen Versionen von MemberMouse inkompatibel ist. Diese Bedingungen sind sehr technisch und einfach, aber im Folgenden wird erklärt, was passiert, und es werden mögliche Lösungen vorgestellt.
Die Datenbank, die Sie verwenden (und mit der die MemberMouse kompatibel ist), ist die MySQL-Datenbank. Die MySQL-Datenbank kann mit verschiedenen "Speicher-Engines" konfiguriert werden, die steuern, wie Daten gespeichert und abgerufen werden. Jede Engine hat bestimmte Vorteile und Kompromisse, so dass die Entscheidung, welche Engine in einer bestimmten Umgebung am besten geeignet ist, sehr subjektiv ist. Die Speicher-Engine, die Ihre Datenbank verwendet, ist InnoDB. Einer der Nachteile der InnoDB-Engine ist die maximale Indexlänge von 767 Byte, was normalerweise kein Problem darstellt, da Indizes in den meisten Fällen nicht so groß sein müssen (ein Index ist ein Datenbankobjekt, das zur Beschleunigung von Abfragen verwendet wird).
Die MySQL-Datenbank hat auch eine Einstellung, die als "Collation" bekannt ist. Die Sortierung legt im Wesentlichen fest, welche Arten von Zeichen die Datenbank speichern kann. Zeichen, die außerhalb des erwarteten Zeichensatzes liegen, werden in der Regel zurückgewiesen. Daher ist es im Allgemeinen am besten, eine Sortierreihenfolge zu verwenden, die in der Lage ist, alle Zeichen zu speichern, die Sie in Ihrer Anwendung erwarten können. Wir empfehlen in der Regel die Kollation utf8_unicode_ci, die für die Speicherung von UTF8-Zeichen ausgelegt ist, was die meisten internationalen Sprachen abdeckt, die Sie normalerweise erwarten. utf8_unicode_ci erlaubt die Verwendung von 3 Byte für die Speicherung von Zeichen, was bedeutet, dass Indizes für Felder mit bis zu 255 Zeichen verwendet werden können (255 * 3 = 765). Da die maximale Größe eines indizierten Feldes in MemberMouse normalerweise 255 Zeichen beträgt, funktioniert dies im Allgemeinen gut.
Ihre Datenbank ist so konfiguriert, dass sie die Sortierreihenfolge utf8mb4_general_ci verwendet, bei der bis zu 4 Bytes für die Speicherung von Zeichen verwendet werden können. Nach meinem Verständnis erlaubt utf8mb4_general_ci alle Zeichen, die in utf8_unicode_ci gespeichert werden, aber zusätzlich Emojis, Sonderzeichen in asiatischen Sprachen usw. Das Problem tritt bei der Verwendung von utf8mb4_general_ci mit der InnoDB-Engine auf. Ein Datenbankfeld mit 255 Zeichen benötigt nun 4 Byte pro Zeichen, um einen Index zu erstellen. (255 * 4 = 1020 Bytes). Das von InnoDB erlaubte Maximum liegt bei 767, was zu einem SQL-Fehler führt, wie Sie ihn gerade sehen.
Im Normalbetrieb gibt MySQL eine Warnung aus, wenn der maximale InnoDB-Index überschritten wird, und passt den Index dann auf 767 Byte an. Es gibt jedoch einen Modus namens "Strict Mode", in dem MySQL alle Fehler/Fehlkonfigurationen als schwere Fehler behandelt und die Verarbeitung des SQL verweigert.
Die Kombination aus der Kollation utf8mb4_general_ci, der InnoDB-Speicher-Engine und MySQL im Strict-Modus hat also eine Umgebung geschaffen, in der MemberMouse seine Tabellen nicht installieren kann.
Erweiterte Lösungsmöglichkeiten
(Befolgen Sie diese Anweisungen, wenn Sie MemberMouse bereits verwendet haben und Daten haben, die Sie nicht verlieren möchten)
1. Deaktivieren Sie den strikten Modus. Wenn Sie dies tun und dann die MySQL-Datenbank neu starten, gefolgt von einer Deaktivierung/Reaktivierung von MemberMouse, sollten die MemberMouse-Tabellen mit Ihrer aktuellen Sortierung erstellt werden können, und die Indexgrößen werden unbemerkt angepasst. Dies ist wahrscheinlich die einfachste Lösung.
2. Ändern Sie die Standardsortierreihenfolge in Ihrer Datenbank auf utf8_unicode_ci und deaktivieren Sie MemberMouse bzw. reaktivieren Sie es. Wahrscheinlich müssen Sie einen Entwickler oder Ihren Hosting-Anbieter damit beauftragen, dies zu tun. Die Standard-Sortierreihenfolgeeinstellung für die Datenbank wirkt sich nur auf neu erstellte Tabellen aus, so dass Ihre vorhandenen Tabellen ihre aktuelle Sortierreihenfolge beibehalten, was zu Problemen führen kann. Am sichersten ist es, alle Tabellen und Daten ohne Sortiereinstellungen zu exportieren, die vorhandenen Tabellen in der Datenbank zu löschen, die Standard-Sortierreihenfolge in der Datenbank auf utf8_unicode_ci zu setzen und die Daten dann erneut zu importieren. Dies könnte eine mühsame Aufgabe sein, aber wir haben keine Daten über die Auswirkungen der Vermischung der Sortierreihenfolge verschiedener Tabellen, so dass es möglicherweise nicht ausreicht, die Standard-Sortierreihenfolge auf utf8_unicode_ci zu setzen und MemberMouse die fehlenden Tabellen neu erstellen zu lassen.
3. Ändern Sie die von MySQL verwendete Speicher-Engine. Diese Aufgabe ist nicht trivial und könnte zu Problemen mit den vorhandenen Daten führen. Dieser Weg sollte nur beschritten werden, wenn Sie Zugang zu jemandem haben, der mit MySQL und den verschiedenen Speicher-Engines und den Feinheiten dieser Art von Konvertierung sehr vertraut ist.
Der Weg des geringsten Widerstands ist die Option #1, aber wenn Sie den strengen Modus nicht abschalten wollen oder können, sollte jede dieser Lösungen funktionieren. Bevor Sie eine dieser Maßnahmen durchführen, sollten Sie eine Sicherungskopie Ihrer aktuellen Datenbank erstellen und die Website in den Wartungsmodus versetzen.