WordPress pede credenciais FTP ao atualizar

Wordpress Login FTP
WordPress Login FTP

Não é a primeira vez que me acontece numa instalação de WordPress ao atualizar um plugin ou o próprio WordPress, através do painel de administração do WordPress, pedir dados de acesso FTP.

A mensagem de erro exata é a seguinte:

Para executar a acção solicitada, o WordPress precisa de aceder ao seu servidor. Por favor insira as suas credenciais de FTP para continuar. Se não se lembra das suas credenciais, deverá contactar o seu serviço de alojamento web.

O primeiro passo para resolver é verificar se o utilizador que corre o servidor Web (Apache, IIS, Nginx etc…) tem permissões de escrita nas pastas do WordPress.

No entanto este problema geralmente fica resolvido quando adicionamos a linha seguinte no wp-config.php:

define('FS_METHOD', 'direct');

Pode ser colocado em qualquer lugar do ficheiro desde que fique acima da linha:

if ( !defined('ABSPATH') )
define('ABSPATH', dirname(__FILE__) . '/');

WordPress proteger BruteForce

De vez em quando gosto de dar uma vista de olhos nos logs do servidor para ver se deteto algo “anormal”, uma das coisas que me saltou à vista já há algum tempo foi o número exagerado de tentativas de autenticação inválidas! Estas tentativas tinham várias origens mas o método é sempre o mesmo tentar combinações comuns de utilizador e passwords de forma a entrar no Painel de administração do WordPress (isto é conhecido por BruteForce).

Para proteger a minha instalação de WordPress ainda pensei usar um plugin para proteger deste género de ataque mas decidi tentar uma abordagem de mais baixo nível, uma vez que já uso o Fail2Ban no servidor decidi aproveitar o mesmo e criar uma regra para à terceira tentativa de autenticação bloquear o ip de origem, fui acompanhando o número de ip’s bloqueados e são mais do que eu imaginava.

Como não sou nenhum master em regex usei uma expressão extremamente simples, quando uma tentativa de autenticação falha o WordPress retorna um erro http 403  (o comportamento standard retorna um 200 OK, com o JetPack ativo e com a opção de bloquear tentativas de login inválidas é que gera o 403), então é só mandar o Fail2Ban pesquisar acessos ao wp-login.php que retornaram 403, a regra que cheguei que se mostrou mais eficaz após alguns testes foi a seguinte:

failregex = :80 <HOST> .* /wp-login.php HTTP/1.1″ 403

Para já tem funcionado como esperado:

Optei por não usar plugins porque mesmo que um plugin detecte uma tentativa de intrusão, vai permitir que o atacante continue a gastar recursos ao servidor, ao enviar centenas ou milhares de pedidos seguidos. Como o Fail2Ban impede o ip do servidor de chegar sequer ao servidor o gasto de recursos é mínimo praticamente nulo.

Uma alteração que faço sempre no Fail2Ban é configurar para que quando bane um ip não faça REJECT e em vez disso faça um DROP(criei um Gist com isso) assim quem está do outro lado (o atacante) tem que aguardar pelo timeout do pedido para proceder para outro, isto fará com que no mínimo a aplicação que estão a usar para nos atacar consuma mais tempo e mais recursos ao atacante.

WordPress Importar Blogspot

O blogger é muito bom e gratuito mas também limitado em alguns aspetos, quando o blogspot não chega a solução pode passar por migrar para o WordPress.
O WordPress facilita esta migração ao disponibilizar uma ferramenta própria para o efeito, para a usar basta ir ao Painel do WordPress, seleccionar Ferramentas e clicar em “Importar”, nesta página surgem vários “importadores” de várias plataformas entre as quais o Blogger… seleccionamos “Instalar Agora” e o plugin de importação será instalado.

É Também possível importar do Blogroll, LiveJournal, Movable Type e TypePad, Tumblr e de sites alojados no WordPress.com.

Este importador importa o ficheiro xml exportado no Blogger, para gerar o ficheiro tem que fazer login no Blogger e ir a Definições -> Outros e seleccionar “Criar Cópia de Segurança de Conteúdo” será gerado um ficheiro com os posts.

Com o ficheiro do Blogger guardado voltamos ao painel do WordPress à página Importar e iniciamos o processo de importação basta seleccionar o novo autor para os posts e aguardar… quando o processo terminar todos os artigos da cópia estarão Publicados no WordPress.

 

 

WordPress não mostra a “Admin Bar”

Hoje depois de atualizar uma das minhas instalações de WordPress para a versão 3.1 a nova barra de admin que aparece quando estamos no site não aparecia, como é um theme feito por mim resolvi investigar o porquê.

A causa para a barra não aparecer é que não estava a implementar corretamente a class do body, para resolver este problema bastou no ficheiro em que abro a tag body, bastou adicionar a seguir à abertura da tag <body> adicionar a função do wordpress que faz echo da class adequada para ser possível a apresentação da dita barra de admin. O código a adicionar é o seguinte <?php body_class($class)?>, pelo que a declaração do body ficará <body <?php body_class($class); ?>>. E basta isto para tornar qualquer theme compatível com a nova barra de admin omnipresente.

WordPress Child Themes

Recentemente depois de actualizar um blogue para o WordPress 3.0, cliquei sem em actualizar Plugins e Temas sem me lembrar que o tema usado estava modificado. Ao actualizar as modificações foram perdidas”¦ para evitar o mesmo erro no futuro decidi criar um Child Theme, e que é um Child Theme???

Um Child Theme é um Theme que deriva de outro Theme, ou seja no Child Theme que podemos chamar Tema Derivado implementamos apenas as modificações ao tema original, se por exemplo quiser-mos alterar algo no ficheiro single.php alteramos apenas esse ficheiro ficando o original do tema intacto, viabilizando assim futuras actualizações, sem comprometer as alterações que fizemos.

A estrutura de um Child Theme é bastante simples, primeiro criamos um directório para alojar os ficheiros modificados, fazemos as alterações que pretendemos, aconselho a copiar o ficheiro original do Theme Parent e fazer ai as alterações. Depois de termos as alterações pretendidas falta apenas criar o ficheiro onde o WordPress vai ler as informações do Tema esse ficheiro tem o nome de Style.css e vai sobrepor o Style.css do tema original á semelhança do que acontece com os outros ficheiros que colocar-mos no nosso Child Theme, este Style.css tem uma particularidade em relação ao original, que é uma tag que informa o WordPress de qual é o tema em que nos baseamos, esta tag é a tag Template. Deixo a seguir o Style.css para um Child Theme baseado no novo tema por defeito do WordPress que é o “Twenty Ten”:

/*
Theme Name:     Nome do Child Theme
Theme URI:      http: //UmUrlQualquer.com/
Description:    Descrição do Child Theme 
Author:         O seu nome
Author URI:     http: //OutroUrlQualquer.com/
Template:       twentyten
Version:        0.0.1
*/

 

Se quisermos usar o css do tema original basta fazer um import do style.css original, que no caso do tema Twenty Ten será:

@import url("../twentyten/style.css");

Podemos ainda no style.css modificar o css original, basta criar os elementos com o mesmo nome e adicionar as nossas personalizações.

Depois do tema criado é só fazer upload para a pasta “wp-content/themes/” e no painel de administração do blogue activar o mesmo. E os problemas com as actualizações do tema principal deixam de ser um  problema.

WordPress comentários muito lentos

De há uns tempos para cá submeter um comentário no meu blogue quase sempre resultava de um timeout, embora o mesmo fosse inserido, ás vezes o timeout demorava quase 1 minuto.

Depois de andar ás voltas a toda a instalação e de ter reinstalado a mesma várias vezes, cheguei á conclusão que a culpa era da configuração de um plugin. O nome do Plugin é “W3 Total Cache”, este plugin faz cache de várias “coisas” do WordPress uma delas é o “database cache”, que faz cache dos queries do WordPress ao MySQL.
Á primeira tentativa para desactivar recebi também um timeout, resolvi investigar, era a pasta “dbcache” do plugin que além de milhares de pastas e ficheiros, tinha um tamanho absurdo para testar renomeie a pasta e criei outra com o mesmo nome, assim consegui desactivar a parte da cache da Base de Dados do W3 Total Cache, com o plugin desactivado o blogue deixou de funcionar devido a uma limitação do meu host, que não deixa um utilizador do MySQL ter mais do que 10 ligações simultaneas ao servidor de Base de Dados.
Baixei então para um valor muito pequeno (120 segundos) a validade da cache dos queries e por agora parece que está tudo a funcionar, alterei também o “Garbage collection interval” para 180 segundos.

Embora seja um plugin que aconselho devido a acelarar bastante a apresentação do site, fica aqui a recomendação!!!