<![CDATA[O Blog de Tecnologia do Janio]]>https://wp.sarmento.org/Ghost 0.9Thu, 08 Sep 2016 02:55:16 GMT60<![CDATA[Resetando a senha de root do MySQL do jeito sujo]]>Às vezes um administrador de sistema precisa trocar a senha de root do MySQL pela linha de comando, não importam as razões.

Minha maneira favorita consiste nos dois passos abaixo.

Passo 1: reiniciar o MySQL sem considerar as permissões

Primeiro a gente para o MySQL e o reinicia desconsiderando todas

]]>
https://wp.sarmento.org/resetando-a-senha-de-root-do-mysql-do-jeito-sujo/08a1e689-e28f-47af-a50f-ddf89af248b1Mon, 05 Sep 2016 18:06:59 GMTÀs vezes um administrador de sistema precisa trocar a senha de root do MySQL pela linha de comando, não importam as razões.

Minha maneira favorita consiste nos dois passos abaixo.

Passo 1: reiniciar o MySQL sem considerar as permissões

Primeiro a gente para o MySQL e o reinicia desconsiderando todas as permissões, depois entra no MySQ como root:

service mysql stop  
mysqld --skip-grant-tables &  
mysql -u root mysql  

Passo 2: trocar a senha

Agora é só trocar a senha do MySQL executando a sequência abaixo (sendo que SENHA deve ser a sua senha desejada):

UPDATE user SET Password=PASSWORD('YOURNEWPASSWORD') WHERE User='root';  
FLUSH PRIVILEGES;  
exit;  

Passo 3: reiniciar o serviço

killall -9 mysqld  
service mysql restart  

Naturalmente, você deverá ter privilégios de root para executar estes passos.

]]>
<![CDATA[Conheça o Franz, mensageiro multiprotocolo e multiplataforma]]>Um problema que sempre existiu desde que o ICQ perdeu espaço para o MSN Messenger é a dificuldade de gerenciar múltiplas contas de mensageiros instantâneos ao mesmo tempo.

Eu mesmo, que me considero bem ponderado no que diz respeito a isso, tenho nada menos do que sete mensageiros ativos.

]]>
https://wp.sarmento.org/conheca-o-franz-mensageiro-multiprotocolo-e-multiplataforma/52384a00-fd17-417a-bca2-60d5f65e9830Fri, 22 Apr 2016 22:01:11 GMT

Um problema que sempre existiu desde que o ICQ perdeu espaço para o MSN Messenger é a dificuldade de gerenciar múltiplas contas de mensageiros instantâneos ao mesmo tempo.

Eu mesmo, que me considero bem ponderado no que diz respeito a isso, tenho nada menos do que sete mensageiros ativos.

No passado houve tentativas de unificar todas as contas em um mesmo programa, o que sempre foi complicado porque perdiam-se muitos recursos de cada plataforma. Ainda há sistemas que integram vários protocolos, mas a impressão que tenho é que as pessoas cada vez menos usam essas gambiarras.

Entretanto, a maioria dos mensageiros instantâneos atuais tem versões web de seus programas, que se não são tão cheias de recursos quanto suas versões "nativas" pelo menos são versões oficiais, produzidas e divulgadas pelo mesmo responsável pelo protocolo de comunicação em si.

É justamente aí que entra o Franz.

Batizado em homenagem a um imperador da Áustria (dizem que foi o mais amado de todos), o programa permite adicionar várias contas de vários mensageiros (quatorze ao todo, ao menos por enquanto). Cada conta vai ocupar então uma aba do programa, que na prática é um Google Chrome totalmente dedicado só àquela página, que por sua vez executa a versão web de cada mensageiro.

Assim é possível ter várias contas de Hangouts, por exemplo, ou de Telegram, ou de WhatsApp, porque cada aba é totalmente independente, não comete nem sofre interferência de nenhuma outra.

A mágica de ser multiplataforma (funciona em Windows, Linux e Mac OS X) se dá pelo fato de ele ser desenvolvido em cima do Electron. Se você não associa o nome ao produto, basta dizer que é uma tecnologia desenvolvida pelo GitHub (este mesmo) capaz de encapsular aplicativos web contendo Node.JS como servidor e Google Chrome como camada de apresentação, num aplicativo nativo para cada ambiente.

]]>
<![CDATA[Como Ocultar o Script wp-login.php do WordPress]]>Ataques do tipo "força bruta" são os mais comuns contra todo tipo de site, o que inclui o popular WordPress. Já falei aqui sobre uma das muitas maneiras de fazer esta proteção (e no texto há um link para um outro post da Via Hospedagem ensinando um outro método)

]]>
https://wp.sarmento.org/como-ocultar-o-script-wp-login-php-do-wordpress/7cab6c90-a170-4324-acaa-7cf0c2786e70Tue, 05 Apr 2016 12:31:00 GMT

Ataques do tipo "força bruta" são os mais comuns contra todo tipo de site, o que inclui o popular WordPress. Já falei aqui sobre uma das muitas maneiras de fazer esta proteção (e no texto há um link para um outro post da Via Hospedagem ensinando um outro método), e agora vou apresentar um outro plugin que recém descobri que é muito simples e eficiente no mister de ocultar a página wp-login.php de olhares não autorizados.

Por que ocultar o wp-login.php

O script wp-login.php é a porta de entrada do WordPress. Qualquer um pode "bombardear" esta página e caso o dono do site tenha configurado senhas previsíveis, a chance de um estranho conseguir invadir o blog é bem alta.

Ao ocultar o wp-login.php os eventuais intrusos vão tentar acessar o blog pelo caminho normal, mas vão quebrar a cara porque não vão encontrar o formulário de login, e não vão nem saber aonde ir para procurar.

Como ocultar o wp-login.php

Existem vários jeitos de se fazer isso, mas minha recomendação de hoje é um plugin chamado Rename wp-login.php.

O nome já diz tudo.

Para usar o plugin basta instalar e ativar o plugin. Em seguida você deve ir à configuração de links permanentes do WordPress (/wp-admin/options-permalink.php) e informar numa nova opção que vai estar lá qual será a URL nova do wp-login.php.

Veja um exemplo:

Como Ocultar o Script wp-login.php do WordPress

Naturalmente que você não vai usar nomes óbvios (como "login"), e sim qualquer coisa que só faça sentido para você.

Cuidados com o cache

É claro que você usa plugin de cache no seu site. Neste caso você deve instruir o script para não fazer cache da nova URL de login que você acabou de criar. Com um pouco de sorte o plugin vai reconhecer o seu ambiente e orientar sobre o local correto para fazer a configuração adicional.

Desfazendo a alteração

Caso queira voltar seu WordPress ao comportamento normal, sem ocultar o wp-login.php, você só precisa desativar o plugin. Caso tenha esquecido da URL nova você pode desativar o plugin simplesmente removendo (via SFTP ou qualquer outro método de acesso aos arquivos) o diretório wp-content/plugins/rename-wp-login/.

Um passo além

Caso você se sinta corajoso (ou pelo menos confortável para mexer em configurações mais avançadas) você pode bloquear totalmente o acesso externo ao arquivo wp-login.php. Eu particularmente gosto de fazer este tipo de bloqueio diretamente no Varnish, mas bloquear diretamente no webserver, usando o .htaccess (no caso do Apache) também será muito eficiente.

<Files wp-login.php>  
    Order deny,allow
    Deny from all
</Files>  

O código acima não foi testado, use por sua conta e risco.

]]>
<![CDATA[Como acessar MySQL remoto mesmo que bloqueado no servidor]]>É comum que as empresas de hospedagem que se importam com os aspectos de segurança dos sites dos seus clientes impeçam o acesso ao MySQL a não ser pelo localhost (ou seja, a partir da mesma máquina onde o serviço está sendo executado). Para a maioria dos casos o phpMyAdmin

]]>
https://wp.sarmento.org/como-acessar-mysql-remoto-mesmo-que-bloqueado-no-servidor/d9975520-03fd-4f7e-8958-dc7f1a6ff39aWed, 30 Mar 2016 18:32:49 GMTÉ comum que as empresas de hospedagem que se importam com os aspectos de segurança dos sites dos seus clientes impeçam o acesso ao MySQL a não ser pelo localhost (ou seja, a partir da mesma máquina onde o serviço está sendo executado). Para a maioria dos casos o phpMyAdmin vai ser o suficiente para permitir acesso quase direto ao banco (via interface web), porém há situações em que é muito melhor poder usar um programa do tipo desktop para gerenciar os dados que, em última análise, pertencem ao cliente.

Vou ensinar aqui como fazer acesso direto usando um excelente cliente de MySQL, o Sequel Pro, disponível para Mac OS X. Existem outros clientes que poderão fazer a mesma coisa, para outros ambientes e também para o OS X, o importante é configurar o túnel SSH que dará acesso direto ao banco, sem ferir as diretivas de segurança do servidor.

Configurando o Sequel Pro

Para configurar corretamente o Sequel Pro para acessar seu banco de dados você vai precisar de:

  • nome do banco de dados (meio óbvio, mas é melhor pecar pelo excesso);
  • usuário com acesso ao banco;
  • senha do usuário
  • usuário de SSH com acesso ao servidor;
  • senha do usuário de SSH;
  • endereço IP ou nome de host do servidor remoto.

Ao abrir o programa pela primeira vez você poderá fazer uma Quick Connect (conexão rápida) ou criar um favorito para facilitar acessos subsequentes ao mesmo banco. O procedimento é o mesmo, então vou demonstrar como criar o favorito.

Na imagem acima vêem-se dois favoritos já criados, e iniciado o processo de criação de um terceiro.

Para o nosso propósito, você deve ir direto na aba SSH e preencher todos os campos, conforme a imagem abaixo.

  • MySQL Host deve conter o IP (ou nome de host) do servidor remoto;
  • Username é o nome do usuário que tem acesso aos bancos de dados;
  • Password é a senha do usuário de MySQL;
  • Database e Port podem ficar em branco, pois você poderá escolher o banco de dados posteriormente, e a porta é padrão;
  • SSH Host é o IP do servidor remoto, é o mesmo que você informou em MySQL Host (se não for, é muito provável de que você não precise deste tutorial);
  • SSH User é o nome de usuário de SSH, que não necessáriamente é o mesmo do MySQL mas provavelmente é o mesmo de SFTP (em caso de dúvida confirme com seu provedor de hospedagem);
  • SSH Password é a senha do usuário de SSH;
  • SSH Port não precisa ser preenchido, a não ser que seu servidor use uma porta não padrão para o SSH (confirme com seu provedor de hospedagem em caso de dúvida).

Terminando de preencher os dados clique no botão de salvar, e você já poderá acessar o seu banco de dados remoto via Internet, como se fosse local, com toda a segurança, através de um túnel criptografado SSH.

Deste ponto em diante sempre que quiser acessar o banco remoto é só clicar no favorito (à esquerda da tela) e mandar conectar (Connect).

]]>
<![CDATA[Inserindo o Código do Analytics com o PageSpeed]]>Um dos problemas mais comuns quando trocamos o template de um site, ou no caso de sites HTML estáticos gerados manualmente, é esquecer de adicionar o código de rastreamento do Google Analytics.

Em blog WordPress esse problema não chega a afetar tanto, pois há plugins que só fazem isso:

]]>
https://wp.sarmento.org/inserindo-o-codigo-do-analytics-com-o-pagespeed/081014cb-53d4-4472-ad81-b299664f8cf5Thu, 24 Mar 2016 16:51:44 GMT

Um dos problemas mais comuns quando trocamos o template de um site, ou no caso de sites HTML estáticos gerados manualmente, é esquecer de adicionar o código de rastreamento do Google Analytics.

Em blog WordPress esse problema não chega a afetar tanto, pois há plugins que só fazem isso: garantir que o código esteja presente em todas as páginas, a despeito de configuração do tema. Num mundo perfeito, seria um plugin que uma vez ativado e configurado jamais seria necessário mexer nele novamente.

A boa notícia é que o ModPageSpeed tem um filtro que garante que todas as páginas contenham automaticamente o código de rastreamento. Bastam duas linhas na configuração do módulo.

No caso do Apache:

ModPagespeedEnableFilters insert_ga  
ModPagespeedAnalyticsID UA-XXXXXX-XX  

No caso do Nginx:

pagespeed EnableFilters insert_ga;  
pagespeed AnalyticsID UA-XXXXXX-XX;  

"Pegadinhas"

Há dois detalhes para se levar em consideração, contudo, antes de achar que o PageSpeed possa ser o remédio definitivo para seus problemas de código de rastreamento.

Primeiro: o código que o PageSpeed insere automaticamente nas páginas é o assíncrono. Na verdade isso não deveria preocupar, mas acho que para algumas poucas pessoas isso pode ser um problema.

Segundo: o código inserido pelo PageSpeed faz uma checagem para evitar que páginas executando em FRAME ou IFRAME não sejam contabilizadas. Na maioria dos casos isso não é problema; mas para mim foi, de modos que vou continuar sendo obrigado a inserir o código manualmente em todas as minhas páginas, pelo menos do projeto que inspirou este post.

ModPageSpeed

O PageSpeed foi uma iniciativa da Google para tornar a Web mais rápida e eficiente. No começo era um serviço (um proxy que ficava na frente do site real) que fazia todas as otimizações automaticamente — o que sempre foi significado de não serve pra todo mundo.

Pouco antes de encerrar o serviço do PageSpeed a Google disponibilizou o ModPageSpeed.

Trata-se de um módulo para Apache (e para Nginx) que faz com que o servidor faça sozinho o trabalho de otimização de uma página e seus elementos (como CSS, JavaScript, imagens, etc).

Há empresas de hospedagem que usam o argumento falacioso de "hospedagem para SEO" para vender hospedagem comum porém com o PageSpeed ativado.

Se você ainda não está beneficiando seu site das possibilidades de otimização do PageSpeed no seu site entre em contato com minha empresa de hospedagem de sites, a PortoFácil. Lá você encontra o que tem de mais moderno e ágil em termos de servidores e serviços web.

]]>
<![CDATA[Como Transformar um Blog em HTML Estático]]>Existe um grupo de pessoas que sonha com a possibilidade de gerar versões "HTML estáticas" de seus sites tradicionalmente mantidos em um CMS dinâmico (Content Management System — Sistema de Gestão de Conteúdo).

Quem fizer uma busca pela Internet vai encontrar algumas dezenas de tutoriais propondo-se a atender esta demanda;

]]>
https://wp.sarmento.org/como-transformar-um-blog-em-html-estatico/24e18145-8d15-4c52-a458-b2b92a041348Fri, 18 Mar 2016 16:10:19 GMT

Existe um grupo de pessoas que sonha com a possibilidade de gerar versões "HTML estáticas" de seus sites tradicionalmente mantidos em um CMS dinâmico (Content Management System — Sistema de Gestão de Conteúdo).

Quem fizer uma busca pela Internet vai encontrar algumas dezenas de tutoriais propondo-se a atender esta demanda; dos que eu acompanhei (apenas analisando ou tentando implementar) nenhum conseguiu cumprir o que prometia, fosse por ignorar alguns itens fundamentais, fosse por terem sido elaborados para atender uma necessidade muito diferente da minha.

CMSs dinâmicos × CMSs estáticos

Há dois tipos de gerenciadores de conteúdo, basicamente: os dinâmicos e os estáticos.

Os gerenciadores dinâmicos são sistemas de gerenciamento (voltados para o "mercado" editorial), normalmente em cima de um banco de dados. Cada requisição feita ao site requer que o sistema consulte o banco de dados e gere a página correspondente para exibir para o visitante.

Já os CMSs estáticos funcionam de maneira diferente: em vez de ser um aplicativo rodando o tempo inteiro e respondendo a requisições de visitantes ele gera o site inteiro de uma só vez: toda e qualquer página possível de ser acessada no site estará necessariamente "pronta" antes mesmo da publicação do site (disponibilização dos arquivos no servidor). Assim, quando o visitante requisitar uma página qualquer ela simplesmente estará prontinha para ser entregue, sem esperas, sem atrasos, sem processamento nenhum a não ser o de entregar o conteúdo ao navegador.

Propositalmente não estou abordando a questão dos caches para CMSs dinâmicos neste momento.

As vantagens dos CMSs dinâmicos são bastante evidentes, e quem está acostumado ao WordPress, ao Joomla, Drupal, Ghost, ou qualquer dos muitos existentes, já as conhece todas. Destaco:

  • facilidade de trabalhar em equipe: várias pessoas podem trabalhar ao mesmo tempo em matérias diferentes (ou até na mesma, com alguma criatividade); o mesmo se aplica à possibilidade de trabalhar de qualquer lugar que tenha conexão à Internet;
  • publicação instantânea: ao clique de um botão qualquer alteração feita em qualquer aspecto do site estará disponível, sem qualquer tipo de espera ou atraso;
  • ferramentas avançadas: em CMSs dinâmicos é muito fácil de inserir recursos como artigos relacionados, páginas personalizadas, etc.

Já as vantagens dos CMS estáticos podem não ser tão evidentes, principalmente para quem tem blogs pequenos (em tamanho e em visitação). Eu destaco as seguintes:

  • custo extremamente baixo: o servidor web para entregar conteúdo estático na Internet pode ser extremamente modesto, uma vez que não há sequer a necessidade de suporte a linguagens de script, nem banco de dados, nada;
  • segurança extrema: como o site que é publicado não tem um sistema de gerenciamento público os riscos de invasão por meio de vulnerabilidades deste se reduzem a zero; a única preocupação com segurança, relacionada ao site em si, diz respeito à segurança do servidor, o que costuma ser responsabilidade das empresas de hospedagem;
  • desempenho extremo: como tudo o que vai ser entregue aos visitantes está previamente "compilado" os recursos de processamento do servidor ficam disponíveis para tratar o tráfego de rede, firewall, etc.

Prova de Conceito

Este blog, desde o seu nascimento, tem sido mantido usando um CMS estático. De todos os que experimentei o que mais me agradou foi o Hugo. Entretanto, "mais me agradou" também pode ser lido como "o que menos me estressou", e eu sei que isso é resultado do "vício" em WordPress e suas facilidades.

Entretanto, o meu mecanismo de blogs favorito é o Ghost, que nasceu para ser justamente uma alternativa mais leve, mais focada em conteúdo, do que o onipresente WordPress. Desde que eu o usei pela primeira vez fiquei apaixonado pela simplicidade e pelo desempenho (embora não seja a coisa mais fácil do mundo, para um não técnico, fazê-lo funcionar corretamente).

Resolvi, então, dar um jeito de transportar o conteúdo do blog dos meus arquivos estáticos (todos armazenados no Dropbox, para facilitar trabalhar de qualquer lugar) para uma instalação do Ghost que inicialmente estava em um VPS, mas agora está no meu próprio computador. Essa foi a parte fácil.

A dificuldade mesmo veio ao tentar converter o blog para site estático, considerando, principalmente, que este blog roda sob HTTPS.

Entra o Buster

Quem é do mundo Linux (ou Unix, de maneira geral) conhece o comando wget --mirror que teoricamente é capaz de baixar uma cópia integral de qualquer site publicado para outro local.

Pois o wget é o núcleo de um software chamado Buster, que se define como um sistema de criação de sites estáticos a partir do Ghost usando força bruta.

Escrito em Python, o que o Buster faz é rodar um wget --mirror e consertar algumas coisinhas antes de que o site possa ser publicado, tais como ajustar o domínio das URLs e remover as querystrings dos CSSs e JavaScripts. Lindo, na teoria, mas há dois problemas

O primeiro problema que notei diz respeito, creio, ao Python em si: no momento que o programa altera cada página para aplicar as correções os caracteres acentuados ficam totalmente bagunçados. Para quem só escreve em Inglês, ou outro idioma sem caracteres especiais, isso não deve fazer diferença, mas para mim foi desesperador.

O segundo parece ser ligado ao wget, porque na segunda abordagem que fiz o problema se repetiu: o site não era baixado inteiro a partir do Ghost, especialmente as URLs de paginação (tais como /page/2, /page/3, etc).

Meu próprio script

Como o Buster não me serviu (e olha que foi um parto para fazê-lo funcionar no OS X El Capitán, mas consegui obter sucesso usando o Anaconda) acabei resolvendo fazer um script em Bash que cumprisse a tarefa de baixar o site inteiro, trocar as URLs em cada página e tornar o resultado final em algo pronto para ser publicado.

Na verdade, a versão final do meu script já publica o site e otimiza as imagens automaticamente por mim.

O coração do sistema são as três linhas abaixo:

#!/bin/bash

remoteurl='https://wp.sarmento.org'  
DIR=`echo ${remoteurl} | sed -e 's,http://,,g' | sed -e 's/:/_/g'`

# Baixa o site todo
wget --recursive --convert-links --page-requisites --no-parent \  
  --directory-prefix static --no-host-directories --restrict-file-name=unix $remoteurl

# Converte o domínio para URLs relativas
grep -rl ${remoteurl} ${DIR} | xargs sed -i '' -e s,${remoteurl}/,/,g  

Vale observar que o sed acima usa a sintaxe do OS X, que é diferente da do GNU sed, usado no Linux.

Não demorei nada a perceber que embora meu script não tivesse o problema da acentuação ele também sofria do mal de não baixar as páginas todas, gerando um site cheio de páginas 404.

Cometi algumas gambiarras vergonhosas para tentar contornar esse problema, porém o nível de complexidade do código saltou a níveis absurdos, o que certamente comprometeria a facilidade de se dar manutenção no código, ou mesmo de usá-lo em situações fora do meu ambiente controlado.

Por fim, consegui resolver o problema do sumiço das páginas trocando o wget pelo httrack. Httrack é um "navegador offline" disponível para Windows, Mac e Linux, que tem por função justamente baixar sites inteiros para o disco local para propiciar navegação offline.

Mas o uso do httrack se por um lado resolveu o sumiço das páginas baixadas por outro criou novos problemas: no momento em que redijo este parágrafo este blog tem cerca de 80 páginas, sendo uns 30 posts e o restante páginas archive de autor e de marcadores. O tempo que um blog pequeno assim leva para ser baixado pelo httrack fica na ordem de uns cinco minutos sem trafegar nada pela Internet (o Ghost roda na minha própria máquina, reitero).

Além disso experimentei um outro problema cuja lógica não consigo encontrar: os arquivos que estão na minha máquina não referenciam nenhum objeto por http, o que é necessário para evitar erros mixed content por causa do https do meu site. Mas depois que os arquivos são enviados para o servidor todas as URLs em toda parte são convertidas para http outra vez, demandando um trabalho extra de consertar no servidor todos estes problemas.

É por esta razão que não vou divulgar o código do meu script aqui. Embora seja praxe eu dizer que não garanto nem dou suporte a nenhum código publicado, seria sacanagem divulgar um script que eu sei que vai dar pau (e depois ainda recusar-me a ajudar quem venha a tentar).

Conclusão

Infelizmente, a não ser pela prova de conceito, que por natureza ocorre em ambiente controlado e em pequena escala, os problemas de se tornar um site dinâmico (não importa qual o CMS usado) em estático tornam a tarefa especialmente difícil, criando um grau de dificuldade que considero acima do tolerável para aplicações no dia a dia.

Se este blog, com trinta posts, demora cerca de cinco minutos para ser espelhado pelo httrack (numa máquina com processador i7, 16GB de RAM, rodando tudo em localhost), podemos inferir que um blog com 300 posts — e isso não é nada — vá demorar mais de 8h apenas para ser espelhado. Some a isso as imagens usadas no site, e temos uma possibilidade de uso para a hashtag #medo.

Além disso, não há como garantir que o httrack vá baixar integralmente todas as páginas do site. CMSs dinâmicos podem ter URLs imprevisíveis num primeiro momento, mas que podem ser corretamente tratadas e exibidas pelo sistema.

Assim, vejo como inviável converter um site dinâmico para estático. Até mesmo este blog, usado como prova de conceito, não vai demorar a ser inviável para o meu script, demandando ser instalado como um Ghost regular.

Quem quiser ter sites 100% estáticos sem sustos vai ter que experimentar um dos muitos CMSs estáticos existentes.

]]>
<![CDATA[Use Somente URLs Relativas em seu Blog WordPress com o WP Super Cache]]>URLs relativas são URLs que não incluem as partículas de protocolo e nome de domínio a que pertencem. Exemplos:

  • /sobre.html
  • /contato.php
  • home.php

As URLs são ser relativas somente à "pasta" em que se encontram (como no home.php acima); para que uma URL seja relativa à raiz

]]>
https://wp.sarmento.org/use-somente-urls-relativas-em-seu-blog-wordpress-com-o-wp-super-cache/65d6da29-ff17-4e26-ad47-b4a2cbf65d8fThu, 17 Mar 2016 14:47:50 GMTURLs relativas são URLs que não incluem as partículas de protocolo e nome de domínio a que pertencem. Exemplos:

  • /sobre.html
  • /contato.php
  • home.php

As URLs são ser relativas somente à "pasta" em que se encontram (como no home.php acima); para que uma URL seja relativa à raiz do domínio ou subdomínio é necessário que ela comece com o caractere de barra, como nos dois primeiros exemplos.

Em contrapartida, URLs absolutas são as que incluem pelo menos o nome do domínio (com a chegada do HTML5 o protocolo passou a ser opcional). Exemplos:

Por padrão, todas as URLs de um blog WordPress são absolutas. O próprio sistema faz com que todos os recursos sejam referenciados pela URL completa, o que é muito saudável porque minimiza os riscos de links quebrados dentro do próprio site.

Entretanto, há pelo menos duas situações em que pode ser útil ter um blog configurado para usar URLs relativas.

A primeira diz respeito àqueles casos em que o ambiente de desenvolvimento não está na mesma maquina do ambiente de produção (o que deveria ser a regra, mas parece, infelizmente, ser a exceção).

O segundo caso em que as URLs relativas podem ser úteis é quando o dono do blog é neurótico por desempenho e quer uma economia ainda maior ao evitar de transferir uns poucos bytes a mais por página do servidor para o cliente.

A rigor haveria até uma terceira hipótese para alguém querer seu WP usando somente URLs relativas, mas ela desviaria demais do propósito do presente artigo, e vai ficar para uma outra oportunidade.

O Plugin Super Cache para URLs Relativas

Para quem deseja apenas resolver seu problema de URLs relativas em ambiente de desenvolvimento, ou não quer sujar as mãos com código, o plugin Relative URL será suficiente.

Para outros casos será necessário abordagens mais agressivas, e a que proponho implica escrever um pequeno plugin para o WP-Super-Cache (o melhor plugin de cache, indispensável para qualquer WordPress) que antes de salvar o cache de uma dada página vai converter todas as URLs para suas equivalentes relativas, em vez de absolutas.

Um plugin para Super Cache é diferente de um plugin padrão para WordPress. Há limitações, contextos que não existem, e filtros e ganchos específicos para o Super Cache.

Infelizmente a documentação para quem deseja escrever seu próprio plugin é confusa e superficial, mas apesar disso consegui escrever um plugin que resolve o meu problema, e torna todas as minhas URLs internas em relativas.

O código do plugin é muito simples.

<?php  
function relativepaths_internal($theURL, $buffer){  
    $theProtocol = ('https' == substr($theURL, 0, 5) ? 'https://' : 'http://');

    $URL = explode($theProtocol, $theURL);
    $domainfolder = $URL[1];
    $domain = explode('/', $domainfolder)[0];
    $site = $theProtocol.$domain;

    $buffer = str_replace("=\"$site/", '="/', $buffer);
    $buffer = str_replace("='$site/", '=\'/', $buffer);

    // DEBUG:
    // $buffer .= "\n" . '<!-- $site = ' . $site . ' -->';
    return $buffer;

}
function relativepaths_action( $buffer ) {  
    $theURL = strtolower(get_bloginfo('url'));
    $buffer = relativepaths_internal($theURL, $buffer);

    // Garante que não vai haver mixed content em caso de páginas https
    $theURL = str_replace('https://', 'http://', $theURL);
    $buffer = relativepaths_internal($theURL, $buffer);
    return $buffer;
}

function relativepaths_actions() {  
    global $cache_relativepaths;
    if( $cache_relativepaths == '1' ) {
        add_filter( 'wpsupercache_buffer', 'relativepaths_action' );
    }
}
add_cacheaction( 'add_cacheaction', 'relativepaths_actions' );

wp_supercache_relativepaths_admin() {  
    global $cache_relativepaths, $wp_cache_config_file, $valid_nonce;

    $cache_relativepaths = $cache_relativepaths == '' ? '0' : $cache_relativepaths;

    if(isset($_POST['cache_relativepaths']) && $valid_nonce) {
        $cache_relativepaths = (int)$_POST['cache_relativepaths'];
        wp_cache_replace_line('^ *\$cache_relativepaths', "\$cache_relativepaths = '$cache_relativepaths';", $wp_cache_config_file);
        $changed = true;
    } else {
        $changed = false;
    }
    $id = 'relativepaths-section';
    ?>
    <fieldset id="<?php echo $id; ?>" class="options">
        <h4><?php _e( 'Relative Paths', 'wp-super-cache' ); ?></h4>
        <form name="wp_manager" action="" method="post">
            <label><input type="radio" name="cache_relativepaths" value="1" <?php if( $cache_relativepaths ) { echo 'checked="checked" '; } ?>/> <?php _e( 'Enabled', 'wp-super-cache' ); ?></label>
            <label><input type="radio" name="cache_relativepaths" value="0" <?php if( !$cache_relativepaths ) { echo 'checked="checked" '; } ?>/> <?php _e( 'Disabled', 'wp-super-cache' ); ?></label>
            <p><?php _e( 'Enables or disables plugin to force relative paths.', 'wp-super-cache' ); ?></p>
            <?php
            if ($changed) {
                if ( $cache_relativepaths )
                    $status = __( "enabled" );
                else
                    $status = __( "disabled" );
                echo "<p><strong>" . sprintf( __( "Relative Paths is now %s", 'wp-super-cache' ), $status ) . "</strong></p>";
            }
            echo '<div class="submit"><input class="button-primary" ' . SUBMITDISABLED . 'type="submit" value="' . __( 'Update', 'wp-super-cache' ) . '" /></div>';
            wp_nonce_field('wp-cache');
            ?>
        </form>
    </fieldset>
    <?php

}
add_cacheaction( 'cache_admin_page', 'wp_supercache_relativepaths_admin' );  
?>

O código acima cria uma interface padrão para ativação do plugin nas opções avançadas do Super Cache. Caso o plugin esteja habilitado o código fará a substituição de toda incidência da URL do site (seguida por uma barra) para a barra propriamente dita:

$buffer = str_replace("=\"$site/", '="/', $buffer);
$buffer = str_replace("='$site/", '=\'/', $buffer);

Meu código é mais uma prova de conceito, então não faço verificações mais avançadas, tais como a verificação de se o endereço do site é parâmetro de algum tipo de link ou não.

Para fazer uso do plugin ele deve ser salvo no diretório de plugins do Super Cache, diretamente com a extensão .php (o nome de arquivo sugerido é relativepaths.php).

Caso prefira baixar o plugin que funciona nos meus sites, o link segue abaixo.

relativepaths.zip

Garantias e Suporte

Naturalmente, como de costume, a única garantia que posso dar é que o código acima funciona bem no meu ambiente. Ponto. Tampouco posso dar suporte (a menos que você seja cliente da PortoFácil).

Antes de fazer uso do plugin apresentado faça backup de seu blog, e se caso algo sair errado restaure o backup. Sua hospedagem web poderá ajudar com essa questão.

PageSpeed

Você deve preferir usar o mod_pagespeed sempre que possível para tornar suas URLs relativas. É mais seguro, funciona sempre, e funciona em qualquer página, não só nas páginas do WP Super Cache.

]]>
<![CDATA[Otimizando imagens ‘à Moda Hacker’]]>Apesar de as conexões de Internet estarem cada vez mais rápidas, assim como os computadores e dispositivos em geral com acesso à Internet, a obsessão por sites que carreguem cada vez mais rápido se torna cada vez mais presente e constante. Eu sei, comigo é assim também.

Embora o

]]>
https://wp.sarmento.org/otimizando-imagens-a-moda-hacker/bbb804ed-9c26-4146-ace7-42dd50bd2ee7Thu, 17 Mar 2016 14:46:04 GMT

Apesar de as conexões de Internet estarem cada vez mais rápidas, assim como os computadores e dispositivos em geral com acesso à Internet, a obsessão por sites que carreguem cada vez mais rápido se torna cada vez mais presente e constante. Eu sei, comigo é assim também.

Embora o código HTML (ou CSS e JavaScript) das páginas seja importante para o rápido carregamento de uma página, as imagens incluídas ainda são os objetos mais pesados e que mais “atrasam” os índices de desempenho que a cada dia influenciam mais o ranqueamento dos sites.

Um estudo de caso

Na verdade, a técnica que vou descrever aqui surgiu de uma necessidade relacionada ao tamanho das imagens de um blog gigante (mais de 20.000 posts, desde 2009), porém não necessariamente vinculada ao tempo de carregamento das páginas.

O cliente estava ocupando um espaço absurdo no servidor e, por motivos que não cabem aqui, um upgrade de disco era impensável.

Como este espaço praticamente todo era ocupado por imagens resolvi então fazer a otimização "por fora" utiilzando a ferramenta jpegoptim, disponível para vários sistemas operacionais.

Ferramentas necessárias

Para otimizar o servidor inteiro deste cliente foram necessárias duas ferramentas apenas: o já citado jpegoptim e o onipresente find.

Para instalar o jpegoptim no Ubuntu Server os comandos são:

apt-get update  
apt-get install jpegoptim -y  

Os comando sacima devem ser executados com o usuário root ou precedidos do comando sudo. Se não tiver certeza absoluta de como fazer peça ajuda ao seu provedor de hospedagem.

Otimização em massa

Caso suas imagens estejam em um único diretório no servidor basta executar o comando abaixo diretamente no diretório que contém as imagens:

jpegoptim *  

Entretanto, é bem pouco provável que sua necessidade seja assim tão simples. O mais comum é que você precise otimizar o diretório de uploads do WordPress, que idealmente conterá os arquivos separados por ano e mês; se não for assim, seu WordPress está um chiqueiro, dê um jeito de consertar.

Nesse caso você pode ir no diretório em que se encontram as imagens e comandar:

find . | xargs jpegoptim  

Otimização melhorada

Se você executar o jpegoptim sem parâmetros adicionais, como nos exemplos acima, o comando vai apenas remover os "metadados" dos arquivos, mantendo as inalteradas as imagens propriamente ditas (é a chamada otimização "sem perdas", embora esta denominação seja discutível).

Entretanto, analisando as imagens que o cliente salvara no seu blog, observei que havia muitos arquivos com dimensões imensas, em qualidade JPEG 100. Em resumo, qualidade 100 é o mais próximo que o JPEG pode chegar de imagens raw, o que implica arquivos muito mais pesados do que o necessário para exibição em páginas web. Em linhas gerais uma imagem JPEG com qualidade 75 vai cumprir bem o seu papel em uma página web. Imagens JPEG com qualidade 80 aparecerão em alta qualidade para um visitante, principalmente em dispositivos de mão, cada vez mais populares.

Para otimizar de maneira extrema os arquivos de meu cliente, liberando quase 50% do espaço em disco que eles ocupavam sem perdas aparentes de qualidade, o comando completo ficou assim:

find . | xargs jpegoptim --strip-all -m80  

Os parâmetros extra significam:

  • --strip-all → remove todos os metadados do arquivo, tais como comentários, marcações de localização por GPS, etc;
  • -m80 → garante que o arquivo terá uma qualidade JPEG de no máximo 80 (poderia ser menos, mas não quis ser radical demais — uso 72 nas imagens para os meus blogs).

Vale observar que ao definir uma qualidade máxima o jpegoptim vai reduzir a qualidade apenas dos arquivos cuja qualidade original seja superior o limite informado; imagens que já tenham qualidade igual ou inferior a esse limite não serão alteradas (exceto por outro parâmetro, que no exemplo acima é o que instrui a remoção de todos os metadados).

Recomendações finais

Esteja ciente de que o jpegoptim altera o arquivo, o que implica mudar suas permissões de propriedade; talvez no final de tudo seja necessário acertar permissões novamente para que as fotos estejam disponíveis para o webserver.

E se for fazer este serviço para terceiros (seus clientes, por exemplo) é importante que eles saibam que as imagens serão alteradas, e que autorizem o procedimento; nem é por nenhum aspecto técnico, e sim por uma questão de respeito ao outro.

]]>
<![CDATA[Layout Responsivo não é Modinha]]>No meu trabalho do dia a dia, na PortoFácil Hospedagem de Sites, não é raro que eu encontre problemas nos sites de clientes causados pelo "tema" que usam em seus WordPress.

Dentre os problemas mais recorrentes estão as dificuldades relativas a cache: ora aparece a versão mobile para os clientes

]]>
https://wp.sarmento.org/layout-responsivo-nao-e-modinha/106b453d-88ca-4531-b8fe-049e4f1309c5Thu, 17 Mar 2016 12:50:33 GMTNo meu trabalho do dia a dia, na PortoFácil Hospedagem de Sites, não é raro que eu encontre problemas nos sites de clientes causados pelo "tema" que usam em seus WordPress.

Dentre os problemas mais recorrentes estão as dificuldades relativas a cache: ora aparece a versão mobile para os clientes de desktop, ora o inverso. Isso quando o cache não fica totalmente comprometido porque a versão mobile normalmente não tem cache nenhum, e já não é mais segredo para ninguém que as pessoas estão usando muito mais dispositivos de mão para acessar a Web do que usando computadores.

"Essa coisa de layout responsivo é modinha!"

Um dos grandes erros que alguém que considere sério o trabalho que faz em seus blogs é desconsiderar a importância do layout responsivo.

Se for para ter um layout não-responsivo em seu site, faça então apenas o layout para dispositivos móveis, e esqueça do desktop.

Mas jamais pense que poderá haver um recuo no uso de dispositivos móveis para acesso à Web. É mais fácil a própria Web deixar de existir do que voltar a ser dominada por dispositivos de mesa.

Vantagens do layout responsivo

O layout responsivo tem muitas vantagens quando bem executado, e vou citar aqui as principais.

Manutenção do Código

Quando você tem um layout responsivo você acaba tendo o mesmo código para qualquer versão do site, reduzindo a mão de obra necessária para qualquer alteração ou modificação

Um Único Conteúdo por URL

Existe uma máxima do SEO que diz que jamais se deve entregar um conteúdo para o buscador (o "bot") e outro para o visitante.

Acontece que quando você não usa um layout responsivo, usando um tema alternativo para os visitantes de dispositivos móveis, é exatamente isso que está fazendo: entregando conteúdos distintos para o bot e para o visitante.

Já com o uso de layout responsivo este pecado deixa de ser cometido, pois o código (e o conteúdo por conseguinte) entregue a qualquer visitante será sempre o mesmo para uma mesma URL.

Otimização de Recursos de Servidor

Como já falei acima, uma das maiores vantagens do layout responsivo é que não há invalidação de cache por causa do dispositivo que efetua a visita no site.

Isso implica menos recursos de processamento sendo gastos para exibir uma página, logo um servidor mais barato pode dar conta de mais audiência, logo isso representa lucro no fim das contas.

Layout Responsivo Não Custa Mais Caro

Se você não tem dinheiro para pagar pelo desenvolvimento de um layout responsivo para seu site, não pague!

Existem toneladas de layouts responsivos disponíveis gratuitamente na Internet. Vá lá, baixe um que seja do seu agrado e use.

Se tiver dinheiro para pagar um layout não-responsivo, use-o para contratar alguém para adaptar elementos visuais e deixar o resultado final mais parecido com o seu gosto.

Se com tudo isso você ainda se recusar a ter um layout responsivo no seu site, então o diagnóstico é um só: você é uma pessoa burra.

]]>
<![CDATA[Como Livrar-se dos Comentários dos Portais de Noticias]]>Todo mundo que usa a Internet, em algum momento da vida, já teve o dia estragado por ter tido a péssima ideia de ler alguma notícia de portal, e "dar uma olhada" nos comentários.

Se você sabe do que estou falando, e como eu não aguenta ter de conviver com

]]>
https://wp.sarmento.org/como-livrarse-dos-comentarios-dos-portais-de-noticias/249376cc-1b33-422d-b6c7-9197ee2b558fThu, 17 Mar 2016 12:46:25 GMTTodo mundo que usa a Internet, em algum momento da vida, já teve o dia estragado por ter tido a péssima ideia de ler alguma notícia de portal, e "dar uma olhada" nos comentários.

Se você sabe do que estou falando, e como eu não aguenta ter de conviver com o tipo de energúmeno que frequenta tais espaços, eu tenho a solução.

Em linhas gerais, você vai precisar instalar um userscript no seu navegador. Vou dar as instruções para fazer isso no Chrome.

Primeiro de tudo, você precisa instalar uma extensão chamada Tampermonkey, que é o mecanismo que vai permitir que o navegador interprete os userscripts (códigos dos usuários que modificam de alguma maneira o comportamento de uma página).

Instalada a extensão, vai aparecer um botão que é um quadradinho com duas bolinhas na metade inferior dele.

Agora, você deve ir até a página do userscript Removedor de Comentários, no Greasy Fork. Aí é só clicar no botão verde com "Install this script" e navegar normalmente.

Pronto.

A partir de agora você pode visitar os sites que a autora do userscript configurou no código, sem precisar se preocupar com a desagradável experiência de ler os comentários.

A qualidade de vida online aumenta assustadoramente, pode crer.

]]>
<![CDATA[Envie Campanhas de Email Marketing (praticamente) de Graça]]>Com o enfraquecimento dos negócios cujo faturamento era baseado no Google Adsense uma modalidade de faturamento que ganha força a cada dia é o CPA (Custo Por Ação, que virou sinônimo de uma parte de seu significado total: as comissões pagas por venda efetuada), que muita gente também conhece por

]]>
https://wp.sarmento.org/envie-campanhas-de-email-marketing-praticamente-de-graca/97954b0a-5f6e-4bbf-b477-89cdd944f638Sun, 24 Jan 2016 11:51:00 GMTCom o enfraquecimento dos negócios cujo faturamento era baseado no Google Adsense uma modalidade de faturamento que ganha força a cada dia é o CPA (Custo Por Ação, que virou sinônimo de uma parte de seu significado total: as comissões pagas por venda efetuada), que muita gente também conhece por programa de afiliados.

Embora eu não acredite tanto assim no potencial de venda do email marketing (leia mais no meu blog principal em “A Volta Triunfante dos Blogs”) as listas de contato ainda são a maneira mais eficiente de divulgar os links de afiliado que poderão render uma graninha — ou uma receita considerável — no final do mês.

Existem muitas ferramentas de envio de email disponíveis na Internet, a maioria delas é paga e custa caro. As gratuitas normalmente são só “chamarizes” ou iscas para que as pessoas se acostumem à ferramenta e acabem pagando pelos upgrades quando atinjam o limite da gratuidade.

Entretanto, praticamente todas sofrem do mesmo mal: as listas de emails não são realmente do dono delas, e sim destas empresas.

Duas histórias de terror

Para entender melhor meu ranço com as empresas de email marketing creio ser adequado contar duas historinhas de terror; uma aconteceu comigo (com a minha lista de emails) e a outra com um amigo.

Atiraram primeiro, nem perguntaram depois

Meu amigo tinha uma lista de 600.000 e-mails funcionando na Aweber, que é popular e muito bem conceituada. Foram emails coletados no decorrer de anos, uma lista construída com dedicação e cuidado, cujos resultados sustentavam sua família. Um belo dia, sem aviso prévio, e sem nem oferecer um backup, a Aweber desativou a conta dele, sem nem ao menos oferecer uma cópia da lista para que ele pudesse restabelecer-se em outro fornecedor.

Utilizando um backup antigo, de quando a lista era 30% menor, ele acabou indo para a GetResponse. Só que se na Aweber, com quem ele tinha anos de relacionamento, ele não se livrou de uma expulsão sumária sob a alegação (inválida, posso atestar) de spam, o que esperar da GetResponse? No fim, acabou tendo o mesmo destino, só que muito mais rapidamente.

Não te queremos aqui

Quando meu amigo migrou para a GetResponse ele o fez quase por indicação minha: eu fui lá, criei uma conta (válida, para as minhas listas) e fiz a inscrição no programa de afiliados. Como meu amigo gastava uma nota preta mensalmente com os 600.000 contatos dele era uma chance de uma parte do dinheiro ser revertida para alguém que merecia (euzinho aqui).

Meu amigo foi expulso sob a alegação de spam, e eu fiquei mais uns três meses lá, até que sem nenhuma justificativa me mandaram embora, e acabei perdendo a lista de contatos, o histórico e consequentemente o tesão no “Spam do Amor”, um projeto muito bacana que acabou morrendo na casca — até hoje não consegui retomá-lo com o carinho que merece.

A única coisa em que posso pensar é que rolou um preconceito básico contra o nome da minha newsletter: ou por causa da palavra Spam ou por causa da palavra Amor — jamais saberei.

Modelo de cobrança injusto

Outra coisa que me incomoda muito na maioria dos provedores de email marketing é a cobrança baseada na quantidade de contatos da lista. Não interessa se você manda emails para uma pequena parcela dos seus contatos, o simples fato de ele existir no banco de dados já é fator de cobrança.

Alguns são até mais cruéis: se você tiver duas listas diferentes, e acontecer de um mesmo contato estar nas duas, você vai ter que pagar em dobro pela existência dele no banco de dados.

Já vi casos de segmentação de listas fazerem um mesmo contato aparecer em cinco ou seis listas diferentes (como uma lista pela idade do contato, outra pelo Estado em que reside, outra pela cidade, outra pelo gênero, pelo estado civil, pelo esporte favorito, pelo time para que torce, pela cor do cabelo, e por aí vai).

Conheça o Sendy

“Sendy” é o nome de um programa que roda no seu próprio servidor, e que usa a Amazon SES (Simple Email Service) para fazer o envio das mensagens. A própria Amazon cuida de tratar as mensagens de erro e denúncias de spam, e encaminhá-las para o Sendy processar, utilizando o seu serviço de notificações (SNS).

A beleza disso tudo é que você paga pelo Sendy uma única vez (59 Dólares), paga pela hospedagem o que você já pagaria normalmente para hospedar seus sites (logo, ao menos teoricamente, não há aumento de custos) e para a Amazon você paga a ridícula quantia de um Dólar por cada 10.000 emails enviados!

Desvantagens do Sendy

Embora seja meu queridinho, devo dizer que o Sendy tem umas duas ou três desvantagens com relação a outros serviços.

Primeiro, a Amazon é muito rígida na verificação dos domínios e dos emails que vão fazer envio de mensagens pelo Sendy. Para os leigos pode ser um pouco assustador fazer todas as configurações necessárias para o correto funcionamento do sistema.

Pela mesma razão de eles serem rígidos com a autenticidade dos domínios e dos remetentes, eles liberam "poucos" emails no começo, e à medida que vão ganhando confiança no novo cliente vão aumentando o limite de emails que ele pode enviar no intervalo de 24h.

A Amazon é intolerante com spam, e por esta razão eles têm controle rígido sobre o que é enviado. Cada "disparo" que você faz fica registrado (na verdade eles usam janelas de tempo e não "disparos" de email para este controle), e eles monitoram o volume de emails inválidos ou que reclamam de spam; se você exceder o limite permitido eles podem cancelar sua conta.

Mas também vale lembrar que embora seja uma megaempresa de Internet a Amazon não é igual às outras no que diz respeito à comunicação com o cliente: sempre tem um canal de comunicação pelo qual a gente consegue falar com um ser humano, que normalmente entende a situação da gente e orienta na correção de eventuais problemas, e que remove suspensões a partir de justificativas plausíveis e o compromisso de não cometer novamente o mesmo erro.

Por fim, o maior “defeito” que o Sendy pode ter é também sua maior virtude: o vínculo estreito com a Amazon. Por causa dele é necessário ter cartão de crédito internacional para poder pagar a despesa mensal da Amazon, caso contrário o Sendy não funcionará.

Limpe suas listas antes de inseri-las no Sendy

Uma das melhores maneiras de evitar problemas com a Amazon, usando o Sendy, ou com qualquer provedor de email marketing, consiste em limpar as listas de emails antes de começar a enviar mensagens.

Já escrevi um longo post sobre o assunto, então não vou me alongar aqui. Para mais informações sobre limpeza de listas de email acesse: Como Limpar sua Lista de Emails.

Hospedagem para o Sendy

Caso precise de hospedagem para rodar seu Sendy sugiro a minha empresa de hospedagem, a PortoFácil. Entre em contato e diga do que precisa, e daremos um jeito de te ajudar.

Já temos experiência no uso do Sendy, bem como vários clientes que o utilizam diariamente. Dificilmente você vai encontrar suporte melhor que o nosso.

]]>
<![CDATA[WordPress: como adicionar o rel=nofollow automaticamente a todos os seus links]]>Não cabe a mim dizer se é bom ou ruim para o SEO do site ter links nofollow (o Google dá a entender que é ruim). O fato é que às vezes a gente quer ou precisa aplicar automaticamente o "nofollow" em todos os posts já publicados e que venhamos

]]>
https://wp.sarmento.org/wordpress-rel-nofollow-automaticamente/df9602f8-a2f3-403c-a810-9bda3270f55dMon, 10 Aug 2015 12:43:00 GMTNão cabe a mim dizer se é bom ou ruim para o SEO do site ter links nofollow (o Google dá a entender que é ruim). O fato é que às vezes a gente quer ou precisa aplicar automaticamente o "nofollow" em todos os posts já publicados e que venhamos a publicar.

Basta adicionar o código abaixo no functions.php e limpar o cache para automaticamente todos os links externos estarem do jeito que a gente quer (caso, reitero, o que desejemos sejam links "nofollow").

add_filter('the_content', 'my_nofollow');  
add_filter('the_excerpt', 'my_nofollow');  
function my_nofollow($content) {  
    return preg_replace_callback('/<a[^>]+/', 'my_nofollow_callback', $content);
}
function my_nofollow_callback($matches) {  
    $link = $matches[0];
    $site_link = get_bloginfo('url');
    if (strpos($link, 'rel') === false) {
        $link = preg_replace("%(href=\S(?!$site_link))%i", 'rel="nofollow" $1', $link);
    } elseif (preg_match("%href=\S(?!$site_link)%i", $link)) {
        $link = preg_replace('/rel=\S(?!nofollow)\S*/i', 'rel="nofollow"', $link);
    }
    return $link;
}

Como de costume, não posso dar suporte nem garantias. Mas eu uso nos meus WPs e estou bem feliz. Seja cuidadoso e as chances de você não ter problemas são altas.

]]>
<![CDATA[Redirecionando URLs antigas para nova estrutura de permalinks]]>Embora eu não seja nenhum especialista em SEO, sei que alguns "gurus" por aí recomendam usar uma estrutura de permalinks mais simples do que o tradicional formato que inclui ano, mês e dia na URL dos posts (tratando-se ou não de WordPress). Particularmente eu gosto de inserir um .html no

]]>
https://wp.sarmento.org/redirecionando-urls-antigas-para-nova-estrutura-de-permalinks/570a0397-b47f-451c-93af-9fbf95d3e774Sat, 01 Aug 2015 12:41:00 GMTEmbora eu não seja nenhum especialista em SEO, sei que alguns "gurus" por aí recomendam usar uma estrutura de permalinks mais simples do que o tradicional formato que inclui ano, mês e dia na URL dos posts (tratando-se ou não de WordPress). Particularmente eu gosto de inserir um .html no final das URLs dos posts, mas o sugerido é que seja apenas o slug do post mesmo.

No WordPress é simples de mudar isso, é só alterar a configuração dos permalinks e pronto.

Entretanto, os posts antigos que já tiverem sido referenciados em outros sites, ou que já façam parte do índice dos buscadores, em vez de abrirem normalmente para os novos visitantes vão apresentar apenas uma página de erro (conteúdo não encontrado).

Para resolver isso é necessário fazer um pequeno truque no .htaccess ou na configuração do Nginx, de forma a redirecionar os posts da URL antiga para a nova.

Suponhamos que tenhamos um blog chamado exemplo.com e que nele haja um post com a seguinte URL:

exemplo.com/2015/08/01/como-mudar-permalink

Com a remoção das partículas de ano, mês e dia a URL vira:

exemplo.com/como-mudar-permalink

Observando a primeira URL podemos inferir uma ER (Expressão Regular) que a descreve:

^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)$

Das quatro partes da URL original, a única que nos importa para fazer o redirecionamento é a quarta e última. Assim, a regra completa de rewrite do Nginx é:

location ~ "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)$" {  
 rewrite "^/([0-9]{4})/([0-9]{2})/([0-9]{2})/(.*)$" http://exemplo.com/$4 permanent;
}

Caso você use Apache pode obter o mesmo efeito de maneira ainda mais simples, usando uma diretiva RedirectMatch no seu .htaccess:

RedirectMatch 301 /\d{4}/\d{2}/\d{2}/(.*) http://exemplo.com/$1  

Para quem está menos acostumado com as diferenças entre o Apache e o Nginx, vale salientar que este requer que a ER esteja envolta em aspas para ser interpretada corretamente, e cada partícula gera uma variável diferente ($1, $2, $3, $4). Já no caso do Apache apenas o .* é considerado variável, por isso a regra dele utiliza $1 como slug do post.

]]>
<![CDATA[Como instalar o WP-CLI em seu servidor]]>WP-CLI é o nome de uma ferramenta sensacional para administrar blogs WordPress pela linha de comando. Tarefas que são um porre de se fazer pela interface visual do WP são um docinho de côco com Nutella: atualizar, instalar plugins ou temas, exportar e importar XML, etc.

Sem contar que algumas

]]>
https://wp.sarmento.org/como-instalar-o-wp-cli-em-seu-servidor/11161b97-574f-40f2-b64c-0fe169d53fe6Mon, 27 Jul 2015 12:39:00 GMTWP-CLI é o nome de uma ferramenta sensacional para administrar blogs WordPress pela linha de comando. Tarefas que são um porre de se fazer pela interface visual do WP são um docinho de côco com Nutella: atualizar, instalar plugins ou temas, exportar e importar XML, etc.

Sem contar que algumas coisas são praticamente impossíveis de se fazer via web, devido ao tempo de execução extremamente longo, dentre as quais destaco:

  • atualizar o WP quando o banco de dados é muito grande (solução alternativa sem WP_CLI) e
  • importar um XML oriundo de um outro WordPress, quando a quantidade de posts é grande e/ou é necessário importar também as imagens do blog antigo.

Para instalar o WP-CLI é necessário ter acesso shell para efetuar SSH com a conta de root no servidor.

A primeira coisa a fazer é decidir onde será instalado o programa, e eu gosto de instalar tudo no /opt. Os comandos abaixo criam o diretório e baixam o WP-CLI para o lugar certo.

mkdir -p /opt/wp-cli/  
cd /opt/wp-cli/  
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar  

Se quiser ter certeza de que o script está funcionando, o comando abaixo faz a mágica:

php wp-cli.phar --info  

Agora é só tornar o WP-CLI disponível no servidor inteiro:

chmod +x wp-cli.phar  
ln -s wp-cli.phar /usr/local/bin/wp  

Pronto, o WP-CLI está instalado no seu servidor, e pronto para ser usado.

]]>
<![CDATA[Instalando Fontes no OS X Yosemite]]>Embora eu (diga que) não goste muito de programar, estou o tempo todo com o SublimeText aberto, ou pelo menos o vim editando scripts e configurações (ambas até se confundem, às vezes).

Nisso faz-se mister que meu editor de texto use uma fonte monoespaçada muito fácil de ler, confortável aos

]]>
https://wp.sarmento.org/instalando-fontes-no-os-x-yosemite/980b2256-f7e9-4ee3-9ce8-f8417efdcf0bThu, 23 Jul 2015 12:37:00 GMTEmbora eu (diga que) não goste muito de programar, estou o tempo todo com o SublimeText aberto, ou pelo menos o vim editando scripts e configurações (ambas até se confundem, às vezes).

Nisso faz-se mister que meu editor de texto use uma fonte monoespaçada muito fácil de ler, confortável aos olhos, bonita (para o meu gosto) de modos que a produtividade não seja afetada.

Nas quebradas da teia acabei chegando a um artigo do LifeHacker sobre a Monoid, uma fonte TrueType Open Source perfeita para programadores.

Tudo muito lindo: baixei o arquivo .zip do site oficial, descompactei e mandei o Font Book abrir os arquivos para instalação.

Só que não foi.

Não teve jeito de fazer a fonte instalar pelo Font Book.

Não vou perder tempo explicando o quanto tive de pesquisar para, meio que por acaso, resolver o problema. Vamos direto à solução.

Claro, vai ter que usar o Terminal para poder seguir minha receita.

Considere que você tenha baixado o arquivo Monoid.zip para sua pasta de Downloads (ou Transferências, caso você use o OS X em Português) e descompactado, de forma a ter uma pasta Monoid dentro da sua pasta de Downloads.

O truque é copiar manualmente os arquivos .ttf do lugar em que estão para /Library/Fonts, que é onde o OS X espera ter as fontes disponíveis para o sistema inteiro.

cp ~/Downloads/Monoid/*.ttf /Library/Fonts/  

Pronto, só isso.

Caso você seja muito cagão para usar o Terminal, creio que deva abrir duas janelas do Finder, uma com a pasta Monoid aberta, e outra onde você vai abrir a pasta Library (ou Biblioteca). Muito provavelmente esta pasta não estará visível, então pressione CMD+J para abrir as opções de visualização, e marque a opção de exibir a pasta Biblioteca.

Com as duas janelas é só arrastar e soltar os arquivos de um lado para o outro.

Feito isso, o ideal é reiniciar o Mac para que as novas fontes sejam reconhecidas pelo sistema inteiro, mas encerrar os programas e reabri-los já deverá ser suficiente para que a nova fonte esteja disponível nos programas.

]]>