<meta name="generator" content="WordPress 2.8.4" />

Muita gente não gosta de anunciar para o mundo a versão usada. Seja por não querer exibir o uso do WordPress, ou por medo de alguem usar essa informação para um possível ataque contra essa versão específica do WordPress, existe uma forma muito simples de retirar isso do cabeçalho, sem precisar editar os arquivos do sistema (que a priori, nunca devem ser editados).
Essa tag é inserida no cabeçalho através de uma action padrão, chamada wp_generator. Para não exibir, basta remover a action, adicionando o seguinte código no functions.php do seu tema:

<?php
remove_action('wp_head', 'wp_generator');
?>

Pronto, com isso o seu site não irá mais exibir esta tag no cabeçalho.

Artigos relacionados

• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

Criando um plugin

Neste artigo, vamos mostrar o passo a passo da criação de um plugin simples, que visa guardar em uma tabela o número de visualizações de cada post do blog. Só isso. Não teremos gráficos, tabelas, nada do tipo. Apenas vamos guardar os dados, que podem ser utilizados por uma outra ferramenta qualquer.
O objetivo não é apenas mostrar como se criar um plugin. A partir deste esqueleto, adicionar mais funcionalidades fica mais fácil.

O cabeçalho do plugin

Antes de mais nada, logo no início precisamos ter um cabeçalho no arquivo do plugin que informará ao WordPress algumas informações, como nome do plugin, uma descrição, autor, versão, e outras coisas. É importante ter isso bem definido.
Essas informações entram em um comentário logo no início do arquivo. No nosso caso, teremos o seguinte:

<?php
/*
Plugin Name: View Counter
Description: Increments a counter each time a post is viewed
Version: 1.0
Author: Bruno Lustosa
Author URI: http://www.ataraxia.com.br/
*/

Pronto, já temos aí o nome do plugin (View Counter), uma breve descrição do que ele faz, a versão, o nome do autor e a URL do autor, para referência. O WordPress exibe essas informações na página dos plugins na área administrativa. Coloquei as informações em inglês, pois a interface administrativa deste blog está toda em inglês.

Os hooks

Entenda os hooks como ações onde você pode criar um callback. Ou seja, sempre que determinada ação for executada no WordPress, uma função definida por você será chamada. No nosso caso, vou definir 2 hooks e uma ação (a ação é parecida com o hook, mostrarei a diferença logo abaixo).

// Hooks
register_activation_hook(__FILE__, "viewcounter_activate");
register_deactivation_hook(__FILE__, "viewcounter_deactivate");
add_action('save_post', 'viewcounter_insert');

O primeiro hook determina que a função viewcounter_activate() será executada quando o plugin for ativado. Esta função cuidará da criação da tabela, caso necessário. Da mesma forma, o segundo hook executará viewcounter_deactivate(), que destruirá nossa tabela, para deixar o sistema limpo como estava antes da ativação. É sempre uma boa prática remover o que criamos após a desinstalação.
A ação é bem semelhante ao hook, e no caso, executará a função viewcounter_insert() assim que um post for salvo. Esta função irá inserir uma linha em nossa tabela, definindo o número de leituras como sendo zero.

Nossa tabela

Iremos criar uma tabela bem simples para guardar as nossas informações. Tudo que precisaremos, é de um campo para guardar o ID do post, e outro pra guardar o número de visualizações. Sim, poderíamos alterar a tabela de posts e adicionar um campo com o número de visualizações, porém, prefiro não mexer em tabelas do sistema, para evitar problemas de compatibilidade futura (vai que uma versão futura do WordPress possui um campo com esse mesmo nome?).
O comando para a criação da tabela:

CREATE TABLE viewcounter (
    post_ID INT NOT NULL PRIMARY KEY,
    views INT NOT NULL DEFAULT 0
);

O hook de ativação

Com a definição da nossa tabela em mãos, vamos partir para a função de ativação do plugin. Ela será executada uma única vez, quando o administrador ativar o plugin.
Nossa função, por segurança, irá checar se a tabela que queremos criar já existe, para evitar erros. A checagem usará o comando SQL SHOW TABLES.
A função ficará assim:

function viewcounter_activate() {
 
    global $wpdb, $viewcounter_table;
 
    if ($wpdb->get_var("SHOW TABLES LIKE '{$viewcounter_table}'") != $viewcounter_table):
        $wpdb->query("CREATE TABLE {$viewcounter_table} (post_ID INT NOT NULL PRIMARY KEY, views INT NOT NULL DEFAULT 0)");
    endif;
 
} // viewcounter_activate

Note que temos duas variáveis globais. A primeira, $wpdb, é do próprio WordPress, e é usada para acessar o banco de dados e executar queries. A segunda, foi definida por nós, e contem o nome da tabela que usaremos. Lembra, que durante a instalação do WordPress, ele te pediu um prefixo para as tabelas? Ao invés de deixarmos um nome fixo, é sempre bom definir o nome da tabela usando este prefixo.
Assim, esta segunda variável global foi definida fora da função, da seguinte forma:

global $viewcounter_table;
$viewcounter_table = "{$wpdb->prefix}viewcounter";

Resumindo, se você definiu o prefixo para as tabelas do WordPress como wp_, então nossa tabela se chamará wp_viewcounter. Isso é especialmente importante caso seu plugin seja usado em um sistema multi-usuário, como o WordPress MU.

A desativação

Bem semelhante à nossa função de ativação, temos a função que será executada quando o plugin for desativado. A idéia aqui é limpar tudo que fizemos, deixando o sistema como estava antes. Para tanto, basta destruir a nossa tabela.

function viewcounter_deactivate() {
 
    global $wpdb, $viewcounter_table;
 
    $wpdb->query("DROP TABLE {$viewcounter_table}");
 
} // viewcounter_deactivate

Simples assim. Desativou o plugin, destruiu a tabela.

Quando salvamos o post

Assim que um post é salvo, temos a função viewcounter_insert() que será chamada, tendo como parâmetro o ID do novo post. Esta função deve inserir uma linha em nossa tabela, indicando que esse novo post teve 0 visualizações até o momento, o que é lógico, pois ele acabou de ser criado.
A função também fica bem simples:

function viewcounter_insert($post_ID) {
 
    global $wpdb, $viewcounter_table;
 
    $wpdb->query("INSERT INTO {$viewcounter_table} (post_ID, views) VALUES ({$post_ID}, 0)");
 
} // viewcounter_insert

A contagem propriamente dita

E por último, temos a contagem das visualizações. Para tanto, teremos uma função chamada viewcounter_update(), que receberá como parâmetro o ID do post a ser atualizado. Para conveniência, essa função também irá retornar o número atualizado de visualizações que o post teve, que poderá ser usado no template em algum lugar.
Esta função tem algumas checagens extras que são feitas por segurança. Por exemplo, caso um post antigo seja visualizado, precisaremos rodar a função que cria a linha para o post, pois como ele foi criado antes da ativação do plugin, o hook anterior não foi chamado.
A função pode ficar assim:

function viewcounter_update($post_ID) {
 
    global $wpdb, $viewcounter_table;
 
    if (is_null($wpdb->get_var("SELECT views FROM {$viewcounter_table} WHERE post_ID = {$post_ID}"))):
        viewcounter_insert($post_ID);
    endif;
    $wpdb->query("UPDATE {$viewcounter_table} SET views = views + 1 WHERE post_ID = {$post_ID}");
 
    return $wpdb->get_var("SELECT views FROM {$viewcounter_table} WHERE post_ID = {$post_ID}");
 
} // viewcounter_update

A primeira query checa se o retorno é vazio, e caso seja, chama a função viewcounter_insert() para inserir uma linha com 0 visualizações. Em seguida, executa um update incrementando em 1 o número de visualizações. E por último, retorna o número atual de visualizações do post.

Atualizando

Tudo que faltou agora, é indicar o ponto onde viewcounter_update() deve ser chamada. Na hierarquia dos templates, o ponto ideal para colocarmos nossa chamada é no arquivo single.php.
Bastaria uma simples chamada como:

<?php
$num = viewcounter_update($post->ID);
?>

E já teríamos o banco atualizado (claro, supondo que temos em $post o objeto com o post). Caso queiramos exibir o número atual de visualizações, podemos utilizar a variável $num em qualquer ponto do template para mostrar ao usuário quantas vezes aquele post foi visto.

Conclusão

Este foi apenas um exemplo, bem tosco, de como criar um template para o WordPress. É claro que ele pode ser melhorado, e muito. Inclusive, aceito sugestões nos comentários.
Estou disponibilizando um arquivo com este plugin, para quem quiser baixar e experimentar.

Artigos relacionados

• Removendo o “generator” do Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

Exemplo em PHP

O memcached pode ser acessado de muitas linguagens de alto nível, como C/C++, Java, Python, PHP, e até .NET. Abaixo, um exemplo em PHP.
Antes do memcache, uma página poderia ter uma consulta do seguinte tipo:

<?php
// A query SQL está abreviada, apenas como exemplo
// Digamos que essa consulte demore cerca de 1 segundo
// para ser completada
$sql = "SELECT * FROM tabela INNER JOIN ......";
$res = pg_query($sql);
$arr = pg_fetch_all($res); // array com todos os resultados
?>

Com esse código, a cada acesso na página, teremos uma consulta de 1 segundo feita ao banco de dados. Muitas vezes, a consulta será exatamente a mesma. Modificando a consulta para uso do memcached, teríamos algo assim:

<?php
// Conecta ao memcached
$mc = new Memcache;
$mc->addServer('ip.do.servidor');
 
$sql = "SELECT * FROM tabela INNER JOIN ......";
$cache = $mc->get(md5($sql)); // Usamos o md5() da query como chave
 
if ($cache === false) {
    // Resultado não está no cache
    $res = pg_query($sql);
    $arr = pg_fetch_all($res);
    $mc->set(md5($sql), $arr);
}
else {
    $arr = $cache;
}
?>

Pelo exemplo acima, temos algumas modificações. Primeiramente conectamos ao memcached. A chamada a addServer() pode ser feita múltiplas vezes, caso existam vários memcached rodando em máquinas separadas. Pode ser dado um “peso” pra cada servidor também, de acordo com a memória disponível em cada um.
Logo em seguida, é feita a verificação no memcached se o resultado da consulta já está lá. Como chave, usei o hash md5 da consulta, pra gerar uma identificação única. O método get() pode retornar false, caso a chave não esteja no memcached, ou retornar o objeto que foi guardado.
A checagem é simples. Se o get() retornou false, então o sistema faz a consulta como já fazia antes, e no fim guarda o resultado no memcached, pra agilizar as próximas consultas. E caso não tenha retornado false, temos já o resultado da consulta diretamente. Ao fim do bloco if, teremos, de uma forma ou de outra, o resultado da consulta em $arr.
A diferença é que rodando a consulta no banco, o tempo será de cerca de 1 segundo (tempo que estimamos para a execução da consulta), e pegando o resultado direto do memcached, a consulta demorará algo da ordem de milissegundos para ser completada.

Problemas

Um dos problemas clássicos em qualquer abordagem que use cache é como saber se as informações em cache ainda estão atuais. Com o memcached, isso não é diferente. Existem algumas formas de se lidar com o problema.
A primeira delas, mais simples, e que pode ser usada livremente caso não seja de suma importância que os dados estejam atuais, é mexer no tempo em que a informação ficará no cache. O tempo pode ser especificado na chamada ao método set(), da seguinte forma:

<?php
$mc->set(md5($sql), $arr, MEMCACHE_COMPRESSED, 60);
?>

Temos neste exemplo todos os parâmetros para a chamada de set(): a chave, o objeto a ser guardado, uma flag (pode ser usado MEMCACHE_COMPRESSED, que indica que o objeto será comprimido para ocupar menos espaço, ou 0 pra indicar que deve ser guardado sem compressão), e por último o tempo de vida do objeto, no caso, 60 segundos.
Ou seja, caso não haja problema das informações permanecerem desatualizadas por 60 segundos no máximo, essa abordagem pode ser usada.
Caso a informação tenha que estar sempre atualizada, a forma de tratamento terá que ser outra. O memcached possui método para apagar o objeto associado a uma chave. Tendo a chave, basta usar:

<?php
$mc->delete('chave');
?>

e a entrada que existia no memcached para aquela chave será invalidada.
A idéia, nesse segundo caso, é justamente localizar no código todos os pontos que modificam o banco de dados de forma que possa alterar o resultado da consulta feita, e adicionar código para invalidar o cache nesses pontos. Assim, quando for feita a consulta no memcached, caso alguma informação tenha sido modificada, a entrada correspondente no memcached já terá sido apagada, e a chamada a get() retornará false naturalmente.
É claro que essa segunda abordagem dá muito mais trabalho, por isso a sugestão de se usar a primeira delas nos casos em que pode ser usada. Lembre-se que em um site com 100 acessos por segundo, um tempo de vida de 60 segundos evitará 5999 consultas ao banco (a primeira será feita e guardada).

Mais informações

O site do projeto tem um Wiki que responde a maior parte das dúvidas que se pode ter, em relação a instalação e ao uso.
No caso do PHP, as funções são bem documentadas na parte do manual sobre memcache.
Eu uso em produção o memcached, com 2 servidores, um com 768mb de memória disponíveis para o memcached e outro com 256mb. Dei pesos 3 e 1 respectivamente, para que um objeto tenha 3 vezes mais chance de cair no primeiro servidor. A configuração está bastante satisfatória, e o banco de dados agradece.

Artigos relacionados

• Evitando SQL injection em PHP
• Otimização: imagens inline
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify
• Problemas com acentuação?
• O limite de 4 (ou 3?) Gb de memória

O problema

Digamos que na página principal do nosso site, a gente tenha um formulário de login mais ou menos assim:

<form action="login.php" method="post">
Login: <input type="text" name="login" />
Senha: <input type="password" name="senha" />
<input type="submit" />
</form>

Um formulário bem simples. E para tratar este formulário, temos o login.php, que vai checar em um banco de dados se o login e a senha estão corretos, da seguinte forma (colocarei apenas o trecho com a consulta SQL relevante):

<?php
$sql = "SELECT * FROM usuarios WHERE login = '{$_POST['login']}' AND senha = '{$_POST['senha']}'";
$res = mysql_query($sql);
if (mysql_num_rows($res) > 0) {
    print "Login OK";
}
else {
    print "Login e senha não conferem";
}
?>

Ou seja, verificamos na tabela usuarios se temos uma linha com o login e a senha fornecidos. Caso essa consulta retorne alguma coisa, significa que existe uma linha com o login e a senha fornecidos, caso contrário, não existe.
Se no formulário eu preencho o login com “joe” e a senha com “xxxx”, a seguinte consulta SQL será montada e executada:

SELECT * FROM usuarios WHERE login = 'joe' AND senha = 'xxxx'

Porém, o que acontece se eu preecher o formulário com o login = joe, e a senha com: xxxx’ OR true –
Neste caso, teremos a seguinte consulta:

SELECT * FROM usuarios WHERE login = 'joe' AND senha = 'xxxx' OR true --'

Essa consulta vai retornar todas as linhas do banco de dados (por causa do “OR true” no final), e como a checagem no código é se a consulta retornou mais de uma linha, estaremos logados.
Existem formas mais sofisticadas de proceder com este tipo de ataque, mas o foco do artigo é na defesa.

FIEO

FIEO é uma técnica bastante usada para aumentar a segurança dos aplicativos web. Significa “Filter Input/Escape Output”, ou traduzindo, “Filtre a Entrada/Escape a Saída”.
O primeiro passo é a filtragem da entrada, já que a regra número 1 da segurança em aplicativos web diz que não podemos jamais confiar em informações vindas de fontes externas. No nosso caso, poderíamos fazer a filtragem do login e da senha checando se eles possuem apenas caracteres permitidos. Por exemplo, o site poderia ter uma regra especificando que o login deve conter apenas letras e números. A filtragem então, poderia ser feita usando a função ctype_alnum():

<?php
if (!ctype_alnum($_POST['login'])) {
    die("login possúi caracteres inválidos");
}
?>

Se o FI do FIEO lida com a filtragem da entrada, o EO lida com a manutenção da saída no contexto em que for lida.
Ou seja, FI garante que a nossa entrada é valida, e EO garante que quem quer que receba os nossos dados, irá interpretá-los da forma correta.
No nosso caso, é importante que as aspas simples não sejam interpretadas como delimitadores na consulta SQL. E se eu quisesse ter uma senha que tivesse uma aspa simples no meio?
Existem 3 formas clássicas de se resolver este problema.

Forma 1: addslashes() no PHP

É a forma mais simples (e ingênua) de se tratar o problema. Por exemplo, se queremos nos proteger das aspas simples, poderíamos simplesmente escapá-las no PHP da seguinte forma:

<?php
$login = addslashes($_POST['login']);
$senha = addslashes($_POST['senha']);
?>

Dessa forma, caso uma aspa simples chegasse do usuário, seria devidamente escapada com uma “\” antes, e o servidor SQL não iria interpretá-la como um delimitador.
Para o nosso exemplo de ataque, resolveria.
O grande problema com esta solução é que ela só prevê ataques que usem aspas simples. Bancos de dados diferentes podem usar caracteres de controle diferentes, como aspas duplas, quebras de linha, ou outras coisas mais estranhas. E checar por todas estas formas é longe de ser a maneira mais eficaz (e viável!) de se proceder.
Temos uma outra opção, suportada por vários bancos de dados.

Forma 2: deixar o próprio banco escapar

A segunda opção é passar a string para o banco e deixar ele se virar. Afinal, ele sabe o que pode e o que não pode entrar em uma string. No MySQL, isso poderia ser feito da seguinte forma:

<?php
$login = mysql_real_escape_string($_POST['login']);
$senha = mysql_real_escape_string($_POST['senha']);
?>

Segundo a documentação, chamando esta função, o banco escapa automaticamente as seguintes sequencias: \x00, \n, \r, \, ‘, ” e \x1a. Ou seja, pelo visto as aspas simples não eram nosso único problema mesmo.
Existem funções semelhantes para outros bancos de dados (por exemplo, pg_escape_string() para o PostgreSQL).
Porém, a solução que considero mais elegante é usar consultas preparadas.

Forma 3: consultas preparadas

A idéia de se preparar uma consulta é dizer ao banco de dados o formato da consulta (apenas os parâmetros formais), e fazer a amarração dos parâmetros reais somente na hora da execução.
A maior parte dos bancos de dados suportam consultas preparadas, mas vou mostrar o exemplo usando MySQL, devido a popularidade.

<?php
$dbh = new mysqli("localhost", "ususario", "senha", "banco");
$c = $dbh->prepare("SELECT * FROM usuarios WHERE login = ? AND senha = ?");
$c->bind_param("login", $_POST['login']);
$c->bind_param("senha", $_POST['senha']);
$c->execute();
?>

Ou seja, primeiro informamos ao banco qual será a consulta a ser executada. Perceba que usamos interrogações no lugar dos parâmetros reais. Com isso, o banco prepara a consulta pra ser executada.
Logo em seguida, dizemos ao banco o valor que cada parâmetro irá receber. Esta etapa se chama amarração (binding). Como o banco de dados sabe o tipo de cada campo, ele também sabe como proceder pra escapar corretamente cada valor.
E por último, executamos a consulta. Simples, fácil e seguro!

Conclusão

SQL Injection é um problema sério que afeta muitos aplicativos web por aí afora, porém é um problema que só existe por causa da ingenuidade dos programadores, que não programam pensando em segurança. A solução, como vimos, é bem simples.

Artigos relacionados

• Criando CAPTCHAs em PHP
• Segurança no envio de emails em PHP
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Os 10 piores CAPTCHAs do mundo
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Evitando spam em formulários
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP

<img src="imagem.png" />

ou então, podemos carregá-la como imagem de fundo de um elemento qualquer usando CSS:

.classe { background-image:url(imagem.png); }

Um dos problemas em páginas que possuem muitas imagens é que cada imagem requer a abertura de uma nova conexão HTTP, e com a limitação de 2 conexões por host (é uma restrição dos navegadores que seguem a especificação HTTP), o tempo de carga da página pode acabar crescendo bastante.

A lógica

Uma solução para este problema é ao invés de carregar as imagens externas, colocá-las diretamente dentro da página, seguindo a mesma lógica que já usamos com CSS. Por exemplo, podemos especificar uma folha de estilo externa:

<link rel="stylesheet" type="text/css" href="arquivo.css" />

ou então podemos colocar os estilos inline:

<style type="text/css">
.classe1 { font-color:#f00; }
#id2 { width:200px; }
</style>

Codificando a imagem

Até aí, tudo bem, afinal CSS é texto, e texto entra bem dentro de uma página. Mas como colocar uma imagem dentro de uma página, uma vez que a imagem é binária?
Simples! Primeiro, codificamos a imagem de binário para ASCII usando a codificação base64. Existem várias formas de se fazer isso, e boa parte das linguagens de programação disponibiliza funções para fazer esta codificação. Por exemplo, em PHP, podemos fazer:

<?php
print base64encode(file_get_contents("arquivo.png"));
?>

A saída disso é algo mais ou menos assim:

iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6
YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AF
uALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==

Pronto, já temos a representação codificada da imagem.
Para que a saída coubesse na tela, quebrei a saída em 3 linhas. A saída real é toda em uma só linha, mas como veremos adiante, tanto faz, pois podemos usar quebras de linha.

URLs do tipo “data”

Antes de colocarmos a imagem dentro da página, precisamos ver como funcionam as URLs do tipo “data”. A URL segue o seguinte formato:

data:[<tipo MIME>][;charset="<charset>"][;base64],<dados>

onde:

• tipo MIME é o tipo do arquivo que vamos colocar, no nosso caso, image/png;
• charset é a codificação utilizada, para o caso de arquivos texto (não usaremos no nosso exemplo).
• base64 é a codificação utilizada. Se for omitida, o navegador entenderá que estamos usando US-ASCII, e no caso de imagens, não vai dar certo;
• e por último, dados contém a string com o arquivo codificado (aquela sequencia grande de caracteres ali de cima). A string pode ser quebrada com espaços ou quebras de linha.

Juntando tudo

Pois bem, agora que temos a representação codificada da imagem e já sabemos usar URLs do tipo “data”, podemos colocá-la diretamente na página, usando a própria tag img:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAxYAAAAKCAAAAAAMKZc
GAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0AIAwEMZT9F4Uh8vTUFCDZM9zV6n
yt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7UZ3wAAAABJRU5ErkJggg==" />

Ou então uma regra de CSS, da seguinte forma:

.classe { background-image:url(data:image/png;base64,iVBORw0KGgoAAAANSUh
EUgAAAxYAAAAKCAAAAAAMKZcGAAAACXZwQWcAAAMWAAAACgALWq6YAAAAOklEQVRYw+3TsQ0
AIAwEMZT9F4Uh8vTUFCDZM9zV6nyt08kMXOypBnCwBdgCbAG2AFuALcAWYAt4xQZXmxLmG7U
Z3wAAAABJRU5ErkJggg==); }

É claro que usar esta técnica, como quase tudo na vida, tem várias vantagens e desvantagens.

As vantagens

Temos várias vantagens em usar um esquema deste tipo:

• Suporte na grande maioria dos navegadores modernos: Firefox, Opera, Safari, Konqueror e Chrome;
• Antes de mais nada, estamos diminuindo o número de requisições HTTP, e consequentemente, evitamos o tráfego associado à requisição (cabeçalhos HTTP);
• Como a imagem está inline, conseguimos “fugir” do limite de 2 conexões por host, já que estamos evitando a abertura de novas conexões;
• Para imagens pequenas, temos um ganho real em bytes transferidos, pois embora a imagem codificada em base64 fique maior, estamos evitando de enviar os cabeçalhos HTTP (que somam em média 200 bytes).
• Conexões seguras (que usam https) só mostram o “cadeado” fechado se todos os elementos externos forem carregados através de https também. E o overhead associado a uma conexão https é bem maior que o de uma conexão http normal. Com a imagem inline, ganhamos mais um pouco.

As desvantagens

Temos várias desvantagens, algumas contornáveis:

• Internet Explorer até a versão 7 não tem suporte. Só a partir do 8. A forma de se usar para os dois navegadores é usando arquivos CSS separados para cada navegador (ou um pré-processador de CSS que detecte o navegador e dê a saída com o que for suportado);
• Imagem inline em uma página (usando tag img) não são cacheadas pelo navegador. Se usada dentro do CSS, aí sim teremos o cache em ação, pois o navegador irá cachear o CSS;
• Uma imagem codificada em base64 tem seu tamanho aumentado em 33%. Para imagens grandes, é uma perda considerável, mas para imagens pequenas (da ordem de 500 bytes), temos um ganho, pois mesmo com o aumento da imagem, estamos evitando o envio dos cabeçalhos, e podemos sair ganhando na soma;
• Dificuldade de manutenção: se uma imagem é alterada, ela precisa ser recodificada. Existem formas de se automatizar isso.

Um exemplo

A imagem que aparece aqui embaixo está inline, e foi colocada usando uma tag img (a qualidade está baixa pra não ficar muito grande):

Clicando o botão direito na imagem e escolhendo “Exibir imagem” (no Firefox ou em outro navegador que dê suporte), dá pra se ver na barra de endereços a URL usada pra criar a imagem.
E claro, se você não está vendo imagem nenhuma, provavelmente está usando o Internet Explorer. E já passou da hora de passar a usar um navegador decente, que suporta os padrões web, não é?

Artigos relacionados

• Evitando conteúdo duplicado
• Otimização de sites com memcached
• Otimização de sites, parte 3 – Cache
• Otimização de sites, parte 2 – Compressão
• Otimização em PHP, parte 1: Minify

Como funciona na teoria?

O funcionamento de um CAPTCHA de letras tortas é bem simples. O servidor gera uma string que será transformada em uma imagem. A string é salva em algum lugar (normalmente em uma variável de sessão). A imagem é apresentada dentro de um formulário. Ao submeter o formulário, o script checa se o que o usuário digitou bate com o conteúdo da variável de sessão. Se bater, o usuário passou no teste.
Na teoria, tudo muito simples.

Mas e na prática?

Na prática, tudo também pode ser igualmente simples. Ao invés de reinventar a roda, podemos utilizar uma classe chamada Securimage, que serve justamente para gerar CAPTCHAs.

Securimage

Securimage é uma classe em PHP que utiliza a biblioteca gráfica GD para gerar imagens com CAPTCHAs. A classe é bastante versátil, e suporta várias opções, como fontes TTF, imagens de fundo, linhas, arcos e bem mais.
O primeiro passo é baixar o pacote com a versão mais recente e descompactá-lo em algum lugar. A partir deste ponto, vou assumir que o pacote foi descompactado em uma pasta chamada “securimage” no diretório raiz do site.

Criando o form com a imagem

Dentro do formulário que se deseja proteger, colocamos uma tag img, que irá conter a imagem gerada pelo Securimage:

<img id="captcha" src="/securimage/securimage_show.php" alt="CAPTCHA" />

Este script securimage_show.php é bem pequeno (3 linhas), e irá criar um CAPTCHA com as opções padrões da classe. Veremos mais adiante algumas formas de se customizar a imagem.
Além da imagem, também precisamos de um campo para o usuário digitar as letras contidas na imagem:

<input type="text" name="captcha_txt" />

E com isso o formulário está pronto.

A checagem no backend

O usuário viu a imagem, digitou os dados e submeteu o formulário. Agora é hora de checar se o código digitado bate com o texto contido na imagem.
Logo no início do script que recebe os dados do formulário (em caso de dúvida, veja o atributo action da tag form), é preciso inicializar as variáveis de sessão:

<?php session_start(); ?>

É importante que este código venha antes de qualquer saída, ou teremos um erro do tipo “Cannot modify header information – headers already sent….”. Na dúvida, coloque logo no início.
O restante da checagem é bastante simples. Basta instanciarmos um objeto da classe Securimage e chamar um método que faz a checagem:

<?php
require_once $_SERVER['DOCUMENT_ROOT'] . '/securimage/securimage.php';
$securimage = new Securimage();
 
if ($securimage->check($_POST['captcha_txt'])) {
    // Código digitado corretamente
    die("Ok, o código foi digitado corretamente.");
}
else {
    // Código digitado não bate com a imagem
    die("Erro: código incorreto.");
}
?>

O exemplo acima apenas ilustra como é feita a checagem. As chamadas a die() devem ser substituídas de acordo com a lógica da página onde o CAPTCHA está sendo inserido. No caso do código estar correto, deve-se prosseguir com o processamento do formulário, e caso não esteja, possivelmente exibir novamente o formulário com uma mensagem de erro. Será gerado um novo CAPTCHA automaticamente.

Outras opções

Como dito anteriormente, a classe é bastante versátil, e suporta diversas opções para a geração das imagens. Todas as opções estão descritas na documentação da classe, mas vou transcrever várias das opções aqui.
Para se customizar a imagem, basta editar diretamente o script securimage_show.php, que é o script usado na tag img. Originalmente, ele é apenas o seguinte:

<?php
include 'securimage.php';
$img = new securimage();
 
$img->show();
?>

Podemos passar opções para a classe antes de chamar o método show(). Apenas para ilustrar, aqui vai um exemplo bem customizado:

<?php
include 'securimage.php';
$img = new securimage();
$img->code_length = 8; // 8 ao invés de apenas 4 caracteres
$img->charset = "AEIOU"; // Apenas vogais
$img->image_width = 280; // Padrão é 175px para 4 caracteres
$img->multi_text_color = "#ff0000,#0000ff"; // Letras azuis e vermelhas
$img->image_bg_color = "#ffff00"; // Fundo amarelo
$img->show();
?>

E abaixo, 3 exemplos de CAPTCHAs gerados por este script:

Como já dito, a classe suporta muitas outras opções, o melhor mesmo é ler a documentação caso se deseje customizar mais.

Artigos relacionados

• Evitando SQL injection em PHP
• Os 10 piores CAPTCHAs do mundo
• Segurança no envio de emails em PHP
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Evitando spam em formulários
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP

Comparação em ponto flutuante

As variáveis do tipo float sofrem de um problema de precisão, pois dependendo do número, ele pode não ter uma representação binária (em potências de 2) exata. Para nos resolver, o PHP (e a grande maioria das linguagens) faz o arredondamento do número. Por exemplo, se fizermos o seguinte teste:

<?php
var_dump(0.1 + 0.2 == 0.3); // saída:  bool(false)
?>

Claro que, matematicamente falando, 0.1 + 0.2 é igual a 0.3. Porém, a forma como o PHP guarda esses números internamente não é exata. Para vermos como o PHP guarda cada um desses números, podemos chamar a função serialize():

<?php
print serialize(0.1); // d:0.1000000000000000055511151231257827021181583404541015625;
print serialize(0.2); // d:0.200000000000000011102230246251565404236316680908203125;
print serialize(0.3); // d:0.299999999999999988897769753748434595763683319091796875;
?>

E fazendo a conta, fica evidente que 0.1 + 0.2 não dá 0.3. E então, como fazer para comparar variáveis do tipo float sem chance de errarmos?
Uma forma é definir uma constante, que por convenção chamarei de EPSILON, que terá o valor do menor número fracionário possível. Qual valor colocar? Depende da aplicação! Se sua aplicação mexe com valores financeiros, normalmente você precisa se preocupar com frações de 2 ou 3 casas decimais no máximo. Podemos então definir o EPSILON, com uma boa margem de segurança, para 1e-5, ou seja, 0.00001.
Tendo esta constante, se queremos checar se dois números são iguais, podemos simplesmente checar se a diferença entre eles é menor que EPSILON. Caso seja menor, podemos considerar os números iguais. Da mesma forma, podemos fazer a comparação entre floats da mesma forma.
Uma função simples, que tem o retorno semelhante à função de comparação de strings strcmp(), mas que serve para comparar floats poderia ser definida assim:

<?php
define("EPSILON", 1e-5);
 
function floatcmp($a, $b) {
    $diff = abs($a-$b);
    if ($diff < EPSILON) {
        return 0;
    }
    return ($a<$b) ? -1 : 1;
}
?>

Esta função recebe dois números como parâmetro. Se os números forem iguais, ou seja, se a diferença entre eles for menor que a nossa margem de erro aceitável EPSILON, a função retorna 0, caso contrário retorna -1 se o primeiro número for menor, ou então 1 caso o segundo seja o menor. Bastante simples e eficaz.
Para fazermos o teste acima, podemos agora proceder assim:

<?php
if (floatcmp(0.1+0.2, 0.3) == 0) {
    print "são iguais";
}
else {
    print "são diferentes";
}
?>

O resultado, como esperado, será “são iguais”.

Números começados com zero

Outro problema muito comum, principalmente quando estamos lidando com datas, é o da comparação de números iniciados com 0. Por exemplo:

<?php
var_dump(09 == 9); // saída:  bool(false)
?>

Isto ocorre porque o PHP trata qualquer número iniciado com 0 como um número octal, ou seja, na base 8. Caso o número não seja um octal válido, a conversão para no primeiro dígito inválido. No caso acima, 09 vira 0 (pois não existe 9 na base octal).
Para fazer esta comparação, uma das formas seria a seguinte:

<?php
var_dump("09" == 9); // saída:  bool(true)
?>

Agora, temos a string “09″, que será convertida no inteiro 9 (base 10 mesmo) antes da comparação, e aí sim, o resultado será o esperado.

Busca de strings com strpos()

É muito comum usarmos a função strpos() para buscarmos strings. O formato da função é:

int strpos (string $haystack, mixed $needle  [, int $offset=0 ] )

onde haystack é onde estamos fazendo a busca, e needle é o que queremos encontrar. O retorno desta função é a posição onde a string foi encontrada, ou false caso ela não seja encontrada. O terceiro parâmetro, opcional, serve para informar a partir de que posição queremos fazer a busca.
Façamos o seguinte teste:

<?php
if (strpos('abcdefg','abc')) {
    print "encontrei";
}
else {
    print "não encontrei";
}
?>

A saída deste exemplo é “não encontrei”, mesmo com a string “abc” tendo sido encontrada na string “abcdefg”. O grande problema, neste exemplo, é que a string foi encontrada na posição 0. Logo, a função strpos() retorna 0. E o valor 0, em uma comparação booleana, é equivalente a false, e por isto o resultado acaba não sendo o esperado.
A forma correta de se fazer este teste é utilizando o operador ===, que além de checar o valor, também checa o tipo do retorno. Podemos fazer assim:

<?php
if (strpos('abcdefg','abc') !== false) {
    print "encontrei";
}
else {
    print "não encontrei";
}
?>

E agora, teremos o resultado esperado “encontrei”.

Existem várias outras “pegadinhas” no PHP (já escrevi por exemplo, sobre os operadores and e or, no artigo sobre precedência), que muitos podem considerar como bug ou algum problema sério da linguagem, mas a maior parte dos problemas tem uma explicação lógica.
Retirei parte dos exemplos de um post na Zend Developer Network, e como passei por problemas com floats recentemente, achei que seria interessante compartilhar.
Caso alguem tenha mais algumas “pegadinhas” para compartilhar, fique a vontade para fazer um comentário.

Artigos relacionados

• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

Existem alguns fatores que influenciam no tempo de carregamento de uma página:

• Tamanho total dos dados
• Tempo de geração da página
• Número de conexões HTTP necessárias

O tamanho total dos dados é de extrema importância, pois quanto mais dados pra se transferir (páginas, imagens, folhas de estilo, scripts externos, etc), maior o tempo de carregamento de uma página. O tempo de geração também é importante, e este tempo depende de uma programação eficiente e de um banco de dados rápido.

Porém, o número de conexões necessárias é frequentemente esquecido, e é um fator de extrema importância para que uma página seja carregada rapidamente.

Para entendermos o porque, precisamos saber o que o navegador faz quando pedimos para ele abrir uma página.

Primeiramente, é realizada uma consulta ao servidor DNS para se determinar o endereço do servidor que estamos tentando acessar. Esta consulta leva algum tempo, mas normalmente é cacheada pelo navegador uma vez feita. Num segundo passo, temos a primeira conexão, que baixa a página que foi pedida.

Após a busca da página, o navegador analisa sua estrutura, e busca elementos externos necessários, como imagens, folhas de estilo (CSS), scripts, arquivos de Flash, etc etc.

Cada elemento externo a ser baixado exige a abertura de mais uma conexão HTTP (nem sempre… existe pipelining e outras coisas que melhoram isso, mas pra simplificar, vou ignorar por enquanto). Cada conexão, para ser estabelecida, leva um tempo antes da transferência de dados ser iniciada. Este overhead gera um atraso, visto que muitas vezes, dependendo do tamanho do arquivo, o tempo para se estabelecer a conexão chega a ser maior que o tempo para se baixar o arquivo.

Some-se a isso uma regra que diz que navegadores devem abrir no máximo 2 conexões simultâneas por host. Ou seja, se a página possui 30 elementos externos a serem baixados, as conexões serão estabelecidas duas a duas até que os 30 sejam completados. Algo que se pode fazer para melhorar isto é dividir os elementos externos em alguns hosts diferentes, já que a regra manda 2 conexões por host, mas isto fica para mais adiante.

Muitas vezes, uma página possui vários arquivos CSS e vários scripts em JavaScript. Ao invés de utilizar, digamos, 5 tags para se carregar 5 arquivos CSS diferentes, e mais 10 tags para carregarmos 10 scripts externos, não seria muito melhor se pudéssemos abrir apenas duas conexões, e baixar todo o CSS em uma, e todo o JavaScript em outra? E melhor, que ao fazer isto eles já viessem “condensados”, de forma a diminuir seu tamanho?

Pois bem, a idéia do Minify é justamente fazer isto. O Minify é um script em PHP que recebe uma lista de arquivos como parâmetro (CSS ou JavaScript) e “junta” todos eles em um único download (ele faz mais, mas para mais detalhes, veja direto na página do Minify).

Para fazer a instalação, tudo muito simples. Basta descompactar o arquivo na raiz do site, e fazer algumas modificações nas tags. Ao invés de termos:

<script type="text/javascript" src="/js/script1.js"></script>
<script type="text/javascript" src="/js/script2.js"></script>
<script type="text/javascript" src="/js/script3.js"></script>
<script type="text/javascript" src="/js/script4.js"></script>
<script type="text/javascript" src="/js/script5.js"></script>

passamos a ter somente:

<script type="text/javascript" src="/min/?f=/js/script1.js,/js/script2.js,/js/script3.js,/js/script4.js,/js/script5.js"></script>

Ou seja, chamamos somente o “/min/”, e passamos como parâmetro (chamado f) uma lista com os scripts, separados por vírgulas, e o Minify se encarrega do resto. Com o CSS, a mesma coisa. Ao invés de termos:

<link rel="stylesheet" type="text/css" href="/css/style1.css" />
<link rel="stylesheet" type="text/css" href="/css/style2.css" />
<link rel="stylesheet" type="text/css" href="/css/style3.css" />
<link rel="stylesheet" type="text/css" href="/css/style4.css" />
<link rel="stylesheet" type="text/css" href="/css/style5.css" />

teremos somente:

<link rel="stylesheet" type="text/css" href="/min/?f=/css/style1.css,/css/style2.css,/css/style3.css,/css/style4.css,/css/style5.css" />

Apenas usando o Minify, já podemos conseguir baixar o número de conexões HTTP necessárias para se carregar a página inteira, e com isso, diminuir o tempo total.

Um site interessante, que fornece um mapa com todos os elementos do site, assim como o tempo de carregamento de cada um é o Full Page Test do Pingdom. O tempo de cada elemento é dividido em 3: tempo para se começar, tempo para se estabelecer a conexão e a transferência em si. Olhando bem, dá pra perceber que o tamanho das páginas (parte azul da barra) tem uma influência menor do que o número de conexões.

Existem outras técnicas, que podem ser usadas em conjunto com o Minify para melhorar ainda mais, mas ficarão para os próximos artigos da série.

Artigos relacionados

• Otimização de sites, parte 2 – Compressão
• Otimização de sites, parte 3 – Cache
• Removendo o “generator” do Wordpress
• Envio de emails em massa
• Escrevendo plugins para o Wordpress
• Otimização de sites com memcached
• Evitando SQL injection em PHP
• Otimização: imagens inline
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Precedência no PHP
• Acessando sites fora do ar
• Páginas de manutenção
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

<?php
$a = $expressao1 && $expressao2;
?>

O valor da variável $a será verdadeiro, se tanto $expressao1 e $expressao2 forem simultaneamente verdadeiras, e será falso caso uma das duas seja falsa.

Da mesma forma, temos o operador and, que da mesma forma que o &&, também funciona como um “e” lógico. A diferença está na precedência. O operador && é processado antes de uma atribuição, enquanto que o operador and é processado depois.

Para ilustrar, podemos fazer o seguinte teste:

<?php
$a = true && false;
$b = true and false;
var_dump($a);
var_dump($b);
?>

Se alguem achar que ao executar este código, tanto $a quanto $b valerão false, abra o PHP e execute para tirar a prova. Teremos $a valendo false, e $b valendo true, o que na verdade era de se esperar.

Para $a, o PHP processa a expressão (true && false), e atribui seu resultado (false) a $a. No caso de $b, a atribuição tem precedência, então o PHP processa primeiro a expressão “$b = true”, e depois disso faz o “e lógico” com o false (que dá false, mas não é guardado em lugar algum). Ou seja, a precedência fez a diferença neste caso. Poderíamos escrever o código da seguinte forma, para facilitar o entendimento:

<?php
$a = (true && false);
($b = true) && false;
var_dump($a);
var_dump($b);
?>

E da mesma forma que temos os dois operadores (&& e and), também temos os operadores || e or. A diferença entre os dois é a mesma que no caso do “and”, ou seja, apenas a precedência em relação ao operador de atribuição.

Ilustrando:

<?php
$a = false || true;
$b = false or true;
var_dump($a);
var_dump($b);
?>

Ou seja, da mesma forma que o exemplo anterior, teremos $a valendo true (pois um dos dois valores é verdadeiro), e $b valendo false, pois primeiro é feita a atribuição, e depois processado o “ou”.

Em caso de maiores dúvidas, a seção de operadores lógicos do manual do PHP certamente irá tirar qualquer dúvida.

Para quem pretende estudar para fazer a prova de certificação da Zend, é uma boa saber desses pequenos detalhes, pois a prova tem várias pegadinhas que podem pegar os desavisados.

Artigos relacionados

• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Imprimindo em formulários contínuos em PHP
• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Envio de emails em PHP
• Validação de dados em PHP
• Segurança no envio de emails em PHP

A solução que eu usei pra resolver um problema de impressão de notas fiscais foi usar uma classe do PEAR chamada File_PDF, que como o próprio nome já deixa claro, serve para gerar arquivos PDF.

Como todos sabemos, o formato PDF é ideal para situações em que precisamos ter certeza de que ele sempre será impresso da mesma forma, independente da máquina onde é aberto. O problema em usar outros formatos (DOC do Word, por exemplo), é que as informações necessárias para a impressão não ficam no arquivo. Detalhes como as fontes usadas, os tamanhos, acabam dependendo de configurações de cada máquina.

Voltando ao problema, eu tinha um formulário de 10 páginas para testes, com um tamanho não muito usual, e os campos da nota fiscal que eu precisaria preencher.

Pra resolver o problema do posicionamento, não tem outro jeito, tem que medir com régua mesmo. A idéia é anotar as posições X e Y de cada campo, usando milímetros pra evitar números fracionários. O tamanho do papel também se mede com régua, não tem muito mistério.

Tendo o tamanho do papel e o posicionamento de cada campo, o grande truque é gerar um PDF dinamicamente, com “páginas” do tamanho da nossa nota fiscal, e depois posicionar os textos dentro dessa página.

No fim do script, teremos um PDF já todo pronto pra ser mandado para a impressora, tudo já formatado com o tamanho e posição corretas.

Segue o código, por partes.

<?php
require_once 'File/PDF.php';
 
$pdf = File_PDF::factory(Array('orientation' => 'P',
                               'unit' => 'mm',
                               'format' => Array(206,165)
                        ));
$pdf->setFont('Courier','',10);
?>

Até aqui, sem muitos mistérios. Incluí o arquivo da classe File_PDF, e instanciei um objeto em $pdf. A orientação do documento é P (de Portrait, ou “em pé”), a unidade que eu vou usar será milímetros, e o formato da minha folha é de 206 mm de altura por 165 mm de largura. Depois disso, eu escolho a fonte Courier 10 para o documento inteiro.

<?php
foreach ($venda as $item) {
$pdf->addPage('P');
$pdf->text(171,44,$item['nome_cliente']);
$pdf->text(171,49,'Prest. Serv.');
$pdf->text(171,57,$item['data']);
...
 
}
?>

Agora, eu percorro um vetor ($venda) já criado com as informações que eu precisarei colocar na nota fiscal. Para cada entrada desse vetor, eu crio uma nova página com a mesma orientação (em pé). A partir daí, é só posicionar cada texto. Em 171 x 44, coloco o nome do cliente, em 171 x 49, a natureza da operação, em 171 x 57, a data da venda, e por aí vai.

<?php
header("Content-type: application/pdf");
$pdf->output('notas.pdf',false);
?>

Para terminar, dou a saída do documento. Marco o tipo da saída para “application/pdf”, e mando o objeto soltar o documento para o navegador com o nome de “notas.pdf”. O segundo parâmetro é se a saída é inline ou como um arquivo para download. Passamos false para que o navegador entenda que o PDF é para ser baixado.

Se tudo deu certo, o navegador vai perguntar se você quer abrir ou salvar o PDF. Se abrir em algum programa como o Adobe Reader, basta imprimir diretamente do programa, e bingo. Resolvida a questão.

Artigos relacionados

• XML no PHP com XML_Serializer, parte 2 de 2
• XML no PHP com XML_Serializer, parte 1 de 2
• Validação de dados em PHP
• Removendo o “generator” do Wordpress
• Escrevendo plugins para o Wordpress
• Evitando SQL injection em PHP
• Criando CAPTCHAs em PHP
• Pegadinhas no PHP
• Otimização em PHP, parte 1: Minify
• Precedência no PHP
• Envio de emails em PHP
• Segurança no envio de emails em PHP