Como atualizar o PHP no macOS?

Se tu usas Mac para desenvolver teus sítios WordPress, deves ter notado que felizmente o macOS já vem com o PHP instalado. A questão é que nem sempre a versão instalada é a mais nova, principalmente se estás rodando uma versão antiga do macOS, como eu, que uso o El Capitan no meu Mac Pro 2009.

Ter a última versão PHP é um pré-requisito para poderes desenvolver teus projetos e uma versão antiga pode ficar atrapalhando tua vida, principalmente se queres usar ferramentas auxiliares como a extensão PHP Intellisense dentro do VSCode.

O macOS Catalina já vem com a versão 7.3 do PHP, e o Mojave e o High Sierra até vêm com o PHP 7.1 pré-instalado, mas a versão instalada no macOS Sierra é a 5.6 e o El Capitan vem com o PHP 5.5. Péssimo.

Felizmente o pessoal do grupo php-osx mantém pacotes dos últimos “builds” das versões do PHP desde a 5.3 até 7.3, que podem ser instalados desde o Snow Leopard (OS X 10.6) até o High Sierra (macOS 10.13). Como os programas são instalados na pasta /usr/local/php5, eles não afetam em nada tua instalação padrão do macOS.

Instalando o PHP no macOS

Mais fácil que correr cancha com tropeiro de lesma. Escolhe a versão, abre o Terminal e digita a linha correspondente, abaixo:

PHP 7.3

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.3

PHP 7.2

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.2

PHP 7.1

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 7.1

PHP 5.6

$ curl -s http://php-osx.liip.ch/install.sh | bash -s 5.6

Infelizmente o pessoal do php-osx não montou um pacote para a versão 7.4 e ainda não descobri uma maneira mais fácil de instalar esta versão sem ter que instalar utilitários extras, como o Homebrew. Quando descobrir, atualizo o artigo.

Verificando se a nova versão do PHP está funcionando

Agora que tudo está instalado, precisamos adicionar a pasta do pacote ao PATH do sistema:

$ export PATH=/usr/local/php5/bin:$PATH  

Depois, é só verificar se a nova versão é a padrão:

Mac-Pro:~ marcoandrei$ php -v

PHP 7.3.8 (cli) (built: Aug 11 2019 20:50:16) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.8, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.8, Copyright (c) 1999-2018, by Zend Technologies
with Xdebug v2.7.2, Copyright (c) 2002-2019, by Derick Rethans

Feito!

“Tá, mas o VS Code continua dando erro…”

Pois é, em alguns casos, quando o VS Code continua dando erro, é porque a extensão PHP Intellisense não identificou corretamente a versão do PHP, mesmo que o sistema aponte a versão nova. A solução é preencher o parâmetro “executablePath” nas configurações da extensão.

Dentro do VS Code, vai em Extensions e encontra a extensão “PHP Intellisense”. Clica na engrenagem e seleciona Extension Settings. Adiciona (ou edita) esta linha no arquivo settings.json:

"php.executablePath": "/usr/local/php5/bin/php"

Agora sim!

Bueno, este tutorial te ajudou? Tens alguma dúvida? Deixa teu comentário aí embaixo e a gente troca uma ideia!

Um bate-papo com Katharina Farina do WordPress Sem Código

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!

SSH: Como forçar o uso de senha para autenticação?

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.

Quando o acesso SSH por chave pública atrapalha

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?

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.

Tenha configurações SSH diferentes para cada servidor

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.

Criando um arquivo de configurações para o SSH

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=no

Daí é 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@servidor

O 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!

10 coisas que deves fazer após criar teu blog WordPress

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.