As atualizações do WordPress e seus componentes de segurança
Saiba como ter um processo contínuo de atualização para garantir segurança.
Posso afirmar que boa parte dos erros em sites WordPress acontecem por falta de gestão.
Precisamos reconhecer que os “softwares são seres vivos”. E todo ser vivo precisa de cuidados, análises e melhorias.
Quanto maior e/ou mais complexo for sua presença digital, maior será a necessidade de gerenciamento.
Para te apoiar nesse desafio constante, eu selecionarei os erros em sites WordPress que você deve evitar a todo custo.
De imediato, vou resumi-los numa lista e em seguida vou detalhar e comentar sobre cada um dos 11 que abordaremos.
Os erros em sites WordPress que você deve evitar a todo custo
- Não atualizar o WordPress, plugins e temas em uso;
- Editar os códigos de um tema em vez de usar o conceito de Child Theme;
- Editar os códigos de um plugin em vez de usar o conceito de add-ons / extensão e etc;
- Deixar o mecanismo de debug do WP ativo em produção;
- Usar o prefixo de tabela padrão no banco de dados do CMS;
- Bloquear o acesso dos mecanismos de busca;
- Não usar o recurso de permalinks;
- Permitir a edição de arquivos de temas e/ou plugins através do wp-admin;
- Utilizar permissões erradas para arquivos e pastas;
- Permitir que o arquivo wp-config.php fique sem proteção;
- Deixar de fazer uso das constantes de segurança no wp-config.php.
Sobre não atualizar o WordPress, plugins e temas em uso
Na maioria das vezes você vai ganhar três vezes ao manter tudo atualizado: mais segurança, mais performance e novidades.
A cada nova versão os desenvolvedores procuram trazer melhorias e implementações diversas para agregar valor ao software em questão.
Bem como aplicam melhorias para deixar os códigos mais performáticos.
Quando uma brecha de segurança é descoberta, a principal forma de corrigir é aplicar a versão mais recente que a corrige.
É recomendado que você tenha diferentes ambientes – desenvolvimento, homologação e produção – para a sua aplicação e assim garantir os devidos testes antes dos updates.
Portanto, não atualizar o WordPress, plugins e temas em uso no projeto é um erro considerável em sites WP.
Sobre editar os códigos de um tema em vez de usar o conceito de Child Theme
Pense comigo: você comprou um tema (seja de prateleira ou desenvolvido de forma personalizada). Com o tempo decidiu alterar alguma parte do código. Uma brecha de segurança foi descoberta. O tema é atualizado é enviado para você. Agora você decide: atualizar, ficar seguro e perder as mudanças que você; ou não atualizar, ficar inseguro e manter suas modificações.
Para não ter que fazer escolhas desse tipo e considerar suas alterações, bem como as correções de segurança, você deve sempre adotar o conceito de Child Theme no WordPress.
Simplificadamente falando, funciona assim: o tema principal é o pai. Você cria outro tema, que será o filho, e nele realiza as alterações desejadas.
O filho herda todas as funções e características do pai, sendo o filho responsável por modificar os padrões herdados.
Logo, você atualiza o tema pai com segurança sempre que necessário.
Sendo um pouco mais técnico: ambos os temas estarão instalados no WordPress. Somente o tema filho será ativado no WP. Através do arquivo style.css do child theme ele vai referenciar, ou seja, informar qual é o tema pai.
Sobre editar os códigos de um plugin em vez de usar o conceito de add-ons / extensão e etc
A mesma lógica para os temas se aplica aos plugins. Ou seja, você não deve alterar o código do plugin e assim poder atualizar para as novas versões afim de desfrutar das melhorias e correções de segurança.
Você pode realizar alterações nesse plugin criando um outro. Isso mesmo, você cria um outro plugin para interferir no plugin desejado através dos hooks que ele disponibiliza usando as APIs do WordPress.
Boa parte dos plugins mais consolidados aplicam os mesmos conceitos do WordPress em relação a filters e actions para permitir que ele seja extendido.
Sobre deixar o mecanismo de debug do WP ativo em produção
Todo desenvolvedor precisa verificar o debug de um software para compreender o que está acontecendo por trás das cenas.
O WordPress tem um mecanismo próprio que pode ser ativado ou desativado. Além de poder configurar para exibir os erros na tela ou gravar em arquivo.
A lógica é assim: nos ambientes de desenvolvimento é recomendável fazer uso da solução. Já no ambiente de produção devemos evitar a todo custo. Dado que informações sensíveis são expostas, as quais podem ser utilizadas por pessoas más intencionadas.
Sugiro a leitura de um conteúdo nosso sobre a trilogia para um debug seguro e eficaz no WordPress.
Sobre usar o prefixo de tabela padrão no banco de dados do CMS
Todo mundo que conhece a estrutura padrão do WordPress sabe que o prefixo da tabela é o “wp_”.
Além disso, sabe também quais os nomes das tabelas que compõe o CMS mais utilizado no mundo.
Se o seu site estiver com brecha de SQL Injection, um hacker pode injetar códigos para realizar operações no seu banco de dados, dado que ele saberá os nomes das tabelas.
Portanto, não faça uso do prefixo padrão do WP no banco de dados do seu projeto. Considere utilizar algo como “wp_xUixyPi_”, por exemplo.
Sobre bloquear o acesso dos mecanismos de busca
Um dos grandes diferenciais do WordPress é sua fácil indexação pelos mecanismos de busca.
E sabemos que o tráfego mais desejado é o orgânico. Sabemos também que alguns sites chegam até 90%, ou mais, de acessos oriundos dos mecanismos de busca.
O WP, por padrão, tem uma configuração para desencorajar os buscadores de indexarem seu site.
Portanto, se você busca por tráfego orgânico considere não usar essa função de bloqueio dos buscadores no CMS.
A natureza de alguns projetos podem exigir tal bloqueio. Logo essa configuração pode ser uma mão na roda. Mas super recomendo ir além, dado que alguns buscadores costumam não ser muito respeitosos.
Sobre não usar o recurso de permalinks
Considerando o desejo de tráfego orgânico, outro recurso considerável são os permalinks.
Através deles podemos acrescentar palavras-chave na URL, ter um endereço mais amigável e evitar parâmetros de URL que não fazem sentido para os serem humanos.
O WP oferece vários tipos de forma nativa, além de permitir a customização do recurso e assim atender suas necessidades específicas.
Sobre permitir a edição de arquivos de temas e/ou plugins através do wp-admin
Na administração do WordPress são oferecidos dois editores de código: um para plugin e outro para tema.
Você pode achar isso um recurso legal e facilitador quando se precisa de editar algo no site de forma urgente.
Eu penso ao contrário, acho que é um recurso que permite a perda do controle de versão e abre brechas para edições indesejadas.
Seja por usuários sem experiência ou através uma invasão de crackers, spammers ou ativistas digitais.
Imagine que obtém seus dados de acesso a administração do site. Ou que você esteja vulnerável a ataques de força bruta e seus dados de acesso são descobertos.
A pessoa entra, faz uso do editor de código, injeta o código malicioso no seu tema e/ou plugins e concluir o serviço desejado.
Até você descobrir, e se descobrir, poderá ter tido significativos prejuízos de imagem, perda de tráfego e credibilidade.
Sobre utilizar permissões erradas para arquivos e pastas
Todo arquivo e pasta no WP tem suas devidas permissões requeridas.
Alguns arquivos especiais requerem permissões específicas. São os casos dos arquivos wp-config.php e debug.log, por exemplo.
E afirmo a você. Nenhuma pasta precisa da permissão 777. Repito nenhuma. Mesmo a pasta que recebe os uploads de arquivos.
Considere apresentar as permissões corretas para os arquivos e pastas do WordPress.
Sobre permitir que o arquivo wp-config.php fique sem proteção
Dentre as dezenas de milhares de arquivos que compõe o WP, sem dúvida alguma o mais importante é o wp-config.php.
Nele está contido as credenciais do seu banco de dados. Somente essa informação já seria digno da sua relevância.
Além disso, todas as principais configurações da plataforma estão nele.
Por isso, precisamos considerar as devidas proteções de segurança para esse arquivo.
Não o deixe sem proteção sobre hipótese alguma.
Sobre deixar de fazer uso das constantes de segurança no wp-config.php
Ainda falando de segurança, proteção e do arquivo wp-config.php.
Considere fazer uso das constantes voltadas para segurança que o WordPress disponibiliza para serem usadas no wp-config.php.
São várias possibilidades e temos um conteúdo específico sobre isso para te orientar a respeito.
Erros em sites WordPress são evitados com gestão
Eu te demonstrei somente 11 tipos de erros, falhas, esquecimentos ou falta de devida atenção que acontecem com os sites WordPress.
É preciso gerir dezenas de itens de forma contínua para garantir segurança e uma operação sem soluços.
O desafio é grande. Mas te oriento, de imediato, a considerar evitar os erros aqui abordados.
Mas não se iluda, toda e qualquer plataforma tem desafios semelhantes.
O único caminho que conheço para evitar erros em sites WordPress, ou alguma outra plataforma, é ter gestão sobre ele.
Quando digo gestão, estou me referindo a executar processos para essas questões, ter fluxos contínuos para sustentar e corrigir o que for preciso. Seja quando o projeto for publicado, seja a cada alteração publicada ou de forma regular a cada determinado período de tempo.
Como a Apiki ajuda milhares de empresas
Como uma empresa focada e especializada em WordPress, nossas soluções para WordPress são direcionadas para ajudar empresas em seus desafios na criação e gestão de sites WordPress.
Consideramos processos para todas as questões aqui abordadas e fluxos contínuos durante toda a nossa jornada de atendimento aos projetos dos nossos clientes.
A cada nova versão do WP, o que acontece de três a quatro vezes por ano, revisamos tudo para aprimorar nossa prestação de serviços.
Além disso, compartilhamos conteúdos como este para ajudar que atua de forma independente.
Tag de Aproximação Gastronomia 
