Erro no banco de dados do WordPress: A chave especificada era muito longa

Isso foi resolvido no MM 2.2.7+

Faça o download da versão mais recente e saiba como atualizar manualmente

Pergunta

Estou recebendo este erro de banco de dados Erro no banco de dados do WordPress A chave especificada era muito longa; o comprimento máximo da chave é de 767 bytes para a consulta...

Breve explicação do problema

Esse problema é resultado do agrupamento usado em suas tabelas de banco de dados, que está definido como utf8mb4_unicode_ci ou algo semelhante. O problema é que esse estilo de agrupamento específico restringe o comprimento das chaves nas tabelas do banco de dados, o que faz com que determinadas tabelas do MemberMouse não sejam instaladas durante a ativação do plug-in. 

Se você analisar os logs de erros do banco de dados, verá esses erros refletidos da seguinte forma:

Erro no banco de dados do WordPress: [A chave especificada era muito longa; o comprimento máximo da chave é de 1000 bytes].

Como você pode imaginar, quando faltam tabelas no banco de dados, isso se manifesta de maneiras diferentes, dependendo de quais tabelas estão faltando. Nesse caso, você está tendo um problema ao criar um produto que é especificamente o resultado da tabela mm_affiliate_providers não estar instalada. 

No entanto, quando o agrupamento utf8mb4_unicode_ci é usado, a seguir está a lista completa de tabelas que não serão instaladas:

mm_affiliate_providers

mm_affiliate_rebill_commissions

mm_email_service_providers

mm_log_events

mm_social_login_linked_profiles

mm_stripe_customer_links

Etapas da solução (siga estas etapas se estiver apenas começando a usar o MemberMouse)

Se estiver apenas começando e não tiver nenhum dado no MemberMouse, ou tiver muito poucos dados, a maneira mais fácil e segura de resolver isso é fazer o seguinte: 

1. Siga as etapas para Desinstalar o MemberMouse.

2. Por meio do phpMyAdmin, navegue até o banco de dados que está sendo usado para a instalação do WordPress. Essa é a tabela do banco de dados listada em seu arquivo wp-config.php.

3. Definir o agrupamento padrão do banco de dados para utf8_unicode_ci

4. Execute um nova instalação do plug-in MemberMouse

Depois disso, todas as tabelas do MemberMouse terão sido instaladas.

Explicação avançada do problema

Esse problema é causado por uma tempestade perfeita de condições que se juntam para criar um ambiente de hospedagem incompatível com as versões atuais do MemberMouse. Essas condições são muito técnicas e de baixo nível, mas o que se segue é uma explicação do que está acontecendo, juntamente com possíveis soluções.

O banco de dados que você está usando (e com o qual o MemberMouse foi criado para ser compatível) é o banco de dados MySQL. O banco de dados MySQL pode ser configurado com diferentes "mecanismos de armazenamento" que controlam como os dados são armazenados e recuperados. Cada mecanismo tem certas vantagens e desvantagens, portanto, o melhor mecanismo a ser usado em um determinado ambiente é altamente subjetivo. O mecanismo de armazenamento que seu banco de dados está usando é o InnoDB. Uma das desvantagens do mecanismo InnoDB é que ele tem um comprimento máximo de índice de 767 bytes, o que normalmente não é um problema porque, na maioria dos casos, os índices não são criados para serem tão grandes (um índice é um objeto de banco de dados usado para acelerar as consultas).

O banco de dados MySQL também tem uma configuração conhecida como "collation". O agrupamento define essencialmente o tipo de caracteres que o banco de dados pode armazenar. Os caracteres fora do conjunto de caracteres esperado geralmente são rejeitados, portanto, é melhor usar um agrupamento que seja capaz de armazenar todos os caracteres que você espera que seu aplicativo produza. Normalmente, recomendamos um agrupamento conhecido como utf8_unicode_ci, que foi projetado para armazenar caracteres UTF8, que abrange a maioria dos idiomas internacionais que você normalmente espera encontrar. utf8_unicode_ci permite que 3 bytes sejam usados para armazenar caracteres, o que significa que os índices podem ser usados em campos com até 255 caracteres (255 * 3 = 765). Como normalmente o tamanho máximo de um campo indexado no MemberMouse é de 255 caracteres, isso geralmente funciona bem.

Seu banco de dados está configurado para usar um agrupamento conhecido como utf8mb4_general_ci, que permite que até 4 bytes sejam usados para armazenar caracteres. Pelo que sei, o utf8mb4_general_ci permite todos os caracteres armazenados pelo utf8_unicode_ci, mas também emojis, caracteres especiais usados em idiomas asiáticos etc. O problema surge quando se usa o utf8mb4_general_ci com o mecanismo InnoDB. Um campo de banco de dados de 255 caracteres agora requer 4 bytes por caractere para criar um índice. (255 * 4 = 1020 bytes). O máximo permitido pelo InnoDB é 767, portanto, isso causa um erro de SQL, como o que você está vendo.

O MySQL, durante a operação normal, emitirá um aviso quando o índice máximo do InnoDB for excedido e, em seguida, ajustará o índice para 767 bytes; no entanto, há um modo chamado "modo estrito" no qual o MySQL pode ser executado e que tratará todos os erros/desconfigurações como erros graves e se recusará a processar o SQL. 

Portanto, a combinação do agrupamento utf8mb4_general_ci, do mecanismo de armazenamento InnoDB e do MySQL em execução no modo estrito criou um ambiente em que o MemberMouse não consegue instalar suas tabelas. 

Soluções potenciais avançadas 

(Siga estas instruções se você já estiver usando o MemberMouse e tiver dados que não deseja perder)

1. Desative o modo estrito. Fazer isso e, em seguida, reiniciar o banco de dados MySQL seguido de uma desativação/reativação do MemberMouse deve permitir que as tabelas do MemberMouse sejam criadas com seu agrupamento atual e ajustará silenciosamente os tamanhos dos índices. Essa é provavelmente a solução mais fácil.

2. Altere o agrupamento padrão em seu banco de dados para utf8_unicode_ci e, em seguida, desative/reative o MemberMouse. Provavelmente será necessário contratar um desenvolvedor ou seu provedor de hospedagem para fazer isso. A configuração de agrupamento padrão do banco de dados afeta apenas as tabelas recém-criadas, de modo que as tabelas existentes manterão os agrupamentos atuais, o que pode causar problemas. A maneira mais segura de lidar com esse problema seria exportar todas as suas tabelas e dados sem configurações de agrupamento, eliminar as tabelas existentes no banco de dados, definir o agrupamento padrão no banco de dados como utf8_unicode_ci e, em seguida, reimportar os dados. Isso poderia ser uma tarefa onerosa, mas não temos dados sobre os efeitos de misturar os agrupamentos de tabelas diferentes, portanto, apenas definir o agrupamento padrão como utf8_unicode_ci e deixar o MemberMouse recriar as tabelas ausentes pode não ser suficiente. 

3. Alterar o mecanismo de armazenamento usado pelo MySQL. Essa é uma tarefa não trivial e pode causar problemas com os dados existentes; esse caminho só deve ser seguido se você tiver acesso a alguém muito familiarizado com o MySQL e os vários mecanismos de armazenamento e as complexidades de fazer esse tipo de conversão.

O caminho de menor resistência é a opção #1, mas se você não quiser ou não puder desativar o modo estrito, qualquer uma dessas soluções deverá funcionar. É recomendável fazer backup do banco de dados atual e colocar o site em modo de manutenção antes de executar qualquer uma dessas ações.