10 dicas para tornar a manutenção do WordPress suave

Como desenvolvedor WordPress que trabalhou em vários tipos de projetos, gostaria de discutir alguns dos pontos problemáticos que experimentei pessoalmente ao assumir um site WordPress existente para edições ou correções de bugs. As dicas e sugestões listadas neste artigo visam minimizar ou até mesmo livrar-se dessas dores.

Por que a manutenção adequada do WordPress é importante

Na maioria das vezes, os sites não são um caso de “configurar uma vez e deixar em paz”, e isso é verdade para todos os sites, não apenas para os do WordPress. De tempos em tempos, você terá que lidar com edições, atualizações ou correções de bugs, que seu desenvolvedor favorito cuidará. No entanto, em alguns casos, você pode precisar contar com vários desenvolvedores diferentes ao longo da vida útil do seu site.

No último caso, as coisas geralmente não correm bem para o desenvolvedor de entrada, especialmente se os desenvolvedores anteriores não aderiram às práticas recomendadas ao lidar com suas tarefas de manutenção.

Vamos ver alguns dos pontos mais importantes a serem considerados em seus futuros trabalhos de manutenção em projetos WordPress para que você possa facilitar a vida do seu próximo desenvolvedor e fazê-los adorar trabalhar em seu site. Obviamente, facilitar o trabalho do seu desenvolvedor também economiza algumas horas de trabalho e dinheiro no processo, o que é sempre um bom ponto de venda para seus clientes em potencial.

1. Faça backup!

Isso pode parecer muito óbvio, mas a primeira coisa é a primeira! Você precisa fazer backup do seu site WordPress de forma adequada e regular.

Essa é uma das coisas mais fundamentais a fazer, mesmo que você não esteja fazendo nenhuma alteração no seu site no momento. Você pode fazer isso manualmente, pegando todos os arquivos mais o dump do banco de dados e armazenando-o em um local seguro, ou pode usar uma opção de backup automatizado, cortesia de um plugin de backup do WordPress. Existem muitos plugins gratuitos e pagos que você pode encontrar no repositório de plugins do WordPress. Você também pode fazer bom uso da opção de backup no nível do servidor, pois a maioria dos provedores de hospedagem oferece opções de backup – isso é algo que você precisa verificar com seu provedor de hospedagem.

Com backups regulares, você tem a tranquilidade de saber que seu site estará funcionando novamente após uma falha ou um erro. Isso também pode ajudar seu novo desenvolvedor a corrigir problemas sem muito aborrecimento, especialmente se você estiver tentando corrigir um bug que suspeita ter ocorrido durante a manutenção no passado. Backups regulares devem ajudar seus novos desenvolvedores a identificar e resolver problemas persistentes, que ocorreram meses ou anos antes de eles assumirem o projeto.

2. Instale seu site WordPress localmente

Não tenho orgulho de admitir que cometi esse erro nos meus primeiros dias e, desde então, tenho notado que muitos desenvolvedores realizam edições diretamente no servidor remoto. A menos que você esteja preocupado em ter dados confidenciais e todos os arquivos do site à mercê do seu desenvolvedor, você deve evitar esse erro para sempre. É muito ineficiente alternar entre a máquina local do desenvolvedor e o servidor após cada edição.

Mesmo que seja uma pequena alteração, como uma pequena edição para alterar um pouco de texto em seu site, o desenvolvedor precisa navegar até o arquivo/pasta correspondente no cliente FTP (se você estiver usando FTP para uploads de arquivos), aguarde os arquivos a serem carregados e esperamos que não haja falhas ocasionais de conexão FTP. Não vamos esquecer que alguns sites WordPress têm muitos dados para mover praticamente, sem perder muito tempo e largura de banda. E, depois que tudo é carregado com sucesso, eles precisam ir ao navegador e atualizar a página que, novamente, depende da velocidade e condição da rede/servidor naquele momento. Pode parecer que estamos falando de meros minutos e segundos que podem ser economizados com cada alteração, mas ao longo do seu projeto, esses minutos podem resultar em horas de trabalho desnecessário.

As edições são muito mais rápidas se seus desenvolvedores tiverem o site instalado em sua máquina local: eles só terão que fazer as edições, atualizar a página e pronto. Mesmo que estejam vivendo dentro de uma caverna sem qualquer conexão com a internet, eles ainda podem trabalhar e fazer o upload de suas alterações posteriormente.

E se você tiver dados confidenciais com os quais está preocupado ou se houver alguns motivos legais que o impeçam de compartilhar todos os seus dados com os desenvolvedores? Nesse caso, você pode preparar alguns dados fictícios especificamente para essa finalidade. Você também pode manter esses dados reservados para manutenção futura.

3. Vá para o Git

Uma das melhores coisas que acontecem no mundo do desenvolvimento de software é o surgimento do controle de versão online. Eu trago este ponto porque há muitos sites ainda em execução com o método tradicional cPanel/FTP para lidar com arquivos. Ou eles não sabem o quão bom é o controle de versão, ou sabem disso, mas hesitam em implementá-lo por causa do esforço inicial de configuração. No entanto, na verdade não é muito trabalho, e é tudo menos uma tarefa difícil.

O controle de versão vem com uma série de benefícios quando se trata de gerenciamento de arquivos, que inclui rastrear alterações por vários autores, reverter edições facilmente, capacidade de ter ramificações separadas para cada tarefa independente para garantir que as alterações de cada tarefa não interfiram nas outras.

Você precisa configurar o Git em um servidor externo, que na maioria das vezes é pré-instalado pelo seu provedor de hospedagem. Você pode precisar de alguém com alguma experiência em servidores para iniciar o repositório e configurar o fluxo de trabalho, o que não vou discutir aqui porque está além do escopo deste artigo.

E para não mencionar, você não está realmente “git'ing” se você não fizer uso de branches! Faça pelo menos duas ramificações para desenvolvimento e produção para que os desenvolvedores possam fazer todo o trabalho na ramificação de desenvolvimento, testar o site e, se tudo estiver bem, enviar para a ramificação de produção, certificando-se de que nada dê errado no site ativo.

4. Remova arquivos, códigos e plugins desnecessários

É comum deixar arquivos e plugins que não são mais necessários. Isso se torna uma dor quando os arquivos se acumulam ao longo do tempo ao longo do ciclo de vida do seu site. Se o seu desenvolvedor não se importou em remover arquivos indesejados que foram adicionados ao longo do tempo, é difícil rastrear de onde veio e se está sendo usado por alguma parte do site ou não. Isso causa uma dor de cabeça adicional, pois o site deve ser testado mais uma vez para garantir que nada quebrou após a remoção desses itens suspeitos.

Isso pode ser eliminado removendo arquivos indesejados imediatamente pelo desenvolvedor correspondente que trabalhou nele. Você pode enfatizar essa prática para todos os seus desenvolvedores.

Além de arquivos PHP e plugins, arquivos de mídia não utilizados também podem preencher sua pasta wp-content ao longo do tempo, o que pode causar problemas para seus desenvolvedores ao trabalhar com qualquer funcionalidade relacionada a mídia. Você pode encontrar vários plugins para simplificar essa tarefa. Um exemplo é o Limpador de Mídia.

O plugin possui uma lixeira interna, movendo os arquivos para lá temporariamente para você ter certeza de que os arquivos não estão realmente em uso; uma vez marcado, você pode lixá-los permanentemente. Certifique-se de seguir o ponto número 1 deste artigo (ou seja, fazer backup) antes de limpar qualquer um dos seus arquivos.

5. Comentando

Você provavelmente está familiarizado com o meme de programação que é mais ou menos assim: Quando o código foi escrito, foi entendido pelo autor que o escreveu, colegas de trabalho e Deus. Depois de algum tempo, apenas o autor e Deus sabiam o que ele faz, e agora só Deus sabe o que ele faz – a menos que o autor tenha adicionado comentários apropriados!

Alguns desenvolvedores podem ser relutantes ou completamente preguiçosos quando se trata de comentar, mas é uma prática obrigatória em um bom ambiente de desenvolvimento. Ele reduz o tempo de edições e correções de bugs que, de outra forma, seriam gastos pelos novos desenvolvedores ou mesmo pelo mesmo desenvolvedor para descobrir o que um bloco de código específico faz.

Comentários devem ser adicionados sempre que a função/classe ou bloco de código não for algo óbvio, tome a seguinte função por exemplo:

 function stripWhiteSapaces(str) { … Return str; }

O nome da função acima fala por si e também não há necessidade de o usuário entrar na função para ver como ela funciona, está apenas fazendo um trabalho, removendo os espaços em branco – é isso! Portanto, neste caso, os comentários podem não ser necessários.

Mas, por exemplo, se houver uma função que aceita vários parâmetros e retorna uma lista filtrada de postagens, isso não é algo óbvio como o anterior. Deve haver comentários descrevendo os parâmetros e seus tipos. Também pode ser necessário descrever os blocos de código dentro desta função.

Para uma verificação rápida, você pode pegar um arquivo do núcleo do WordPress e ver como os especialistas do WordPress comentaram. Ou, para informações mais detalhadas, você pode consultar o guia oficial do WordPress que ilustra bem isso.

6. Forro

Linting é outro recurso legal que impõe regras na maneira como escrevemos código e, às vezes, corrige a própria formatação do código, o que é legal e útil. A maioria dos IDEs em uso hoje vem com opções de linting, que você pode melhorar ou personalizar ainda mais adicionando várias configurações de linting.

Por exemplo, ao usar o Visual Studio Code como seu IDE, o VS Code usa o linter oficial do PHP ( php -l ) para diagnóstico de linguagem PHP. Você pode configurar regras/restrições para cada idioma separadamente (ou seja, PHP, JavaScript, CSS etc.). Você pode dar uma olhada nos Padrões de Codificação do WordPress para mais detalhes.

• https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
• https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/

Depois de ter uma configuração de linting, você precisa aplicá-la. Todos os seus desenvolvedores atuais e futuros precisam integrar essa configuração de linting aos seus IDEs para que seus códigos também sigam as mesmas regras/restrições. Caso contrário, muito do seu esforço será em vão.

7. Nomeação de Variáveis ​​e Arquivos

Elabore um padrão para lidar com a forma como as coisas são nomeadas. Isso inclui nomes de funções/classes, nomes de variáveis, nomes de arquivos e até mesmo nomes de mídia/imagem se fizerem parte do modelo, pois também ajudará a entender para que servem.

Considere alguns dos pontos vitais:

1. Evite nomes inequívocos
2. Mantenha-o curto quando possível
3. Às vezes é muito útil acrescentar o “tipo” ao nome do arquivo. Por exemplo, se for um ícone, você pode ter algo como BlackArrowIcon.png ou se for uma grande imagem de fundo pode ser algo como FrontYellowBG.jpg. Ou se for um arquivo de código, às vezes é muito fácil saber o que esse arquivo representa ao trabalhar com vários arquivos abertos em várias guias no IDE. Por exemplo, se houver uma classe com funções auxiliares, será útil se ela se chamar HelperClass.php em vez de Helper.php.

Para obter mais informações, consulte a seção Convenções de nomenclatura no guia de práticas recomendadas do WordPress.

8. Depuração do WordPress

A depuração pode levar uma quantidade significativa de tempo e tende a comandar uma alta participação no tempo total de desenvolvimento, especialmente quando se trata de edições ou correção de bugs. Isso significa que você deve observar se seus desenvolvedores estão fazendo isso da maneira mais eficiente possível. A maioria dos desenvolvedores são propensos a fazer isso manualmente var_dump 'ing as variáveis ​​em alguma parte da página da web que não é o método mais eficiente. Isso também pode causar dores de cabeça para os desenvolvedores que ingressarem no projeto mais tarde, pois eles acabarão com linhas de código inúteis aqui e ali se o código de depuração não for limpo corretamente após o trabalho ser concluído.

Existem alguns plugins para ajudar nessa tarefa de depuração. A seguir estão alguns exemplos dos plugins de depuração populares para WordPress.

• Depurador Kint
• Barra de depuração
• Monitor de consultas

9. Tenha um CSS melhor

Quando se trata de desenvolvimento web, estilizar com CSS é uma das atividades mais básicas. Infelizmente, isso significa que é frequentemente negligenciado e recebe menos atenção do que JS, PHP, etc. Mas, acredite ou não, o CSS pode causar uma quantidade enorme de problemas se não for arquitetado corretamente quando você tentar adicionar ou editar algo no futuro, a menos que seu site seja básico e pequeno.

Se você estiver interessado em saber mais sobre por que essa técnica de estilo relativamente básica é propensa a problemas, você pode pesquisar no Google por que o CSS é irritante ou pode ler mais sobre as 5 coisas mais irritantes com CSS.

Aqui estão algumas dicas rápidas do meu lado sem muitos detalhes:

• Aplique uma boa prática de nomenclatura. Use uma metodologia de nomenclatura como BEM (Block Element Modifier)
• Evite o estilo inline. Em vez disso, use folhas de estilo externas.
• Tente criar padrões reutilizáveis ​​comuns sempre que possível, sem apenas aumentar os estilos sempre que necessário.
• Divida estilos em vários arquivos com base nos recursos ou áreas do site. Se você está preocupado que um número maior de arquivos de estilo possa afetar o desempenho de carregamento, você pode superar isso usando um bom plug-in de cache que consolidará vários arquivos em um único arquivo.
• Faça uso do pré-processador CSS, como SASS, LESS e assim por diante.

10. Obtenha feedback dos desenvolvedores atuais

Como pensamento final, e para completar a lista, você pode obter feedback de seus desenvolvedores sobre os problemas que eles enfrentaram ao trabalhar em seu site. Eles podem dar alguns bons conselhos, pois são eles que sujam as mãos em seu site. Eles também podem apontar falhas ou código sujo que foi deixado por desenvolvedores anteriores.