mar17

Desafio aos visitantes programadores: WordPress

21 Comentarios »Postado por GordoGeek em 17/03/2011 às 16:30h

     Provavelmente nossos leitores que acessam o conteúdo do blog por feed ou via iPhone não devem ter notado, mas certamente quem acessa via browser percebeu algumas mudanças no visual do blog. Andei fazendo alguns ajustes pra conseguir acomodar melhor os anúncios do site e acabei esbarrando num problema do WordPress, o qual gostaria de pedir a ajuda dos “entendidos”, pois já tem 3 dias que estou nisso, já fiz várias coisas e nada surtiu o efeito desejado.

     Estou acostumado a trabalhar com PHP há alguns anos e nunca vi um sistema similar ao WordPress. A cada acesso no site, ele chama alguns arquivos repetidas vezes no mesmo load, como o index.php, header.php, footer.php, sidebar.php e outros. Como eu queria fazer um controle do acesso, gerando estatísticas para os anunciantes, acabei esbarrando nesse problema, uma vez que, se ele carrega os mesmos arquivos várias vezes, as estatísticas ficam completamente erradas, com inúmeros acessos similares. Bom, a essa altura, muitos devem estar se perguntando: ‘mas você não usa o Google Analytics?’. Sim, uso e gosto. Mas para o que eu quero fazer, eu preciso desse controle paralelo, em tempo real.

     Pra tentar entender como o WordPress funciona, comecei pedindo pra logar um registro no banco de dados, cada vez que o arquivo index.php fosse acessado. Pra cada acesso no site, ele cria cerca de 7 entradas no banco de dados, num intervalo de 5 a 10 segundos. Ambos os números variam, tanto as entradas, como o intervalo entre elas.

     Na tentativa de fazer um controle melhor, resolvi criar um cookie pra ‘marcar’ o acesso. Como eu sei que os acessos ocorrem num intervalo de 5 a 10 segundos, criei um cookie, mandei ele expirar em 15 segundos e coloquei uma verificação no início: se existir cookie, não logue o novo acesso. Não sei porque, mas mesmo existindo o cookie, ele diz que não existe. O mais curioso é que testei o trecho do código no mesmo servidor e funcionou. O problema é mesmo quando eu coloco esse trecho no index.php do WordPress.

     Como trabalhar com cookie não funcionou e ainda tem a possibilidade de algum visitante não aceitar cookie em seu navegador, resolvi trabalhar com sessão. Adaptei o código, testei no mesmo servidor e beleza, funcionou. Porém, assim como aconteceu com o cookie, ao jogar no index.php do WordPress, ele diz que a sessão não existe.

     Tentando entender o problema, eu peguei o trecho de código que cria e valida a sessão e joguei dentro dum loop de 30 repetições. Minha intenção era ver se, pelo fato do WordPress chamar o mesmo arquivo repetidas vezes, rapidamente, poderia estar atrapalhando em algo. Novamente, tudo funcionou perfeitamente dentro do loop. Ou seja, o problema não são as chamadas repetidas num curto período de tempo.

     Como último recurso, abri cada um dos arquivos que o WordPress carrega (citados lá em cima, como header.php, sidebar.php, footer.php, etc.) e coloquei o mesmo trechinho de código pra logar no banco de dados, cada load do arquivo, passando um parâmetro pra eu saber qual arquivo estava sendo carregado. Da mesma forma que ocorre com o index.php, os outros arquivos também são carregados várias vezes. Não existe nenhum que é carregado uma única vez, pra eu usá-lo como controle.

     Depois de 3 dias batendo cabeça com o problema, aparentemente idiota, resolvi compartilhar por aqui e ver se encontro alguém pra me dar uma luz, pois estou quase abandonando. Eu posso estar cometendo algum erro bem bobo, mas a priori, não estou vendo. Outra coisa é que estou muito puto da vida com os desenvolvedores do WordPress. Não entendi porque, afinal de contas, eles dão load no mesmo arquivo tantas vezes.

     Update 18/03/2011 17:05h => Depois de tentar várias coisas, uma idéia acabou vingando. Eu precisava marcar a visita como única, mas não vinha conseguindo, nem via cookie, nem via sessão. O que eu fiz? Joguei no banco de dados. Toda vez que carrega o index, eu verifico se existe a informação daquele acesso no banco de dados. Se não existir, cria. Se existir, verifica se é maior que 15 segundos ou não. Caso seja, renova a sessão e interpreta como um novo acesso/ clique. Caso não, impede que gere estatísticas erradas. Resolvido!

Leave a Reply

preload preload preload