Eu pensei que ao setar a propriedade SingleTo para True, cada endereço inserido através do método AddAddress() seria tratado de forma exclusiva, ou seja, seria como se eu estivesse mandando uma mensagem por vez, exclusivamente, para cada destinatário… ledo engano! O que ocorre é que a mensagem será enviada para todos os destinatários, apenas o endereço de e-mail é que não será mostrado (e isso na versão mais recente da classe, pois na que eu estava usando nem isso ocorreu!).

Dito isso, se você quer enviar mensagens para vários destinatários de forma exclusiva, usando uma mesma instância do objeto PHPMailer, no seu loop,  antes de chamar AddAddress(), você deve chamar o método ClearAddresses().

Se você é um usuário registrado do uebLOCK agora vai entender porque recebeu “alguns” e-mails a mais ontem! Ah, e não se preocupe, TODOS os dados já foram redefinidos.

Fica aí a dica!

Simples: Eis que descobri que é possível definir uma Timezone personalizada para cada sessão de acesso ao banco (Mysql), bastando para isso que você execute a seguinte query:

$mysqlcon->query("SET TIME_ZONE = '-03:00'");

Fica aí a dica!

Logo após a conexão com o banco new PDO(…) execute as seguintes queries:

$mysqlcon->query("SET CHARACTER SET utf8");
$mysqlcon->query("SET NAMES SET utf8");

Fica aí a dica!

Saiba que, a partir da versão 5.3, um novo método foi adicionado à classe DateTime, o método diff.

Como o nome sugere, o método diff retorna a diferença entre duas datas, ou melhor dizendo, entre dois objetos DateTime e seu uso é bastante simples:

$datetime1 = new DateTime('2009-10-11');
$datetime2 = new DateTime('2009-10-13');
$interval = $datetime1->diff($datetime2);
 
echo $interval->format('%R%a days');

Para informações mais completas, sugiro que acessem o manual e que também deem uma olhada neste comentário, que acredito ser bastante útil.

Fica aí a dica!

Por um descuido acabei usando a Short Tag <? … ?> e não a Long Tag <?php … ?> em uma parte do código e com isso o Apache sempre me retornava “Parse error: syntax error, unexpected $end in …” e por mais que eu procurava eu não encontrava o erro.

Agora você já sabe, caso tenha algum problema parecido, a causa pode ser essa.

Fica aí a dica!

É como se o campo/variável nem existisse! E isso vale para qualquer outro elemento de formulário que tenha definida a propriedade disabled em seu código.

A solução: Se você quer impedir a alteração de algum campo do formulário e ainda continuar recebendo o seu valor pelo PHP, ao invés de utilizar a propriedade disabled, use a propriedade readonly. Ex:

<input type="text" name="email" value="" readonly="readonly"  />

Fica aí a dica!

A lista completa das funções pode ser vista aqui. Note ainda que você pode montar um “pacote” personalizado com as funções desejadas.

Na prática eu ainda não fiz nenhum teste, mas merece um clique.

Fica aí a dica!

A solução é adicionar os parâmetros ‘ENT_QUOTES’ e ‘UTF-8′ na função. Exemplo:

echo htmlentities($post->post_title, ENT_QUOTES, 'UTF-8');

O problema ocorre porque a função htmlentities() usa o charset ISO-8859-1 como padrão e em alguns casos, como no WordPress, a string está codificada em UTF-8.

Mais informações aqui.

Fica aí a dica!

O problema já havia acontecido ao migrar da versão 2.9.2 para a 3.0 e se repetiu novamente.

A solução: acessar o site via FTP, navegar até a pasta “wp-content/languages” e então remover o arquivo pt_BR.php.

Fica aí a dica!

Ocorreu que o processo de atualização automática [do WordPress 2.9.2 para o 3.0] não foi concluído corretamente. O motivo desse erro teria sido a sobrecarga do uso de memória, que por sua vez estaria relacionado à quantidade de plugins instalados. E deve ser isso mesmo, pois em outro site no qual tenho poucos plugins habilitados a atualização ocorreu sem problemas.

Pois bem, segue uma descrição dos fatos e dos procedimentos realizados para solucionar o problema:

Depois que a instalação foi interrompida, recarreguei a página e me deparei com a mensagem “Briefly unavailable for scheduled maintenance. Check back in a minute”.

Descobri que no momento que você inicia o processo de atualização automática, o arquivo “.maintenance” é criado na pasta raiz do WP, indicando que o site está em manutenção e fazendo com que os usuários que acessarem o site, durante a atualização, vejam a mensagem mencionada.

Normalmente, ao final da atualização, esse arquivo é removido automaticamente, porém como ocorreu um erro, ele não foi. Logo, o primeiro passo para a solução do problema foi acessar a pasta de instalação do WP via FTP e remover esse arquivo.

Após remover o arquivo, recarreguei novamente a página do site, e dessa vez obtive a mensagem: “PHP Fatal error:  Call to undefined function is_multisite() in …/wp-includes/wp-db.php on line 505″.

Problema sério. Não era mais possível acessar o site ou o Painel de Administração, logo a única solução foi realizar a atualização manual do WordPress.

Primeiramente fiz o download do WP pelo site oficial (em pt_BR) e extraí o conteúdo do arquivo zip para uma pasta qualquer. Em seguida fiz o upload dos arquivos para o site via FTP, substituindo todo o conteúdo da pasta principal do WP, bem como das pastas wp-admin, wp-content e wp-includes.

Assim que a cópia foi concluída, acessei novamente o site e desta vez obtive a seguinte mensagem: “Sem permissões suficientes para acessar esta página”.

A solução para esse caso foi, via FTP, navegar até a pasta “wp-content/languages” e então remover o arquivo pt_BR.php.

Abri novamente o site e dessa vez tudo estava “normal”. Por fim, ao acessar o Painel de Administração, me deparei com uma mensagem avisando que o banco de dados deveria ser atualizado. Concordei e pronto! Problema resolvido e site atualizado.

Fica aí a dica!