WordPress Widgets – Problemas com Drag and Drop – Resolvido na unha

Já há bastante tempo eu estava tendo problemas com a capacidade de drag and drop dos widgets do WordPress. Nas últimas duas semanas passei boa parte do meu tempo livre fazendo backups e reinstalando o WP. Desliguei plugins, mudei de temas, tentei de tudo. E nada funcionava.

Nessas horas bate uma frustração de não ser programador. Mas mesmo assim eu não desisti… Precisava descobrir o que havia de errado. O Google não ajudou muito, ao contrário de tantas outras vezes. O fórum do WordPress.org também não. O suporte técnico do WordPress.com nem ligou para mim, apesa do problema acontecer por lá também…As soluções propostas, e olha que tentei muitas, não deram jeito. E aí acaba que, com um pouco de curiosidade e saco, consegui achar o motivo do problema. A página lida pelo wordpress 2.3.1 para a manipulação dos widgets é widgets.php. No Firefox, ao ler tal página, os widgets ficavam estáticos e eu não podia arrastar e soltar nenhum deles.

Verifiquei que o Error Console do Firefox me mostrava a mensagem de erro “Draggable is not a function“. Dragabble é sim uma função, que pertence a uma extensão do jquery.js chamada interface.js. Pensei com os meus botões que talvez, por mais improvável que pudesse parecer, o proxy da Tunísia implicasse com o nome da função. Afinal Drag pod se referir a drag queen, e se comportamento sexual diferente do “standard” já dá confusão em Niterói, imagina como deve ser bem visto em um país muçulmano… Mudei todas as referências a drag e substituí por “brag” em todos os arquivos que compõem o pacote do WordPress e voilá… Não funcionou. Bem, pensei com os meus botões, o problema não era o proxy…

No dia seguinte, ao fazer o restore do backup com tudo original, sem modificar o nome da função, deixando Draggable mesmo fui fazer o teste de novo para saber se o erro persistia. Persistia é claro. Tudo imóvel. Como estava usando o Safari, resolvi escarafunchar e ver se havia algo como o Error Console do Firefox. Não havia algo assim, ao menos eu não achei. Em compensação havia uma opção que se chamava “active connections”.

Foi ali que descobri o problema. O active connections mostra todos os links de dada página, de onde estão chupando informação. E entre os links da página, havia o seguinte:

http://www.camelomanco.com/weblog/wp-includes/js/jquery/interface.js?ver=1.2 NOT FOUND

Em poucas palavras, o WordPress não conseguia encontrar o arquivo interface.js, acreditava que o mesmo não estava no servidor. Mas ele estava lá! Coloquei a url acima no browser e recebi uma mensagem igualzinha a do post sobre o Youtube. O danado do Proxy da Tunísia estava aprontando mais uma! Como resolver este pepino?

Tentei então a url:

http://www.camelomanco.com/weblog/wp-includes/js/jquery/interface.js

e qual não foi minha surpresa ao achar lá o arquivo bonitinho….

O meu trabalho então era fazer com que o WordPress chamasse pela segunda url e não pela primeira. E toca a procurar onde era feita a leitura da bendita… Acabei que achei o arquivo scripts-loader.php, que se encarrega de carregar na memória todos os scripts (como o nome diz).

Com um pouco de tentativa e erro modifiquei a linha 77 (no WP 2.3.1):

de:
$this->add( ‘interface’, ‘/wp-includes/js/jquery/interface.js’,
array(‘jquery’), ‘1.2’);

para

$this->add( ‘interface’, ‘/wp-includes/js/jquery/interface.js’,
array(‘jquery’), ”);

Agora o wordpress consegue ler a linha gerada e ela não encrenca com o proxy.

Eu deixei isso tudo aqui documentado por dois motivos. O primeiro é para que quando houver atualização do WP eu saberei exatamente onde eu tenho que mexer no danado caso o mesmo problema ocorra. O segundo é que, apesar de comigo acontecer na Tunísia, o problema certamente não é causado por uma vontade do governo de bloquear a leitura do interface.js. A causa é um proxy mau configurado. E você pode apostar que tem muito proxy nessa situação pelo mundo afora. Se acontecer com você algo parecido, essa dica pode te dar o caminho das pedras para “obrigar: o WP a ler uma biblioteca qualquer…