como configurar o módulo CDN do Drupal para ignorar algumas urls

a complexa arte de escrever documentação clara e coerente

hoje passamos por uma situação atípica em um projeto Drupal de um cliente nosso: temos tudo configurado da melhor forma possível: dois servidores web na amazon, balanceados com load balancer, usando uma cdn para servir arquivos estáticos. E também um requisito de cortar imagens manualmente, que é muito bacana.

eis que, para funcionar adequadamente nesse cenário, as imagens que são cortadas imediatamente após upload, precisam estar disponíveis no domínio servido pela CDN em questão de segundos, mas isso dificilmente é conseguido nas CDNs, então precisávamos de uma alternativa

eis que o excelente módulo de cdn do drupal permite criar "listas negras", tanto globais como para usuários autenticados. Estaria resolvido nosso problema!

Não fosse um detalhe bastante ardiloso: a configuração do módulo CDN usa a seguinte frase para descrever o campo de "lista negra" dos usuários autenticados:

Drupal paths entered in this blacklist will not serve any files from the CDN. This blacklist is applied for authenticated users only.

O pior é, na verdade, o exemplo dado:

Example file patterns are *.js for all JavaScript files and mytheme/*.css for all CSS files in the mytheme directory.

Nosso primeiro pensamento foi: maravilha! basta colocarmos *.jpg para ignorar imagens para os usuários logados!

Porém, nem tudo são flores! Na verdade, a configuração pede em quais url do Drupal o processamento de urls da CDN será evitado: neste caso, a configuração mais correta é algo como node/*/edit, ou seja, qualquer página de edição de conteúdo

Drupal 7 - Como mover os módulos para uma outra pasta

É comum, para organizarmos um projeto existente, feito fora da Itelios, re-estruturarmos as pastas do projeto para seguir as boas práticas

Uma dica muito valiosa para quem quer mover os módulos da sua instalação de Drupal 7 de uma pasta para outra, normalmente para uma das pastas contrib, custom ou features é usar o comando drush "registry_rebuild".

Os passos são simples:

  1. drush dl registry_rebuild
  2. Mova os módulos (se mover antes do comando acima, pode ter falha na execução)
  3. drush rr

Simples assim!

Caso você não possa usar drush, na página do projeto existem instruções para rodar o comando sem drush. 

 

Drupal 7 - Criando pop-ups facilmente com o módulo Splashify

Colocar uma Splash Screen no seu site é uma ótima forma de espantar ou incomodar os seus usuários

Se, ainda assim, você insistir nisso, e sei bem como a teimosia humana não tem limites, existe uma forma bastante "drupal-way" de fazer a coisa: módulo Splashify

É um módulo simples que permite criar uma página, seja na forma de redirect, seja na forma de lightbox, funcionando como página "Splash", ou seja, página de entrada para sua aplicação

Um caso de uso válido é qdo vc precisa fazer um anúncio realmente importante para todos os seus usuários. Então, ao invés de pedir para o desenvolvedor criar um módulo custom com uma mensagem fixa, ou ainda desenvolver tudo do zero, que tal usarmos esse módulo e economizar um pouco de energia? O mundo agradece!

 

Instalando e Configurando o XDebug com NetBeans usando Vagrant e Drupal 7

Porque ferramentas de debug são fundamentais para desenvolvimento php profissional (lembro de um amigo que dizia que nenhum código está suficientemente bem testado enquanto não passar por um debug)

Se você tem um ambiente com vagrant bem configurado (ou equivalente), como é o caso dos devs da Itelios, então a coisa é tão simples quanto:

No Netbeans, botão direito no seu projeto, escolha Propriedades. Selecione Run Configuration no painel da esquerda e clique em Advanced no painel central.

Agora mapeie a pasta do seu vagrant para a pasta local do seu computador:

Pronto!  Foi muito fácil não? Agora se você não tem um vagrant tão bem configurado assim, você talvez precise instalar e configurar o Xdebug, vamos lá:

Instalar XDebug

Basta rodar o comando:

sudo pecl install xdebug

Configurar XDebug

Para isso, crie um arquivo xdebug.ini na pasta /etc/php5/conf.d, com o seguinte conteúdo:

zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so

xdebug.remote_connect_back=1
xdebug.default_enable=1
xdebug.remote_autostart=0
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.max_nesting_level = 200
xdebug.remote_host=10.0.2.2

A primeira linha desse arquivo contém um path meio estranho. Acredito que no momento da instalação da extensão o PEAR deve dizer qual o path no qual ele instalou a extensão. Se você não reparou ou caso ele não diga, você pode descobrir o path do seu xdebug através de:

 find / -name 'xdebug.so' 2> /dev/null

Esse comando demora um pouco para executar, e se você tiver mais de uma versão de xdebug instalado, eu usaria a mais recente.

Agora, basta reiniciar o seu Apache com sudo service apache2 restart e clicar no botão Debug do NetBeans (ou Ctrl+F5).

Ah! Não se esqueça de fazer os passos do início deste post para configurar seu NetBeans!

Instalando e Configurando o profiler XHProf no PHP Apache e Drupal 7

Um profiler é ferramenta essencial para desenvolvimento profissional em PHP

Instalar o XHProf é bastante trivial:

 sudo pecl install xhprof

Mas aí você pode cair neste erro aqui:

Failed to download pecl/xhprof within preferred state "stable", latest release is version 0.9.4, stability "beta", use "channel://pecl.php.net/xhprof-0.9.4" to install
install failed

Mas não tema, basta configurarmos nosso PEAR para buscar pacotes beta e lá vamos nós:

sudo pecl config-set preferred_state beta
sudo pecl install xhprof

Normalmente isso é o suficiente para instalar o xhprof. Se você tiver qualquer problema diferente, coloque nos comentários abaixo que vou tentar criar uma base de conhecimento a respeito da instalação do xhprof.

Acho bom voltar à configuração padrão do PEAR para stable, então:

sudo pecl config-set preferred_state stable

Configuração do PHP e Apache

Agora vamos configurar o XHProf, primeiro criamos uma pasta onde ficarão os dados do profiler:

mkdir /tmp/xhprof
chmod 777 /tmp/xhprof

E então vamos precisar configurar o PHP, para habilitar a extensão (se você reparou na instalação do XHProf ele coloca a mensagem: "configuration option "php_ini" is not set to php.ini location You should add "extension=xhprof.so" to php.ini")

Normalmente, o PHP vai ler todos os arquivos *.ini localizados na pasta /conf.d, por isso criamos um arquivo /etc/php5/conf.d/xhprof.ini com o seguinte conteúdo:

[xhprof]
extension=xhprof.so
xhprof.output_dir="/tmp/xhprof"

A última etapa é criar um alias no Apache para os relatórios do xhprof. O Apache tb lê os arquivos da pasta conf.d, mas desta vez use a extensão .conf, ou seja: /etc/apache2/conf.d/xhprof.conf:

alias /xhprof_html "/usr/share/php/xhprof_html/"

O caminho "/usr/share/php" é o default para a instalação via PEAR da extensão xhprof. Você pode confirmar listando o conteúdo dessa pasta e vericando que existem duas pastas com o nome xhprof nelas.

Restarte o apache com sudo service apache2 restart e pronto!

Configuração Drupal 7

Para visualizar os relatórios do XHProf no Drupal é muito fácil: instale o devel!

Configure na página de configuração do módulo as variáveis:

devel_xhprof_directory "/usr/share/php"
devel_xhprof_url "/xhprof_html"

E veja suas páginas sendo renderizadas com um lindo profiler!

Dica Final

Para finalizar, mais uma pequena dica, se você não quiser ter o trabalho de ativar manualmente as extensões instaladas via PEAR (ou seja, via comando pecl install), então você pode executar o seguinte comando:

pecl config-set php_ini /path/to/php.ini

Alterando claro o "/path/to" para o caminho correto ao seu php.ini. Dessa forma o próprio PEAR irá colocar a linha que ativa a extensão no seu arquivo php.ini.

Particularmente, eu prefiro fazer isso manualmente, assim criamos um arquivo para cada extensão do PHP instalada.

Como funciona a engine de renderização padrão do Drupal 7 PHPTemplate Engine

como são lindas essas pequenas curiosidades do código open source!

No Drupal 7, temos a famosa PHPTemplate Engine para renderização dos templates.

Na verdade, a função theme() permite que se sobrescreva a engine de renderização de template.

Porém, por padrão, é usada essa função theme_render_template():

function theme_render_template($template_file, $variables) {
  // Extract the variables to a local namespace
  extract($variables, EXTR_SKIP);

  // Start output buffering
  ob_start();

  // Include the template file
  include DRUPAL_ROOT . '/' . $template_file;

  // End buffering and return its contents
  return ob_get_clean();
}

Basicamente, usamos a função ob_start, para interromper a saída do script PHP e começar a gravar tudo em um buffer. (ob é a abreviação de output buffer, ou seja, buffer de saída e não isto aqui)

Aí, fazemos um include do arquivo de template. Esse include irá simplesmente enviar para a saída o resultado do arquivo de template, já substituindo as variáveis locais extraídas pela função extract.

A função finaliza retornando com ob_get_clean, que interrompe o processo de jogar a saída no buffer e retorna tudo o que foi gerado para uma string.

Antes de encerrar o post curto, queria apenas mostrar o que é possível fazer com a função extract:

$var_array = array ("cor" => "azul",
                    "tamanho"  => "medio",
                    "forma" => "esfera");

extract ($var_array);

echo "$cor, $tamanho, $forma, n";

Ou seja, as variáveis $cor, $tamanho e $forma aparecem como variáveis locais após o uso da função extract!