Marketeer, webmaster and WordPress lover
No final de julho de 2020, tive o prazer de conversar com a simpática Katharina Farina, produtora do canal WordPress sem Código, quando falamos um pouco da minha experiência com o WordPress, opiniões “polêmicas” sobre construir sítios usando page builders e o desejo de criar uma comunidade internacional de WordPress em língua portuguesa.
Confere aí embaixo este bate-papo e depois segue o WordPress sem Código no YouTube!
Para desenvolvedores que têm conhecimento de infraestrutura e gostam de manter seu próprio servidor, usar o SSH para acessá-lo e fazer manutenções no WordPress e outras pastas é uma tarefa cotidiana. Normalmente o acesso se dá com a dupla usuário/senha, mas há casos, entretanto, em que a plataforma obriga ou já deixa o servidor pré-configurado para fazer o acesso somente por uma chave pública SSH.
O acesso por chave pública é uma opção segura, mas pode ser um problema se tu não tens conhecimento dessa chave ou não estavas preparado para este tipo de acesso.
Nestes casos, ao se tentar acessar o servidor com o comando ssh usuario@servidor, recebemos aquele erro chato e sem muita explicação:Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password)
Isso normalmente ocorre porque o SSH está tentando fazer a combinação de autenticação e a chave não está armazenada em tua máquina, simplesmente porque não existe.
Um exemplo comum são servidores criados nos serviços Lightsail ou EC2 da Amazon. Nestes serviços, os servidores não tem um usuário “root” e o acesso por padrão é via chave pública. Para melhorar, a documentação não é clara sobre este aspecto da configuração (até porque é quase toda em Inglês).
No caso da Umbler, é um pouco diferente. A documentação é melhor e o suporte é amistoso, o que já melhora 100%. Entretanto, para se fazer o acesso SSH é obrigatório fazer o envio da chave pública antes, não há a opção de acessar por senha.
Já na DigitalOcean, Vultr e outras, em geral é possível ter o acesso via chave pública, mas a autenticação padrão é por senha, o que pode ser menos seguro, mas é mais prático logo que se cria o servidor.
O que fazer nestes casos? Na verdade é simples. Basta usar os parâmetros PreferredAuthentications (Autenticação Preferida) e PubkeyAuthentication (Autenticação por Chave Pública) para forçar o acesso por senha e dispensar a chave pública.
O comando ficaria assim:
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no usuario@servidor
Ou seja, “Autenticação Preferida = senha” e “Autenticação por Chave Pública = não”.
Com esse comando, o SSH vai responder com:
usuario@servidor's password:
Daí é só entrar com a senha e pronto.
Outra possibilidade interessante é guardar as configurações usadas para cada servidor que precisares fazer acesso.
Isso é feito por meio de um arquivo “config” que é gravado na pasta .ssh, a mesma onde ficam as chaves de acesso.
1) Acessa a pasta .ssh na tua pasta de usuário e cria um documento com o nome config e ajusta as permissões do arquivo para 600.
2) Edita o arquivo e cria seções iniciando sempre com este modelo
host <servidor ou padrão>Por exemplo:
host *.gauderio.com
user gaudencio
port 9191
PubkeyAuthentication=noDaí é só usar ssh indio-veio.gauderio.com que o SSH vai consultar o arquivo de configurações e aplicar as opções listadas acima.
Ainda há a chance de haver um arquivo de configuração padrão para todo o sistema. Neste caso, será necessário “enganar” o SSH, especificando uma configuração de mentirinha:
ssh -F /dev/null usuario@servidorO parâmetro -F permite especificar um arquivo de configuração alternativo e a configuração padrão de sistema é ignorada.
Este artigo te ajudou? Ficaste com alguma dúvida sobre o SSH? Seguiste os passos e não funcionou? Deixa teu comentário aí embaixo para a gente ver juntos!
Este vídeo está chegando ao meu blogue com um atraso de 2 anos — foi apresentada no WordCamp Porto Alegre 2018 — mas é um assunto que sempre gostei de falar, porque muitas vezes esquecemos de coisas básicas, como mudar a descrição do nosso próprio sítio e deixamos aquele padrão “só mais um blog WordPress”.
Nessa palestra, eu sugeri 10 ações “obrigatórias” que formam uma configuração básica para servir de ponto-de-partida de um blogue WordPress. Esta configuração leva em conta aspectos de apresentação, conteúdo, SEO, segurança e desempenho. A apresentação tem foco no público iniciante, mas pode despertar interesse aos já introduzidos ao mundo WordPress.
O arquivo da apresentação está disponível para baixar aqui: http://bit.ly/wcpoa2018-palestra06.
PS: Lá pelos 16 minutos o operador de som cansou das minhas piadas sem graça e cortou meu microfone, mas voltou pelo minuto 17.
Por padrão, a pesquisa do WordPress retorna em seus resultados todas as páginas e postagens que contém a expressão solicitada pelo usuário. Em geral este ajuste é o mais adequado para a maioria das vezes, mas há situações que seria desejável exibir apenas as páginas ou os posts do blog nos resultados da busca.
Para isso, basta usar o filtro pre_get_posts por meio de uma pequena função no arquivo functions.php do teu tema ou em um plug-in específico. Vamos ver como fazer.
Para mostrar só os posts, a função define que o tipo de post (post type) a ser buscado pela consulta principal é “post”.
/* Se não é o painel administrativo, segue */
if (!is_admin()) {
function buscar_somente_posts($query) {
/* Se a consulta é uma busca, então */
if ($query->is_search) {
/* Limita o "post_type" a posts */
$query->set('post_type', 'post');
}
return $query;
}
/* Adiciona a função ao filtro pre_get_posts */
add_filter('pre_get_posts','buscar_somente_posts');
}O código é o mesmo, só trocamos o post_type para “page”.
/* Se não é o painel administrativo, segue */
if (!is_admin()) {
function buscar_somente_paginas($query) {
/* Se a consulta é uma busca, então */
if ($query->is_search) {
/* Limita o "post_type" a páginas */
$query->set('post_type', 'page');
}
return $query;
}
/* Adiciona a função ao filtro pre_get_posts */
add_filter('pre_get_posts','buscar_somente_paginas');
}Bem, se tu prestaste atenção, te deste conta que é só trocar o post_type na consulta para filtrar por qualquer tipo personalizado de post que se queira, como por exemplo, “produtos”, “pessoas”, “endereços” e qualquer outro.
Conseguiste fazer o filtro que precisavas? Faz teu comentário e diz como foi tua experiência. Queres que eu escreva um artigo mais completo sobre isso? Deixa tua sugestão!