Uma comparação detalhada entre o WordPress e o CMS de outubro

Três meses atrás, o WordPress finalmente lançou o Gutenberg, com tecnologia React, para potencializar sua experiência de edição de conteúdo padrão, fazendo com que muitas pessoas que não estão satisfeitas com essa mudança procurem alternativas. Algumas pessoas decidiram fazer um fork e lançar o WordPress pré-Gutenberg, no entanto, para mim, isso não faz muito sentido, pois ainda carrega 15 anos de dívida técnica. Se eu encontrasse uma alternativa ao WordPress, tentaria evitar ficar preso no passado e procuraria um corte limpo em alguma plataforma madura construída em fundações modernas.

Este artigo compara o WordPress ao CMS de outubro indiscutivelmente semelhante, mas mais moderno, em uma ampla variedade de tópicos técnicos e não técnicos. O objetivo do artigo não é convencer as pessoas a se ater ao WordPress ou a mudar para o CMS de outubro, mas simplesmente demonstrar quais aspectos devem ser levados em consideração antes de concluir a mudança para uma plataforma diferente. A mesma comparação pode (e deve) ser feita também com outras plataformas antes de tomar uma decisão sensata.

Por que outubro CMS

Descobri o CMS de outubro quando ele ganhou um prêmio, depois do qual entrei no modo de pesquisa e passei muito tempo investigando profundamente esse CMS - da perspectiva de um usuário e um desenvolvedor. À medida que adquiri conhecimento sobre este CMS, senti-me confiante de que poderia fornecer uma avaliação objetiva de seus recursos em comparação com o WordPress. Escolhi este CMS para comparação com opções alternativas como Grav, Statamic, ButterCMS, Joomla, Drupal, Jekyll, Hugo e outros, pelos seguintes motivos:

• Eu sei como esse CMS funciona (diferente do Grav);
• É gratuito e de código aberto (ao contrário de Statamic e ButterCMS);
• Aos cinco anos, é “relativamente” novo (ao contrário do Joomla e Drupal);
• É um gerador de conteúdo dinâmico (não estático) e baseado em PHP (ao contrário de Jekyll e Hugo).
  

Acredito que o October CMS seja um bom candidato porque é baseado no Laravel que é um framework usado para construir aplicações modernas. Após sete anos de existência, recebeu aprovação positiva dos desenvolvedores (como evidenciado por sua comunidade e ecossistema consideráveis), e marca um contraste distinto sobre a codificação no WordPress, ou seja, o WordPress é principalmente programação procedural, enquanto o Laravel é decididamente programação orientada a objetos.

Qual a diferença entre os dois?

Abaixo, vou comparar o WordPress e o CMS de outubro em diferentes categorias e destacar o que, acredito, é bom e não tão bom neles. No entanto, não vou escolher um vencedor, pois esse não é o objetivo do artigo e, de qualquer forma, não há CMS “melhor” ou mesmo “melhor”: cada CMS tem seu próprio conjunto de pontos fortes e fracos que o tornarão mais ou menos adequado para cada tarefa, projeto, empresa, equipe e qualquer outra coisa. Além disso, um projeto pode se beneficiar do uso de mais de um CMS, como usar algum CMS para gerenciar e fornecer dados e outro CMS para renderizar a visualização. Decidir qual das dezenas de CMSs existentes é o mais adequado para suas próprias necessidades depende inteiramente de você.

Além disso, este artigo nunca poderia tirar conclusões definitivas, pois se preocupa apenas com um subconjunto de todas as possibilidades. Por exemplo, também podemos encontrar comparações online como “WordPress vs Drupal vs Joomla”, “WordPress vs Static Site Generators” e até “WordPress vs Medium”. Como nenhum desses artigos vê o quadro completo, nenhuma dessas comparações pode ser conclusiva e não deve ser tratada como tal.

Vamos começar com a comparação.

Filosofia e Grupo Alvo

Não é por acaso que o WordPress alimenta quase 1 em cada 3 sites. Desde a sua criação, ele se esforçou para ser extremamente fácil de usar e o fez com sucesso, removendo o atrito para usuários técnicos e não técnicos, bem como para pessoas de todas as origens - independentemente de sua educação e níveis econômicos. O fundador do WordPress, Matt Mullenweg, expressou que o lema do WordPress de “Democratize Publishing” para a era atual significa o seguinte:

“Pessoas de todas as origens, interesses e habilidades devem ser capazes de acessar o software Free-as-in-speech que os capacita a se expressar na web aberta e possuir seu conteúdo.”

O WordPress é fácil de usar para todos e sua inclusão também é evidenciada no lado do desenvolvimento: Não é incomum encontrar pessoas sem experiência em programação (como profissionais de marketing, designers, blogueiros, vendedores e outros) mexendo em suas instalações WordPress, projetando seus próprios temas e lançando com sucesso seus próprios sites. O WordPress é centrado no usuário e as necessidades dos usuários superam as dos desenvolvedores. No WordPress, o usuário é rei (ou rainha).

Em contraste, o CMS de outubro é mais voltado para o desenvolvedor, conforme estabelecido explicitamente desde seu primeiro lançamento:

“Outubro faz uma suposição ousada, mas óbvia: os clientes não constroem sites, os desenvolvedores sim. O papel de um cliente é gerenciar o site e transmitir seus requisitos de negócios. O desenvolvedor web e a própria indústria giram em torno da mediação desses fatores.”

Nas palavras de seus fundadores, a missão do CMS é “provar que fazer sites não é ciência do foguete”. Sendo baseado em Laravel, o October CMS pode alegar ter bases sólidas de código reutilizável e modular que pode produzir aplicativos adequadamente arquitetados, de manutenção a longo prazo e totalmente personalizáveis ​​sem exigir hacks - o tipo que atrai programadores sérios. O CMS de outubro também pode fornecer uma ótima experiência ao usuário, no entanto, não é tão simples ou sem atritos quanto o fornecido pelo WordPress. Pode ser necessário explicar aos usuários como usar determinada funcionalidade antes de poder usá-la. Por exemplo, incorporar um formulário de algum plugin tem uma longa explicação sobre como fazê-lo, o que é mais complicado do que a funcionalidade de arrastar e soltar auto-evidente fornecida por vários plugins de formulário no WordPress.

Instalação

O WordPress é famoso por sua instalação de 5 minutos, embora muitas pessoas apontem que (levando em consideração todos os plugins que devem ser instalados) uma instalação típica requer 15 minutos ou mais. Além disso, o WordPress também oferece o recurso Multisite, que nos permite criar uma rede de vários sites virtuais em uma única instalação. Esse recurso facilita para uma agência administrar os sites de vários clientes — entre outros casos de usuário.

A instalação do October CMS também é muito fácil: a instalação do Wizard em si leva menos de cinco minutos e, se você instalá-lo através da instalação do Console, é ainda mais rápido. Você pode fazer o último simplesmente navegando até o diretório de destino e executando curl -s https://octobercms.com/api/installer | php curl -s https://octobercms.com/api/installer | php (após o qual precisamos inserir a configuração do banco de dados, caso contrário, ele se comporta como um CMS de arquivo simples). Assim que a instalação estiver concluída, teremos um site totalmente funcional, mas ainda bastante vazio (se você adicionar o tempo necessário para instalar e configurar os plugins necessários, pode esperar que demore pelo menos 15 minutos).

Segurança

O WordPress tem sido acusado de ser inseguro devido à grande quantidade de vulnerabilidades que são constantemente encontradas. Isso força os usuários a ter o software para o CMS e todos os plugins instalados sempre atualizados para evitar explorações de segurança. Entre os principais problemas está o suporte do WordPress para versões mais antigas do PHP que não são mais suportadas pela comunidade de desenvolvimento PHP (o WordPress atualmente suporta PHP 5.2.4, enquanto a última versão totalmente suportada do PHP é 5.6). No entanto, esse problema deve ser resolvido em abril de 2019, quando o WordPress começará oficialmente a oferecer suporte às versões PHP 5.6 e posteriores.

Caso contrário, o WordPress não é necessariamente inseguro por si só, mas por causa de sua alta popularidade, o que o torna um alvo primordial para hackers. No entanto, isso funciona nos dois sentidos: a onipresença do WordPress significa que sua equipe de segurança deve realmente levar seu trabalho a sério, procurando constantemente por exploits e corrigindo-os o mais rápido possível, caso contrário, até um terço da web estará em risco. As apostas são muito altas.

O CMS de outubro, por outro lado, não tem fama de ser inseguro. No entanto, como existem cerca de 27.000 sites ativos que usam outubro em comparação com os milhões do WordPress, não podemos julgar os dois nos mesmos termos. No entanto, a equipe por trás do CMS de outubro leva a segurança a sério, como evidenciado pelo prompt da instalação do Assistente para inserir o URL de back-end do CMS, definido como /backend por padrão, mas alterável para qualquer outra coisa, para tornar mais difícil para os hackers direcionarem o site . Em contraste, alterar os URLs de login e backend do WordPress de /wp-login.php e /wp-admin respectivamente para outra coisa deve ser feito através de um plugin. Além disso, o October CMS pode funcionar como um CMS de arquivo simples (ou seja, sem um banco de dados) e evitar vulnerabilidades relacionadas ao banco de dados, como injeção de SQL.

Pilha de Tecnologia

Tanto o WordPress quanto o CMS de outubro são executados na pilha LAMP tradicional: Linux, Apache, MySQL e PHP. (No entanto, apenas o PHP é fixo: também podemos usar Windows, Nginx, MariaDB e outros.) O CMS de outubro também pode se comportar como um CMS de arquivo simples, o que significa que pode ficar sem um banco de dados, no entanto, ao custo de renunciar muitas funcionalidades (como postagens de blog e usuários) a única funcionalidade garantida são as páginas, que é considerada a unidade básica para a criação e publicação de conteúdo e enviada como um recurso central.

Com relação à pilha de idiomas, os sites criados com WordPress e CMS de outubro são baseados em HTML, CSS e JavaScript (observe que o PHP é usado para gerar o HTML). O CMS de outubro também facilita o uso de arquivos LESS e SASS.

Paradigma de programação

O WordPress segue um paradigma de programação funcional, baseado no cálculo de cálculos chamando funções desprovidas de estado do aplicativo. Embora os desenvolvedores do WordPress não precisem se ater à programação funcional (por exemplo, para codificar seus temas e plugins), o código principal do WordPress herda esse paradigma de 15 anos preservando a compatibilidade com versões anteriores, que tem sido um dos pilares do sucesso do WordPress mas que tem a consequência não intencional de acumular dívida técnica.

Por outro lado, o October CMS segue um paradigma de programação imperativa, baseado no cálculo de cálculos manipulando o estado dos objetos. O CMS de outubro fica no topo do Laravel, um framework web totalmente baseado em princípios de programação orientada a objetos que permitem a produção de aplicativos modulares baseados em conceitos como o Model-View-Controller para desacoplar a interface do usuário dos dados do aplicativo, injeção de dependência para configurar dependências de classe e o Princípio de Segregação de Interface para definir os principais serviços fornecidos pelo framework, entre muitos outros.

Ganchos/Eventos

A programação no WordPress pode ser caracterizada como HDD, que significa “Hook-Driven Development”. Um gancho é um mecanismo que permite alterar um comportamento ou valor padrão e permitir que outro código execute a funcionalidade relacionada. Hooks são acionados através de “ações” que permitem executar funcionalidades extras, e “filtros” que permitem modificar valores.

Hooks, que são difundidos em toda a base de código do WordPress, são um dos conceitos que mais gosto na codificação no WordPress. Eles permitem que plugins interajam com outros plugins (ou com um núcleo ou tema) de forma limpa, fornecendo algum suporte básico de Programação Orientada a Aspectos.

A boa notícia é que o Laravel (e consequentemente o CMS de outubro) também suporta o conceito de ganchos, que é chamado de “eventos”. Os eventos fornecem uma implementação simples de observador, permitindo que o código assine e escute eventos que ocorrem no aplicativo e reaja conforme necessário. Os eventos permitem dividir uma funcionalidade complexa em componentes, que podem ser instalados de forma independente, mas colaboram entre si, permitindo a criação de aplicativos modulares.

Dependência de bibliotecas JavaScript

A versão mais recente do WordPress incorpora o Gutenberg com tecnologia React para sua experiência de criação de conteúdo padrão. Portanto, o desenvolvimento do WordPress agora depende em grande parte do JavaScript (predominantemente através do React), embora também seja possível usar outros frameworks ou bibliotecas (como evidenciado pelo Elementor Blocks for Gutenberg, que é baseado no Marionette). Além disso, o WordPress ainda depende do Backbone.js (para o Media Manager) e do jQuery (código legado), no entanto, podemos esperar que a dependência dessas bibliotecas diminua à medida que o Gutenberg for consolidado como a nova norma.

O CMS de outubro depende do jQuery, que ele usa para implementar sua estrutura AJAX opcional para carregar dados do servidor sem uma atualização da página do navegador.

Páginas, temas e plugins

Tanto o WordPress quanto o CMS de outubro tratam uma página como a unidade básica para criação e publicação de conteúdo (no caso do WordPress, além do post), suportam a alteração da aparência do site por meio de temas e permitem instalar e estender as funcionalidades do site por meio de plugins . Embora os conceitos sejam os mesmos em ambos os CMSs, existem algumas diferenças na implementação que produzem um comportamento um pouco diferente.

No WordPress, as páginas são definidas como conteúdo e armazenadas no banco de dados. Como resultado, o conteúdo da página pode ser criado apenas através do CMS (por exemplo, na área do painel), e alternar de um tema para outro não torna uma página existente indisponível. Isso produz uma experiência geral sem atrito.

No CMS de outubro, por outro lado, as páginas são arquivos estáticos armazenados no diretório do tema. No lado positivo dessa decisão arquitetônica, o conteúdo da página pode ser criado a partir de um aplicativo externo, como editores de texto como Sublime ou Visual Studio Code. Do lado negativo, ao mudar de um tema para outro, é necessário recriar ou copiar manualmente as páginas do tema atual para o novo, caso contrário, elas desaparecerão.

Significativamente, o October CMS resolve o roteamento pelas páginas, portanto, as páginas são usadas não apenas como contêineres para conteúdo, mas também para funcionalidade. Por exemplo, um plug-in para blogs depende de uma página para exibir a lista de postagens de blog em um URL escolhido, outra página para exibir um único post de blog em outro URL escolhido e assim por diante. Se qualquer uma dessas páginas desaparecer, a funcionalidade associada do plug-in ficará indisponível e esse URL produzirá um 404. Portanto, em outubro, os temas e plug-ins do CMS não são totalmente desacoplados, e a troca de temas deve ser feita com cuidado.

Funcionalidade Core vs Plugin

O WordPress tenta fornecer uma funcionalidade básica mínima que é aprimorada por meio de plugins. O WordPress conta com a “ _regra ^80/20 ” para decidir se inclui alguma funcionalidade em sua experiência principal ou não. Se beneficia 80% dos usuários, entra, caso contrário, pertence ao plugin-land. Ao adicionar plug-ins a um site, eles podem causar inchaço se muitos plug-ins forem instalados. Os plug-ins também podem não funcionar bem uns com os outros, ou executar código semelhante ou carregar ativos semelhantes, resultando em desempenho abaixo do ideal. Portanto, embora o lançamento de um site WordPress seja relativamente fácil, um desafio maior é a manutenção geral e a capacidade de preservar um estado ideal e de desempenho ao adicionar novos recursos.

Da mesma forma, o October CMS também tenta entregar uma funcionalidade básica mínima, mas com esteróides: a única funcionalidade garantida é a criação e publicação de páginas, e para todo o resto precisaremos instalar um plugin ou outro, que é expresso como:

“Tudo o que você precisa, e nada que você não precisa.”

O objetivo é claro: a maioria dos sites simples são compostos apenas de páginas, possivelmente sem postagens de blog, usuários ou área de login. Então, por que o aplicativo deve carregar recursos para eles quando não são necessários? Como consequência, funcionalidades para blogs, gerenciamento de usuários, tradução e várias outras são liberadas através do diretório de plugins.

O October CMS também inclui alguns recursos em seu núcleo que (mesmo que nem sempre sejam necessários) podem melhorar significativamente o aplicativo. Por exemplo, ele oferece suporte imediato para fazer upload de arquivos de mídia para o Amazon S3 e acessá-los por meio do Rackspace CDN. Ele também inclui um Gerenciador de Mídia que é usado principalmente através de plugins, por exemplo, para adicionar imagens em um post de blog. (As páginas também podem usar o Gerenciador de mídia para incorporar arquivos de mídia, no entanto, o CMS também vem com uma seção de ativos para fazer upload de arquivos de mídia para aqueles que parecem mais adequados.)

Acredito que a opinião de outubro pode perfeitamente nos permitir produzir um aplicativo o mais enxuto possível – principalmente para sites simples. No entanto, também pode sair pela culatra e incentivar o inchaço, porque a linha do que é necessário e do que não é é arbitrária, e é difícil de ser definida antecipadamente pelo CMS. Essa dificuldade pode ser apreciada quando se considera o conceito de “usuário”: no WordPress, os usuários do site e os administradores do site pertencem à mesma entidade de usuário (e por meio de funções e privilégios podemos fazer um usuário se tornar um administrador). No CMS de outubro, esses dois são implementados separadamente, enviando no core a implementação para o administrador do site que pode fazer login na área de backend e modificar as configurações, e através de um plugin a implementação do usuário do site. Esses dois tipos de usuários têm um processo de login diferente e uma tabela de banco de dados diferente para armazenar seus dados, violando assim o princípio DRY (Don't Repeat Yourself).

Este problema surge não apenas em relação ao comportamento de uma entidade, mas também em quais campos de dados ela deve conter. Por exemplo, os campos de dados do usuário do site devem ser predefinidos? O campo de telefone é obrigatório? Que tal um campo de URL do Instagram, considerando que o Instagram ficou legal apenas recentemente? Mas então, ao construir um site profissional, não devemos usar um campo de URL do LinkedIn? Essas decisões dependem claramente do aplicativo e não podem ser decididas pelo CMS ou pelo plugin.

O plugin CMS de outubro chamado User implementa usuários, mas sem nenhum campo de usuário, em cima do qual o plugin User Plus adiciona vários campos de usuário arbitrários, que possivelmente não são suficientes, então o plugin User Plus+ adiciona ainda outros campos de usuário. Quando, onde e como paramos esse processo?

Outro problema é quando não há espaço para adicionar novos recursos a uma entidade, o que leva à criação de outra entidade extremamente semelhante, apenas para suportar esses recursos necessários. Por exemplo, o October CMS vem com páginas e permite criar “páginas estáticas” através de um plugin. Sua natureza é a mesma: tanto as páginas quanto as páginas estáticas são salvas como arquivos estáticos. A única diferença entre eles (até onde eu sei) é que as páginas estáticas são editadas com um editor visual em vez do editor HTML e podem ser adicionadas aos menus. Na minha opinião, apenas diferenças estruturais, como ter uma entidade salva como arquivo estático e outra armazenada no banco de dados, poderiam justificar a criação de uma segunda entidade para uma página (há um pull request para fazer isso), mas por simples recursos, como é o caso atualmente, constitui um inchaço de desenvolvimento.

Em resumo, um aplicativo CMS de outubro bem implementado pode ser muito enxuto e eficiente (por exemplo, removendo o banco de dados quando não for necessário), mas, pelo contrário, também pode se tornar desnecessariamente inchado, forçando os desenvolvedores a implementar várias soluções para entidades semelhantes e que podem ser muito confuso de usar (“Devo usar uma página ou uma página estática?”). Como nem o WordPress nem o CMS de outubro encontraram uma solução perfeita para remover o inchaço, devemos projetar a arquitetura do aplicativo com cuidado para evitar problemas no futuro.

Criação de conteúdo

Gutenberg faz duas contribuições importantes para o WordPress: ele usa componentes como unidade para a construção de sites (o que oferece várias vantagens sobre blobs de codificação de HTML) e introduz uma entidade chamada “bloco” que, uma vez que a Fase 2 do Gutenberg esteja concluída (presumivelmente em 2019), fornecerá uma maneira unificada de incorporar conteúdo ao site, permitindo assim uma experiência de usuário mais simples em oposição ao processo mais caótico de adicionar conteúdo por meio de códigos de acesso, botões TinyMCE, menus, widgets e outros.

Como os blocos do Gutenberg podem produzir e salvar HTML estático como parte da postagem do blog, a instalação de muitos blocos do Gutenberg não se traduz necessariamente em inchaço no site do lado do usuário, mas pode ser mantido restrito ao lado do administrador. Portanto, Gutenberg pode ser considerado uma boa abordagem para produzir sites de maneira modular, com uma experiência de usuário simples, mas poderosa para criar conteúdo. Possivelmente, a maior desvantagem é o (inevitável, mas não tão fácil) requisito de aprender React, cuja curva de aprendizado é bastante íngreme.

Se os componentes React são a unidade básica para criar conteúdo no WordPress, o October CMS é baseado na premissa de que conhecer o bom e velho HTML é suficiente para construir sites. De fato, ao criar uma página, somos simplesmente apresentados a um editor HTML (Markup):

Se a página fosse apenas HTML estático, não haveria necessidade de um CMS. Em vez disso, as páginas CMS de outubro são escritas usando modelos Twig que são compilados para código PHP simples e otimizado. Eles podem selecionar um layout para incluir o scaffolding da página (ou seja, elementos repetitivos, como cabeçalho, rodapé e assim por diante), podem implementar espaços reservados, que são definidos no layout para permitir que a página personalize o conteúdo e podem incluir parciais, que são pedaços de código reutilizáveis. Além disso, as páginas podem incluir blocos de conteúdo, que são arquivos de texto, HTML ou Markdown que podem ser editados por conta própria e podem anexar componentes que são funcionalidades implementadas por meio de plugins. E, finalmente, sempre que HTML não for suficiente e precisarmos produzir código dinâmico, podemos adicionar funções PHP.

O editor é tudo sobre HTML. Não há área de texto do textarea para adicionar conteúdo de maneira visual - pelo menos não através da experiência padrão (essa funcionalidade pertence ao plugin-land). Portanto, ter conhecimento de HTML pode ser considerado uma obrigação para usar o CMS de outubro. Além disso, as várias entradas diferentes para a criação de conteúdo (páginas, layouts, placeholders, parciais, blocos de conteúdo, componentes e funções PHP) podem ser muito eficazes, porém, certamente não é tão simples quanto através da interface de bloco unificada do WordPress. Pode até ficar mais complexo, pois outros elementos também podem ser adicionados (como páginas e menus estáticos e snippets), e alguns deles, como páginas e páginas estáticas, aparentemente fornecem a mesma funcionalidade, tornando confuso decidir quando Use um ou outro.

Como resultado, atrevo-me a dizer que, embora praticamente qualquer pessoa possa usar um site WordPress do lado do administrador, o October CMS é mais amigável ao desenvolvedor do que não técnico, então os programadores podem achar divertido usar, mas alguns outros funções (profissionais de marketing, vendedores e afins) podem achar isso não intuitivo.

Gerente de mídia

Tanto o WordPress quanto o October CMS são fornecidos com um Media Manager que permite adicionar arquivos de mídia ao site sem esforço, suportando a adição de vários arquivos simultaneamente por meio de uma interface de arrastar e soltar e exibir as imagens na área de conteúdo. Eles se parecem e se comportam de maneira semelhante; as únicas diferenças notáveis ​​que encontrei são que o WordPress' Media Manager permite incorporar galerias de imagens, e o October's Media Manager permite criar manualmente uma estrutura de pastas onde colocar os arquivos enviados.

Desde a introdução do Gutenberg, no entanto, os recursos de mídia do WordPress foram bastante aprimorados, permitindo incorporar vídeos, fotos e galerias de fotos no local, em comparação com uma área de texto do textarea (que fornece apenas uma versão não precisa de como ficará no site) e desbloqueando recursos poderosos e fáceis de usar, conforme mostrado neste vídeo.

Internacionalização

O núcleo do WordPress usa gettext para permitir a tradução de temas e plugins. A partir de um arquivo .pot contendo todas as strings a serem traduzidas, precisamos criar um arquivo .po contendo sua tradução para o idioma/localidade correspondente, e este arquivo é então compilado para um arquivo binário .mo adequado para extração de tradução rápida. As ferramentas para executar essas tarefas incluem GlotPress (online) e Poedit (aplicativo para download). Convenientemente, esse mecanismo também funciona para localização do lado do cliente para Gutenberg.

Atualmente, o WordPress não envia nenhuma solução no núcleo para traduzir conteúdo e não o fará até a Fase 4 de Gutenberg (destinada para o ano de 2020+). Até então, essa funcionalidade é fornecida por plugins que oferecem diferentes estratégias para armazenar e gerenciar o conteúdo traduzido. Por exemplo, enquanto plugins como Polylang e WPML armazenam cada tradução em sua própria linha de uma tabela de banco de dados personalizada (que é limpa, pois não mistura conteúdo, mas mais lenta, pois requer um INNER JOIN adicional de duas tabelas ao consultar o banco de dados), o plugin qTranslate X armazena todas as traduções no mesmo campo da tabela do banco de dados original (mais rápido para consultar os dados, mas o conteúdo misturado pode causar estragos no site se desabilitar o plugin). Assim, podemos pesquisar e decidir a estratégia mais adequada às nossas necessidades.

O October CMS não fornece a funcionalidade multilíngue por meio de seu núcleo, mas como um plug-in criado pela equipe do October CMS que garante uma integração perfeita no sistema. Do ponto de vista funcional, este plugin cumpre o que promete. Do ponto de vista do desenvolvimento, não é exatamente ideal como esse plugin realmente funciona. No WordPress, uma página é simplesmente uma postagem com o tipo de postagem “página” e existe um único mecanismo de tradução para elas, mas no CMS de outubro, existem as entidades “página”, “página estática” e “postagem do blog” e, embora bastante semelhantes, eles exigem três implementações diferentes para suas traduções! Então, o conteúdo de uma “página” pode incluir códigos de mensagem (por exemplo, códigos chamados nav.content , header.title , e assim por diante), cada um dos quais contém suas traduções para todas as localidades como um objeto JSON serializado na tabela de banco de dados rainlab_translate_messages . O conteúdo de uma “página estática” é criado em um novo arquivo estático por localidade, no entanto, todas as URLs traduzidas para todas as localidades são armazenadas não no arquivo correspondente, mas no arquivo do idioma padrão. O conteúdo da “postagem do blog” é armazenado como um objeto JSON serializado com uma linha por localidade na tabela de banco de dados rainlab_translate_attributes e a URL traduzida é armazenada com uma linha por localidade na tabela de banco de dados rainlab_translate_indexes . Não sei se essa complexidade se deve à forma como o plugin foi implementado ou se é devido à arquitetura do CMS de outubro. Seja qual for o caso, este é outro exemplo de inchaço indesejado no lado do desenvolvimento.

Gerenciamento de plug-ins

Tanto o WordPress quanto o October CMS oferecem um gerenciador de plug-ins sofisticado que permite pesquisar plug-ins, instalar novos plug-ins e atualizar os plug-ins atualmente instalados para a versão mais recente - tudo a partir do back-end.

Gerenciamento de Dependências

O October CMS usa o Composer como gerenciador de pacotes de escolha, permitindo que os plugins baixem e instalem suas dependências ao serem instalados, proporcionando assim uma experiência indolor.

O WordPress, por outro lado, não adotou oficialmente o Composer (ou qualquer gerenciador de dependências do PHP) porque a comunidade não pode concordar se o WordPress é um site ou uma dependência de site. Portanto, se eles precisarem do Composer para seus projetos, os desenvolvedores devem adicioná-lo por conta própria. Com a mudança para Gutenberg, o npm se tornou o gerenciador de dependências JavaScript preferido, com um kit de ferramentas de desenvolvedor popular dependendo dele, e as bibliotecas do lado do cliente sendo lançadas constantemente como pacotes autônomos no registro npm.

Interação com o banco de dados

O WordPress fornece funções para recuperar dados do banco de dados (como get_posts ) e armazená-los (como wp_insert_post e wp_update_post ). Ao recuperar dados, podemos passar parâmetros para filtrar, limitar e ordenar os resultados, para indicar se o resultado deve ser passado como uma instância de uma classe ou como um array de propriedades e outros. Quando a função não satisfaz totalmente nossos requisitos (por exemplo, quando precisamos fazer um INNER JOIN com uma tabela personalizada), podemos consultar o banco de dados diretamente através da variável global $wpdb . Ao criar um plug-in com um tipo de postagem personalizado, o código provavelmente executará consultas SQL personalizadas para recuperar e/ou salvar dados em tabelas personalizadas. Em resumo, o WordPress tenta fornecer acesso ao banco de dados por meio de funções genéricas no primeiro estágio e por meio de acesso de baixo nível ao banco de dados no segundo estágio.

Outubro CMS emprega uma abordagem diferente: em vez de se conectar ao banco de dados imediatamente, a aplicação pode usar o Eloquent ORM do Laravel para acessar e manipular dados do banco de dados através de instâncias de classes chamadas Modelos, fazendo com que a interação com o banco de dados também seja baseada em Programação Orientada a Objetos . É acesso de alto nível; apenas seguindo as regras de como criar tabelas e configurar relacionamentos entre entidades, um plugin pode recuperar e/ou salvar dados sem escrever uma linha de SQL. Por exemplo, o código abaixo recupera um objeto do banco de dados por meio do model Flight , modifica uma propriedade e a armazena novamente:

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

Atualizando o modelo de dados

Outra razão para o sucesso do WordPress (além de não quebrar a compatibilidade com versões anteriores) tem sido sua arquitetura de banco de dados, que foi projetada para permitir que os aplicativos cresçam ao longo do tempo. Este objetivo é alcançado através de propriedades “meta”, ou seja, propriedades que podem ser adicionadas livremente a um objeto de banco de dados a qualquer momento. Essas propriedades não são armazenadas em uma coluna da tabela de entidades correspondente ( wp_posts , wp_users , wp_comments ou wp_terms ), mas sim como uma linha na tabela “meta” correspondente ( wp_postmeta , wp_usermeta , wp_commentmeta ou wp_termmeta ) e recuperadas fazendo um INNER JOIN . Portanto, embora a recuperação desses valores meta seja mais lenta, eles fornecem flexibilidade ilimitada e o modelo de dados do aplicativo raramente precisa ser rearquitetado do zero para implementar alguma nova funcionalidade.

O CMS de outubro não usa propriedades meta, mas pode armazenar vários valores arbitrários, que não são mapeados diretamente como colunas nas tabelas do banco de dados, como um objeto JSON serializado. Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

Hospedagem gerenciada

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

Comunidade

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

Alimentando um terço de todos os sites do mundo, o WordPress não tem falta de partes interessadas que contribuem para o software; portanto, não precisamos temer que o software entre em decadência. No entanto, o WordPress está passando por deliberações internas sobre seu modelo de governança, com muitos membros da comunidade expressando que as decisões sobre a direção do WordPress estão sendo tomadas unilateralmente pela Automattic, a empresa que administra o WordPress.com. O palco central dessa percepção foi a decisão de lançar Gutenberg, da qual muitos membros discordaram e que sofreu uma falta de comunicação adequada por parte dos líderes do projeto durante seu desenvolvimento e lançamento. Como consequência, muitos membros da comunidade estão questionando o papel de “ditador benigno”, que historicamente foi concedido ao fundador do WordPress e CEO da Automattic, Matt Mullenweg, e pesquisando diferentes modelos de governança para encontrar um mais adequado para o futuro do WordPress. Ainda não se sabe se essa busca produz algum resultado, ou se o status quo persevera.

As decisões sobre a direção do CMS de outubro são tomadas principalmente pelos fundadores Alexey Bobkov e Samuel Georges e pelo desenvolvedor e gerente da comunidade Luke Towers, que mantêm o projeto forte. Outubro CMS ainda não se dá ao luxo de ter um problema de governança: sua preocupação atual é como tornar o projeto sustentável gerando renda para os mantenedores do software principal.

Documentação

A documentação do WordPress em seu próprio site não é extremamente abrangente, mas faz o trabalho razoavelmente bem. No entanto, ao levar em consideração toda a documentação sobre o WordPress de todas as fontes, como sites gerais (Smashing Magazine, CSS tricks e muitos outros), sites especializados (WPShout, WPBeginner e muitos outros), blogs pessoais, cursos online, e assim por diante, não há praticamente nenhum aspecto de lidar com o WordPress que já não tenha sido abordado.

O October CMS não gosta de nada perto dos muitos cursos, tutoriais ou postagens de blog de terceiros sobre isso tanto quanto o WordPress, no entanto, a documentação em seu site é razoavelmente abrangente e certamente suficiente para começar a codificar. Os fundadores de outubro também adicionam regularmente nova documentação por meio de tutoriais. Um aspecto que eu pessoalmente gostei é a duplicação da documentação do Laravel na documentação de outubro para tudo de relevante, então o leitor não deve preencher as lacunas sozinho e ter que adivinhar qual é o domínio de outubro e o que é do Laravel. No entanto, isso não é 100% perfeito. A documentação de outubro usa termos originários do Laravel, como middleware, contêineres de serviço, fachadas e contratos, sem explicar adequadamente o que são. Então, ler a documentação do Laravel com antecedência pode ser útil (felizmente, a documentação do Laravel é decididamente abrangente, e os screencasts do Laravel, Laracasts, são outra grande fonte de aprendizado, não apenas em relação ao Laravel, mas ao desenvolvimento web em geral).

Conclusão

Comecei a descobrir quais recursos podem ser atraentes para desenvolvedores que buscam alternativas ao WordPress comparando o WordPress a um CMS semelhante, que defini como sendo gratuito e de código aberto, baseado em PHP e produzindo conteúdo dinâmico, e contando com o suporte de alguma comunidade . Dos CMSs que atendem a essas condições, escolhi o CMS de outubro para a comparação devido ao conhecimento que obtive sobre ele e porque apreciei sua abordagem de codificação limpa e modular fornecida pelo Laravel, que poderia oferecer uma perspectiva nova e moderna para os canteiros de obras.

Este artigo não teve a intenção de escolher um vencedor, mas simplesmente analisar quando faz sentido escolher um ou outro CMS, destacando seus pontos fortes e fracos. Não existe CMS “melhor”: apenas o CMS mais adequado para uma situação específica. Além disso, quem procura um CMS para usar em um projeto específico com uma equipe específica e com um determinado orçamento, deve pesquisar e comparar todas as ofertas disponíveis para descobrir qual é a mais adequada para o contexto específico. É importante não se limitar a alguns CMSs como fiz aqui neste artigo, mas sim dar uma chance a todos eles.

Em uma nota pessoal, como desenvolvedor, o que encontrei em outubro CMS é realmente atraente para mim, principalmente sua capacidade de construir aplicativos modulares fornecidos pelo Laravel. Eu certamente consideraria este CMS para um novo site. No entanto, no processo de escrever este artigo, também “redescobri” o WordPress. Sendo tão popular, o WordPress recebe mais do que seu quinhão de críticas, principalmente em relação à sua antiga base de código e, desde recentemente, à introdução do Gutenberg; no entanto, o WordPress também possui alguns recursos excelentes (como seu modelo de banco de dados superescalável) que raramente são elogiados, mas também devem ser levados em consideração. E o mais importante, o WordPress não deve ser considerado apenas em seus aspectos técnicos: em particular, o tamanho de sua comunidade e ecossistema o coloca um nível ou dois acima de suas alternativas. Em poucas palavras, alguns projetos podem se beneficiar com o WordPress, enquanto outros podem confiar melhor no CMS de outubro ou em outra plataforma.

Como nota final, gostaria de observar que explorar como outro CMS funciona é uma atividade muito gratificante por si só, independentemente da decisão tomada sobre usar ou não esse CMS específico. No meu caso, eu estava trabalhando há anos apenas no WordPress, e mergulhar no CMS de outubro foi muito refrescante, pois me ensinou muitas coisas (como a existência de Recomendações de Padrões PHP) que eu não tinha sido exposto através do WordPress. Agora posso decidir mudar de CMSs ou ficar com o WordPress sabendo como produzir um código melhor.

Leitura adicional no SmashingMag:

• Cache inteligente na era de Gutenberg
• Melhorando o código do WordPress com PHP moderno
• Lições aprendidas ao desenvolver plugins WordPress
• Como usar mapas de calor para rastrear cliques em seu site WordPress
• Esteja atento: funções PHP e WordPress que podem tornar seu site inseguro