Autor: marcoandrei

Quais os servidores MX do serviço Email Business da GoDaddy?

Recentemente, eu trabalhei em um projeto em que o cliente tinha um domínio no Wix, mas o e-mail estava na GoDaddy. Ocorre que meu trabalho foi justamente substituir o Wix pelo WordPress e, por isso, o cliente contratou uma hospedagem na própria GoDaddy, abandonando de vez o Wix.

O domínio foi migrado, a hospedagem contratada na GoDaddy foi corretamente “conectada”, mas na hora de integrar o e-mail, o sistema deles não faz a conexão automaticamente, como faz com a hospedagem. Sendo assim, era necessário incluir no DNS as entradas MX do serviço de correio eletrônico.

Infelizmente eu não encontrei estas informações em nenhum lugar da documentação da GoDaddy, por isso deixo aqui registrado. São dois servidores, com as respectivas prioridades:

0 smtp.secureserver.net
10 mailstore1.secureserver.net

Mas atenção: use estas entradas para configurar o serviço Email Business também conhecido como Email Profissional. Para o Microsoft 365, também oferecido pela GoDaddy, as entradas são outras.

Boa sorte!

Como resolver erros 404 com permalinks do WordPress usando MAMP 7

Tu usas o MAMP desde sempre e depois de instalar a versão 7 (em diante) começaram a surgir problemas com links permanentes no WordPress? Eu tenho a solução. Aconteceu comigo.

Sou fã do MAMP e uso desde priscas eras para programar em PHP e depois com o WordPress. Tudo funcionava lindamente, quando mais de repente, não consegui fazer os links permanentes funcionarem.

Me concentrei no WordPress, como é de praxe e como apareceu em diversos artigos de ajuda pela Web: gravar de novo as configurações dos links permanentes, alguma permissão errada etc. Nada deu certo.

Até que me dei conta de uma coisa: o que mudou foi o MAMP. Fui atrás de diversos artigos considerando o MAMP e sempre botavam a culpa no WordPress. Um caminho sem saída.

Até que lembrei de uma coisa simples: para os links permanentes funcionarem, o módulo mod_rewrite precisa estar habilitado no Apache. Meio óbvio e bem, sempre funcionou, porque não estaria habilitado dessa vez?

Pois bem, aparentemente a versão mais nova do MAMP vem com o mod_rewrite desabilitado. De fato, quando eu consultei o arquivo de configurações, a linha estava comentada.

Para habilitar o mod_rewrite em sua instalação do MAMP, segue os seguintes passos:

  1. Localiza a instalação da pasta MAMP. Em geral está em /Applications/MAMP, vou usar como base.
  2. Edita o arquivo
    /Applications/MAMP/conf/apache/httpd.conf
  3. Procura pela linha
    LoadModule rewrite_module modules/mod_rewrite.so
  4. Se houver um comentário na frente, assim
    #LoadModule rewrite_module modules/mod_rewrite.so
    O mod_rewrite está desativado. Precisas remover a cerquilha da frente da linha, deve ficar como listado no item 3.
  5. Grava o arquivo.
  6. Reinicia o servidor MAMP (fecha e abre o aplicativo).
  7. Pronto! Tudo deve voltar a funcionar.

Esta dica resolveu teu problema? Ou os erros 404 continuam a ocorrer? Deixa teu comentário, vamos trocar uma ideia.

Como resolver o erro “mysqlcheck: Got error: 2002: Can’t connect to local MySQL server through socket ‘/Applications/MAMP/tmp/mysql/mysql.sock’ (61) when trying to connect”

Se tu és um usuário antigo do MAMP, deves ter passado por aquele problema chato do MySQL não iniciar, seja quando se abre o MAMP ou diretamente no console.

Já vi várias soluções pela Web, incluindo matar processos ou reinstalar o MAMP, mas não chega a tanto. Aparentemente há um problema com os registros (logs) que ainda não foi solucionado (na época deste artigo o MAMP está na versão 6.8).

Dito isso, vamos ao passo-a-passo:

  1. Desligue o MAMP.
  2. Vá para a pasta /Applications/MAMP/db/mysql ou /Applications/MAMP/db/mysql57, a depender da versão do MAMP que tens em tua máquina.
  3. Procure por arquivos com o nome ib_logfile e um número. Apague ou mova para algum outro lugar, se quiseres guardar o documento, por segurança.
  4. Inicie o MAMP.

Pronto! Agora tudo vai funcionar bem. Bom, pelo menos até ocorrer este erro de novo. 🙂

Como eliminar marcações P adicionadas automaticamente pelo Contact Form 7

A partir de dezembro de 2022, o o CF7 passou a incluir marcações de parágrafo em todas as linhas. Como voltar ao comportamento anterior?

Alguns usuários mais antigos do plug-in Contact Form 7 devem ter sido surpreendidos nos últimos meses quando fizeram a atualização para as últimas versões, a partir de dezembro de 2022. Isso porque começaram a aparecer tags <p> entre as linhas do form, algo que não era o comportamento padrão deste tão adorado plug-in.

Na prática, o problema é que, com a atualização, algo que estava assim:

1. Form antes da atualização de dezembro de 2022 do Contact Form 7

passou a ficar assim:

2. Form depois da atualização de dezembro de 2022 do Contact Form 7, tela maior

e assim:

3. Form depois da atualização de dezembro de 2022 do Contact Form 7, tela menor

De fato, os programadores que gostam de ter um controle total do CSS das suas páginas podem ter que modificar muita coisa no seu código. Imaginem o tamanho do problema para quem tem atualizações automáticas na maioria dos seus projetos.

Felizmente, isso é fácil de desativar. Basta adicionar a seguinte linha no arquivo wp-config.php do website com problema:

define( 'WPCF7_AUTOP', false );

Entretanto, como uma instrução no wp-config.php vale para todo o WordPress, isso pode causar problemas no futuro, caso se mude o tema atual para um outro que já considere o comportamento novo. Portanto, talvez seja mais interessante fazer a correção direto no tema ou plug-in que faça uso do CF7 da maneira antiga.

Para fazer a correção apenas em um tema ou plug-in, adicione o seguinte filtro no arquivo functions.php:

add_filter('wpcf7_autop_or_not', '__return_false');

Pronto! Agora seu website voltou a ser lindo como antes!