Os pontos críticos do WordPress: a perspectiva de um desenvolvedor

Cada vez mais desenvolvedores acabam usando um CMS como o WordPress, mesmo não gostando da plataforma.

Os desenvolvedores qualificados geralmente preferem usar soluções personalizadas, especialmente quando você é um desenvolvedor realmente bom em codificação. Com uma solução personalizada, você pode criar aplicativos muito elegantes que funcionam muito bem. No entanto, os desenvolvedores acabam usando um CMS como o WordPress, mesmo que não gostem muito da plataforma.

Este artigo é destinado a esses desenvolvedores e aborda muitos dos desafios encontrados ao trabalhar com o WordPress (WP). Vamos explicar quais são essas dificuldades e também dar uma sugestão: a ajuda do Plesk, que disponibiliza um kit de ferramentas WP que realmente ajuda a levar em conta algumas das principais criticidades do CMS mais amado do mundo: o WordPress.

Por que os desenvolvedores usam o WordPress

Não se engane, o WordPress é o CMS mais popular do mercado por boas razões. Nesta seção, descrevemos por que o CMS é tão popular até mesmo entre desenvolvedores experientes que podem realmente escrever seu próprio código.

Em primeiro lugar, o WordPress é super fácil de instalar. Tudo o que você precisa é o ambiente LAMP/LEMP padrão – Linux, Apache/Nginx, PHP e MySQL/MariaDB como DBMS. Se você tiver, você pode começar a instalar o WordPress.

A personalização é igualmente fácil porque o WP CMS vem com uma grande variedade de complementos, incluindo temas para personalizar a aparência e comportamento do front-end e plug-ins que adicionam funcionalidade. Também é possível construir seu próprio tema e desenvolvedores experientes também podem fazer seus próprios plugins, mas esse processo é mais complexo.

Talvez a maior razão para a popularidade do WordPress seja, claro, o fato de ser acessível a usuários não técnicos. Uma vez instalado, o WP não requer experiência em codificação ou compreensão do software para funcionar bem, os usuários novatos podem publicar um site e configurar uma instância do WordPress logo após o trabalho.

Qual é exatamente o problema com o WordPress?

Bem, o CMS mais popular do mundo tem muitos problemas a considerar. Não pretendemos fazer barulho sobre os problemas do WordPress, mas o que se segue é uma discussão franca e esperamos que a equipe de desenvolvimento por trás deste incrivelmente popular CMS considere os seguintes pontos como uma crítica positiva. Veja por que achamos que o WordPress é frustrante para os desenvolvedores:

Amplamente capaz, mas nunca excelente

O início do WordPress foi simples. O WP nasceu para ser uma plataforma para quem queria escrever e publicar um blog. O CMS mudou completamente ao longo dos anos e agora não é nada como seu começo humilde. Tem gente que usa como sistema básico para gerenciar um site inteiro, como plataforma para lojas online e até como forma de gerar sites estáticos (loucura, mas já vimos isso ao longo dos anos também)

Isso meio que destaca como o CMS é adaptável e concordamos com essa afirmação, mas o problema de ser tão flexível é que fica difícil se destacar em qualquer função. Uma maneira de perceber isso é olhar através das lentes do plug-in: os milhares de plug-ins do WordPress disponíveis mostram como as pessoas estão tentando forçar o WordPress a ser algo que simplesmente não é ou pior, a fazer algo de que não é capaz. faz, dói. É por isso que nós, quando usamos o WordPress e o usamos com frequência e de boa vontade, nunca o carregamos com plugins que não sejam estritamente necessários. Nesse ponto, preferimos fazê-los nós mesmos.

Claramente, o WordPress é feito para esta abordagem "self-made" e, obviamente, a flexibilidade tem muitas vantagens, sem dúvida. Mas sem um foco forte em uma tarefa específica, o CMS luta muito para oferecer uma solução clara. Esse foco em tentar ser tudo para todos está causando enormes problemas. No entanto, temos que ressaltar: o WordPress ainda funciona bem como uma plataforma para a construção de blogs e sites não complexos e sites de comércio eletrônico.

Hacks e rachaduras: o WordPress pode ser uma porta aberta

Resumindo, o WordPress é hackeado o tempo todo e é a maior reclamação que ouvimos do mundo dos desenvolvedores. Não tem como negar, o CMS é cheio de brechas de segurança, não acaba nunca. É como um cobertor curto: você ajusta de um lado e descobre do outro. Em parte, o número de hacks se deve à popularidade do WordPress, mas também ao fato de o WordPress ser de código aberto.

Como qualquer pessoa pode visualizar o código-fonte aberto do CMS, isso permite que os hackers encontrem pontos fracos no código. Não queremos dizer que o código-fonte aberto seja uma abordagem ruim, mas achamos que a natureza de código-fonte aberto do WordPress CMS está contribuindo para seus problemas de segurança intermináveis.

A análise mostra que os sites WordPress representam mais de um quarto da internet. A equipe do WordPress sabe disso e tenta fazer tudo o que pode para garantir que o CMS seja seguro, mas com os ciclos de desenvolvimento tão rápidos hoje em dia, pode ser difícil proteger totalmente um aplicativo complexo. E quando os esforços de segurança falham, milhões de sites podem estar em risco.

Não temos uma solução óbvia para os desafios de segurança do WordPress além, é claro, do óbvio “atualize sua instância do WordPress”. Mesmo assim, o ciclo de lançamento do WordPress traz consigo problemas únicos e intermináveis.

Muitas pessoas dizem que cuidar da segurança do WordPress é simples, e isso é verdade em grande parte, mas a questão é por que os proprietários de sites devem fazer uma lista de tarefas para garantir que o WordPress seja seguro? Por que essa segurança não é parte do WordPress pronta para uso?

• É fácil para alguém carregar um arquivo executável no WordPress, e essa opção deve ser limitada por padrão. Basta uma pessoa um pouco esperta para carregar um arquivo com código malicioso em um script PHP e seu site fica comprometido.
• Atualmente, as opções podem ser configuradas no sistema de arquivos. Em vez disso, o WordPress deve remover isso e assumir que o sistema de arquivos é “somente leitura”. Embora o núcleo do WordPress faça isso, os plugins não seguem esse padrão de comportamento. Se você encontrar um plug-in que altera seu arquivo de configuração enquanto está ativamente em produção, pare de usá-lo. Isso indica um sistema de arquivos gravável e, consequentemente, uma maneira fácil de fazer alterações maliciosas. Uma solução é remover o arquivo wp-config.php da raiz do sistema (WordPress funciona de qualquer maneira), mas não é uma garantia total de segurança e, em qualquer caso, impede o funcionamento correto de muitos plugins escritos por desenvolvedores inconscientes .
• Por padrão, o WordPress permite que os usuários façam quantas tentativas de login quiserem. Isso abre a porta para um ataque de força bruta em que os hackers continuam tentando senhas aleatórias até que o login seja bem-sucedido. O WordPress CMS deve desabilitar tentativas ilimitadas de login na instalação.

Esta não é uma lista exaustiva, são apenas alguns pontos. Obviamente, uma grande solução de software, especialmente uma solução de código aberto, não pode ser completamente invulnerável a ataques. Mas nosso ponto é que desenvolvedores sérios relutam em usar o WordPress precisamente porque ele é muito vulnerável. Os desenvolvedores qualificados preferem criar um novo aplicativo que atenda elegantemente às suas necessidades e possa ser rigorosamente protegido – sem se preocupar com vulnerabilidades futuras desconhecidas.

Ou, fazendo o melhor uso das configurações do PLESK e não carregando o WordPress com plugins “não recomendados” ou pior “grátis” ou pior ainda mal escritos (você precisa de experiência na área para poder fazer julgamentos sobre isso), você ainda pode tornam o WordPress uma excelente plataforma também em termos de segurança. Mas não é mais um gerenciamento do tipo "faça você mesmo", é necessária uma mão especializada.

Plugins como fonte de problemas

Um bom desenvolvedor não recorre a um plugin na primeira vez que fica preso. Em vez disso, bons desenvolvedores tentam construir uma solução simples e elegante. Pelo contrário, confiar sempre em plugins procurando por eles na internet ou confiar naqueles sugeridos pela Comunidade é uma forma de pensar muito equivocada.

Em última análise, um plug-in facilita a adição de funções específicas ao WordPress, o que torna a ampla gama de plug-ins disponíveis para WP um ponto forte do CMS – mas também é um risco. Por mais que os plug-ins possam tornar as coisas mais fáceis e rápidas, os plug-ins também representam muitos riscos de segurança e, ao mesmo tempo, forçam você a escolher qual versão do WP você pode usar e, ao mesmo tempo, aumentam sua instância do WordPress além da crença. medida frustrando ou também colocando em crise a sua presença online, a velocidade de abertura do site e consequentemente a acessibilidade e consequentemente a correta indexação nos motores de busca.

Plug-ins e segurança

Primeiro, vamos ver os problemas de segurança que os plug-ins criam. Um relatório sugere que mais da metade dos problemas de segurança conhecidos do WordPress decorrem de plugins. Os desenvolvedores estão sujeitos a todas as boas práticas seguidas por um criador de plugins – o que pode não ser tão bom. Portanto, como desenvolvedor, você deve testar minuciosamente um plug-in antes de usá-lo. Até certo ponto, esse processo de verificação pode remover o tempo que você economiza com plug-ins, então, nesse ponto, você também pode considerar desenvolver do zero o recurso necessário para adicionar ao site.

Limites nas versões do WP

Conhecido como “restrição de versão”, os plug-ins podem limitar qual versão do WP CMS você pode executar. Agora, o WordPress é muito agressivo com seu ciclo de lançamento, por isso lança regularmente uma nova atualização e, de fato, muitas vezes acontece que a plataforma lança várias pequenas versões ou patches em um determinado mês. Isso é compreensível, pois a equipe WP está constantemente corrigindo vetores de ataque. No entanto, todas essas atualizações têm um problema: uma atualização do WP pode interromper um plug-in, fazendo com que seu site pare de funcionar ou trave.

Claro que você precisa manter seu CMS atualizado, mas as restrições de versão impostas pelos plugins podem dificultar esse trabalho. Alguns desenvolvedores de plugins estão sempre testando e atualizando seus plugins, mas esse pequeno "mundo" de plug-in premium não representa a maioria. Fora desses plug-ins premium, existe um risco real de que uma atualização de versão do WP possa literalmente quebrar o site.

Excesso de plug-ins

Vamos supor que a maioria dos desenvolvedores saiba que é importante criar projetos enxutos que não usem código em excesso. Agora, alguns plug-ins obedecem a esse princípio, mas muitos plug-ins são muito inchados porque tentam resolver todos os problemas que um usuário possa ter. É comum que um desenvolvedor descubra que um plug-in resolve um problema enquanto oferece uma solução para cinquenta outros problemas não relevantes para seu site. (Sem falar nos temas e "construtores").

Plugins interrompem seu fluxo de trabalho do WordPress

Por fim, outro problema comum que muitos plugins criam é o fato de um plugin poder atrapalhar a experiência do usuário no WordPress, isso depende, infelizmente, do efeito plugins de inchaço do WordPress. Por exemplo, um plugin pode mudar completamente a forma como um post é criado e divulgado pelo site.

Isso resulta em um problema que os desenvolvedores do WP geralmente enfrentam, eles sentem que precisam "contornar" demais um plug-in, em vez de apenas usar o plug-in. Inevitavelmente, os desenvolvedores assumem esse processo de ignorar plug-ins porque esse plug-in pode parecer estar resolvendo um problema de processo (que inevitavelmente não existe).

A arquitetura da Web evoluiu

Já mencionamos que o WordPress já existe há algum tempo. Quando foi construído, os desenvolvedores presumiram que um site sempre usaria um único servidor, juntamente com um único sistema de arquivos. No entanto, os desenvolvedores estão usando cada vez mais o que é chamado de arquitetura de microservidor que faz uso de vários nós. Eles fazem isso porque essa forma de trabalhar é mais escalonável e flexível. Mas usar o WordPress em uma arquitetura complicada pode criar problemas, por exemplo, o uso quase exclusivo de FTP para atualizações do WP CMS.

Os desenvolvedores modernos obviamente pensariam que atualizar o código via FTP é meramente arcaico. Os desenvolvedores geralmente usam um fluxo de trabalho específico para que possíveis problemas possam ser interrompidos antes que o código se torne operacional. Isso significa que o desenvolvimento é feito localmente, o código é controlado por versão e esse código também é testado automaticamente – tudo por meio de um processo de integração contínua. Portanto, basta carregar o novo código em um ambiente que executa loops curtos, o que significa que há uma alta probabilidade de que as coisas possam dar errado.

Maior do que o problema de correção é simplesmente a suposição de que estamos trabalhando com um único sistema de arquivos em um único nó. Um cluster de vários nós de servidores da Web melhora tanto as falhas de hardware quanto o desempenho, e é por isso que essa abordagem está sendo cada vez mais adotada. O WP tem um obstáculo, no entanto, porque instalar um tema ou atualização de plugin via FTP significa que apenas um sistema de arquivos pode ser atualizado por vez. Portanto, com um cluster de vários nós, você precisa fazer essa atualização para cada nó.

Os desenvolvedores podem contornar esse problema, mas continua sendo uma dificuldade que não é facilmente resolvida. Além disso, o processo exige que o sistema de arquivos seja gravável, o que, por sua vez, traz uma grande preocupação de segurança para o banco de dados, que é o coração pulsante do WordPress.

Dados órfãos e estrutura de dados em geral

A princípio, a estrutura de dados do WordPress é simples. No entanto, logo descobre que existem tabelas redundantes no banco de dados do WP. Por exemplo, por que os metadados precisam ser separados em duas tabelas: uma chamada "wp_posts" e outra chamada "wp_postmeta"? Não é melhor incluir todos os dados em uma tabela? O mesmo vale para a tabela de comentários, que possui uma segunda tabela associada para seus metadados.

O resultado é que há dados extras deixados em todo o banco de dados. Sim, o WP inclui alguns recursos que ajudam a reduzir o efeito de dados órfãos, mas as funções falham quando você precisa manipular uma contagem de milhares de linhas. Basicamente, os recursos do WordPress causam timeouts do servidor e levam a vazamentos de memória e simplesmente não são eficazes.

Claro, você pode optar por simplesmente reduzir os dados órfãos escrevendo diretamente as consultas SQL para fazer isso. Mas você precisa entender completamente como as tabelas são conectadas para poder escrever as consultas SQL corretas. O grau de separação de dados no banco de dados do WordPress acaba sendo supérfluo.

O que o Plesk Toolkit for WordPress faz para melhorar as coisas

O WordPress Toolkit do Plesk é uma maneira fácil de configurar e personalizar uma instância do WordPress, tudo a partir de um único painel de controle. Você pode usá-lo desde que esteja instalado em seu site. Aqui estão algumas áreas onde o WordPress Toolkit ajuda a cuidar do WP:

Gerenciamento de segurança

Com o kit de ferramentas, você pode fechar automaticamente as brechas de segurança mais óbvias. Por exemplo, você pode alternar o ping de XML para RPC, garantir que a pasta “wp-content” seja segura e muito mais. O kit de ferramentas exibe o status de segurança do seu site e sinaliza problemas com “perigo” ou “aviso”, que é uma recomendação para melhorar a segurança.

Atualizando sua instância do WP

Disponível como um recurso complementar no Toolkit 3.xe posterior, o recurso Smart Updates permite manter um site de produção em execução e atualizá-lo ao mesmo tempo, sem o risco de danificar o site. A ferramenta verifica se há problemas que podem ocorrer devido à atualização e informa se há algum tipo de risco.

Clonazione

Existem inúmeras razões pelas quais você pode querer fazer uma cópia do seu site WordPress. Por exemplo, você pode ter um site de teste onde pode testar as alterações antes de entrar no ar. Depois de pronto, você gostaria de copiar o conteúdo do site.

Ou você pode ter um site público e pode querer fazer uma cópia dele que não deseja que o público tenha acesso. Outro exemplo são os desenvolvedores profissionais que possuem uma cópia modelo de uma instalação do WordPress e desejam apenas cloná-la, incluindo temas e plugins, automaticamente.

Também temos clientes que querem apenas fazer algumas cópias de um site por vários motivos, como para demonstrar como um site pode ficar diferente com algumas alterações.

Seja qual for o motivo, a ferramenta de clonagem no WordPress Toolkit facilita a cópia de tudo, incluindo arquivos do site, banco de dados do site e todas as configurações do WP CMS.

sincronização

Por vários motivos, você pode querer garantir que dois sites WordPress correspondam. O WP Toolkit permite sincronizar automaticamente o banco de dados WP e todos os arquivos WP.

Se você tiver uma cópia de teste do seu site, enquanto sua cópia pública estiver em execução em outro lugar, talvez queira sincronizar os sites porque deseja copiar as alterações feitas no site de teste para o site ativo do WP.

Da mesma forma, você pode querer copiar alguns dados do site de produção para sua instância de teste para que possa verificar se as alterações feitas na versão de teste funcionam bem com os dados ativos. Ou as alterações feitas em seu site de teste causaram uma alteração em suas tabelas de banco de dados; nesse caso, o kit de ferramentas só permite que você sincronize essas alterações com seu banco de dados, se desejar.

Outro caso de uso do recurso de sincronização do WP Toolkit é quando um desenvolvedor atualizou um site de teste para uma versão de varejo do WordPress e deseja espelhar as alterações em um site ativo.

Você tem a opção de sincronizar todo o WP CMS ou apenas algumas partes dele. Assim, você pode espelhar os arquivos do seu WP, seu banco de dados ou ambos. Há mais granularidade em oferta, pois você pode escolher entre sincronizar todo o banco de dados ou apenas tabelas, ou mesmo tabelas que estão na origem, mas não estão presentes no destino. Também é possível espelhar tabelas individuais.

Caça a bugs no WP

O Plesk WordPress Toolkit também permite que os desenvolvedores detectem e corrijam erros automaticamente na fonte do site, ativando seu modo de depuração.

Conclusão.

Depois de tudo o que foi dito acima, fica claro que se torna extremamente importante escolher não apenas o desenvolvedor com quem trabalhar ou a agência que pode acompanhá-lo, mas acima de tudo a hospedagem na qual hospedar seu site em WordPress. Mesmo com essas coisas, entendemos o que significa ter um site escuro em uma hospedagem profissional ou não.

O WordPress não é um “objeto” fácil de manusear. Claro, você se sente livre, acha que não precisa de desenvolvedor ou não está vinculado a uma agência, acha maravilhoso poder fazer você mesmo mas na realidade a verdade diz o contrário e hoje segurança é um tema que está não mais secundária, mas primária também em virtude das obrigações e responsabilidades para com terceiros.