Há uma opção especificamente para isso no arquivo my.conf:

[mysqld]
ft_min_word_len=3

Nesse exemplo, 3 é o número mínimo de letras para uma palavra ser indexada.

Para quem usa Mac, e Mamp, é preciso criar esse arquivo, com base nos exemplos que estão em /MAMP/Library/share/mysql. Por exemplo, copie o arquivo my-small.cnf para /MAMP/Library/, renomeie-o para my.conf e cole o bloco acima.

Obviamente, o “small” se refere a uma configuração padrão para bancos de dados pequenos.

Referências:

• Fine-Tuning MySQL Full-Text Search
• Create MySQL configuration file (my.cnf) on MAMP

No final, rolou um glorioso Fail. Tive que apelar para o Apache do Mac mesmo. Vou documentar pois vira e mexe preciso consultar esses procedimentos.

Comecei com essa dica: Using Ruby MySQL Gem with MAMP 1.8.x on Snow Leopard.

Para isso, tive que atualizar o Mamp. Estava com receio de quebrar algo no processo, já que meu Mamp está todo customizado. Mas como já tinha documentado as principais mudanças [Drupal no Mac], foi suave.

Tive que instalar o XCode também, que vem no DVD do Snow Leopard. Essa etapa funcionou que é uma beleza, me deixando saudosista dos tempos em que compilava kernel customizado no Linux.

Agora que o Ruby já conversa com o MySQL, falta o Apache do Mamp. Essa não é uma etapa obrigatória, sendo que o desenvolvimento local pode ser feito com os servidores web do Rails (Mongrel ou Webrick). Mas tive que configurar o Rails no Apache pois alguns hosts (como a Dreamhost), devido a alguma configuração específica, simplesmente não rodam uma aplicação que, localmente, está OK.

Para já ir desenvolvendo na mesma configuração do servidor onde ficará a aplicação é preciso usar o Apache/Passenger localmente.

Módulo não compila

Tentei me basear nessa dica: Installing passenger on Apache that bundled with MAMP. Ela não funciona pois ao rodar o passenger-install-apache2-module, é preciso especificar os caminhos específicos do Apache Mamp, coisa que não é informada aí.

Mas mesmo fazendo isso, não funciona. A compilação pára em certo momento, reclamando de alguns arquivos não encontrados. Gastei várias horas tentando compilar o Passenger de umas dez maneiras diferentes. Pelo que entendi, o problema é que — mesmo usando os arquivos-fonte do Mamp — faltam arquivos para a compilação, como o config_vars.mk.

Desisti. Como a dica acima funciona se compilarmos o Passenger com o Apache do Snow Leopard, é assim que estou usando, apesar de ser uma gambiarra horrível usar o MySQL do Mamp com o Apache do Snow Leo, ainda mais porque meu Mamp está configurado nas mesmas portas do Mac.

O que vou fazer assim que tiver um tempo maior é abandonar o Mamp e instalar MySQL e PHP tudo na mão mesmo.

Dreamhost e Drupal

Por falar em Dreamhost, há um mês mais ou menos ficou muito difícil lá para quem usa Drupal. Trabalho com um site que ficou praticamente inutilizável em horário comercial (PDT, nos EUA). Pesquisei bastante, tentando algum jeito de contornar o problema, mas nada.

Por fim, a própria Dreamhost admitiu que, por usar servidores MySQL separados, há uma latência que prejudica muito CMSs como o Drupal, que realizam dezenas de queries por pageview.

Migrei para Bluehost e agora dá para respirar aliviado: uuuuffaaaaa! Tá tudo de volta ao normal.

Como tudo fica no nosso computador, o processo agiliza bastante:

• As mudanças no site são instantâneas
• Não há necessidade de ficar subindo cada arquivo editado, basta um refresh no navegador

Em Linux e Mac, nunca tive dificuldade para instalar e configurar. Ultimamente, usando Windows 7, foi uma boa surpresa descobrir que é tão fácil quanto (com o WampServer).

Importar banco de dados

Usando Wordpress, uma coisa um pouco chata é que na hora de passar tudo para o servidor web real, você importa o banco de dados e o site simplesmente implode: nada funciona mais.

Mas há uma gambiarra simples que contorna isso. Basta editar o arquivo .sql:

1. Exporte o banco de dados — com o PHPMyAdmin, por exemplo — em um arquivo .sql
2. Abra o arquivo em um bom editor de código, como o Notepad++
3. Dê um “find & replace”, substituindo “localhost” pelo domínio do servidor online
4. Importe o arquivo no servidor web real (se o arquivo for maior que 2 MB, vai haver problemas. A etapa 6 deste tutorial ajuda a resolver a coisa)
5. Pronto!

Com o Wordpress, isso funciona até que bem. Só há um erro que ainda não entendi: alguns widgets somem após a importação, sendo necessário reposicionar e configurar. Mas esse é um preço baratinho até pela comodidade de desenvolver localmente.

Arquivo “hosts”

Além desse método, há um outro mais simples ainda:

• Abra o arquivo “hosts” e acrescente a linha “127.0.0.1  seudominio.com.br”
• No Windows 7, o arquivo fica em “Windows\System32\drivers\etc\” (em Linux e Mac, fica em /etc/ )

Isso faz com que cada requisição a “seudominio.com.br” seja redirecionada para “localhost”. Assim, é possível importar o banco de dados local no servidor online, sem edição nenhuma.

O único incômodo é ter de ficar comentando e descomentando (#) a nova linha do arquivo hosts sempre que precisar acessar o domínio verdadeiro e vice-versa.

Nesse vai e vem, tem hora que já nem sei mais se estou no localhost ou no domínio online. Mas dá para acostumar e considero um preço barato também pelo tempo que isso poupa.