Apresentação técnica do WP21

 (ma.tt)
1 pontos por GN⁺ 2024-05-29 | 1 comentários | Compartilhar no WhatsApp
  • Já se passaram 21 anos desde que o WordPress teve seu primeiro lançamento, após Matt Mullenweg e Mike Little fazerem um fork do b2/cafélog, e no desenvolvimento daqui para a frente é preciso retomar as condições que possibilitaram seu sucesso inicial
  • A direção do produto segue o princípio de tornar as coisas fáceis intuitivas, sem deixar de possibilitar as complexas
  • Recursos dinâmicos da web como blogs, comentários e pingbacks tornam os sites mais interessantes, e sites dinâmicos são considerados mais valiosos que sites estáticos
  • O ecossistema de plugins e temas precisa ter uma infraestrutura de desenvolvimento no nível do core do WordPress, e em 2024 não faz sentido depender de upload de ZIP
  • Loops de feedback próximos dos usuários, fóruns centrados na comunidade, boas prévias de temas e o Playground serão determinantes para a experiência futura do WordPress

21º aniversário do WordPress e princípios do produto

  • Já se passaram 21 anos desde que o WordPress teve seu primeiro lançamento, depois que Matt Mullenweg e Mike Little fizeram um fork do trabalho de Michel no b2/cafélog
  • No desenvolvimento daqui para a frente, é preciso continuar tendo em mente os fatores que contribuíram para o sucesso inicial do WordPress
  • O princípio central do produto é que o simples deve ser fácil e intuitivo, e que o complexo também deve ser possível

Blogs, documentação e recursos de comunidade

  • Blogs, comentários e pingbacks devem ser divertidos
    • Sites estáticos também são bons, mas a posição é que sites dinâmicos são melhores
    • Quase todo site pode melhorar com um ótimo blog
  • A documentação deve ser tão fácil de editar quanto um wiki
    • Wikis são avaliados como ferramentas “incríveis”
  • Na comunidade, os fóruns devem estar no centro

Ecossistema de plugins e temas

  • Todos os plugins e temas devem ter uma infraestrutura de desenvolvimento no mesmo nível da usada para criar o próprio WordPress
    • Controle de versão
    • Bug tracker
    • Fórum
    • Documentação
    • Internacionalização
    • Sala de chat
    • P2
    • Um caminho fácil para contribuição e comunidade
  • Em 2024, tratar plugins e temas por meio de upload de ZIP não é adequado
  • As prévias de temas devem ser excelentes
  • Uma coleção de temas não comerciais com diferentes estéticas e funcionalidades é importante

Loops de feedback e transparência, mais que regras

  • Não se deve pender demais para guidelines e requisitos
  • É melhor projetar boas dinâmicas de marketplace, loops de feedback automatizados e transparência para os usuários
  • Os limites de recursos e design devem ser levados mais adiante
  • É necessária tolerância zero com spam e comportamentos de spam
  • Os loops de feedback devem escalar de acordo com o uso e com a comunidade como um todo, em vez de depender de gatekeepers

A natureza do core e os pontos de contato com usuários

  • O core do WordPress deve ser opinativo e único
    • Easter egg
    • Linguagem com personalidade, mesmo que seja difícil de traduzir
    • Uma personalidade como a do jazz
  • Todas as pessoas que desenvolvem o software e tomam decisões sobre ele devem usar esse software
  • Desenvolvedores e tomadores de decisão devem estar próximos dos usuários finais comuns por meio de atividades possíveis, como suporte, meetups e eventos

Playground e experiência inicial

  • A expectativa é que o Playground mude tudo
  • Em 27 de maio de 2003, no dia do primeiro lançamento do WordPress, Matt Mullenweg deixou a frase “lancei o WordPress, e me senti bem” em um post de blog de 953 palavras escrito na varanda da casa de seus pais
  • Naquela noite, ele configurou o WP para seu amigo Ramie Speight e prestou suporte técnico por telefone a Mike Tremoulet, que havia conhecido em um encontro local de blogueiros
  • Amigos do ensino médio usavam WordPress em seus próprios domínios, e esse loop de feedback teve um papel importante na formação do software

Leituras relacionadas

1 comentários

 
GN⁺ 2024-05-29
Opiniões no Hacker News

  • É uma pena ver o WordPress aparentemente não só deixando de seguir padrões de desenvolvimento, mas tentando quebrá-los ativamente.
    Depois de usar variáveis globais everywhere e incentivar código espaguete com temas clássicos, nos novos temas passaram a colocar JSON dentro de comentários HTML, sem suporte do editor, fácil de gerar erros e simplesmente com um design estranho.
    Fico me perguntando seriamente se engenheiros seniores decidiram colocar templates JSON dentro de comentários HTML; olhando de forma conspiratória, também parece uma tentativa de matar o mercado de freelancers e agências digitais e empurrar todo mundo para o construtor de sites WYSIWYG do WP.com.

    • O WordPress incentiva uma quantidade enorme de más práticas. Só olhando a estrutura do tema padrão, ele descreve metadados do tema em comentários de um arquivo CSS e usa concatenação de strings everywhere em vez de composição, dificultando a reutilização de trechos de HTML.
      É algo como CSS dentro de JS dentro de HTML dentro de PHP, e depende de uma estrutura implícita sobre quais arquivos são lidos, e em que ordem, para montar a página inteira.
      No começo parece conveniente, mas acaba fazendo elementos HTML não serem fechados corretamente no mesmo arquivo e serem concluídos em outro, impedindo a reutilização.
      Parece erro de iniciante, mas milhares de temas dependem disso, então agora ficaram presos; é o oposto de como templates Jinja2 renderizam blocos e macros.
    • Matar freelancers? Nos últimos 15 anos, minha frase favorita para prospects baratos foi dizer para eles criarem um site em WordPress e procurarem um “especialista” em WordPress.
      O WordPress existe para clientes baratos e clientes sem orçamento que têm a ilusão de precisar de um site simples; e acho que a própria ideia desse tipo de site simples já morreu.
    • Se preciso trabalhar com WP, sempre uso o framework Timber em vez das versões de blocos/clássica.
      https://timber.github.io/docs/v2/
    • Não sou nem de longe especialista em WordPress, mas às vezes precisei migrar sites de clientes, e lembro muito bem de encontrar caminhos absolutos do sistema de arquivos hardcoded dentro de PHP serializado no banco de dados.
      Ao tentar mover para um novo servidor com um caminho de instalação minimamente diferente, tudo quebrava imediatamente.
    • Se seguir padrões de desenvolvimento, os usuários não ficam presos à plataforma. Podem migrar para um CMS que funcione melhor e seja mais fácil de administrar, ou ir para uma solução hospedada em vez de serem obrigados a pagar alguém.
      Infelizmente, isso poderia prejudicar a frase de marketing “nossa plataforma roda 43,4% de todos os sites”.

  • É uma pena que julgamentos rápidos e opiniões fortes tenham se tornado parte da comunidade.
    Depois de desenvolver bastante em WordPress nos últimos 2 ou 3 meses, eu diria que o isolamento de código oferecido pelos blocos (Gutenberg) é excelente.
    Usando como plugin independente ou junto com o Advanced Custom Fields, é possível criar sites perfeitamente modulares, com fluxo de desenvolvimento e controle 100% direto até do HTML — ou seja, um design system.
    Recomendo a todos entender e aprender WordPress de verdade. Não tenho nenhuma relação nem associação com o WordPress.

    • Estou trabalhando exatamente dessa forma agora e enfrentando alguns erros 500 interessantes em produção.
      Hoje, de repente, Gutenberg e ACF Blocks estão entrando em conflito em algum ponto por causa do parsing do conteúdo de campos de mídia aninhados.
      A causa pode ser “o usuário inseriu uma descrição de imagem que não deveria inserir” ou “o objeto global de um plugin contaminou outro objeto global passado para acf_register_block_type()”.
      Talvez eu tenha que ligar para um cliente que já está irritado e dizer para evitar julgamentos rápidos e opiniões fortes.
    • Acho que a maior parte dos julgamentos se formou ao longo de 21 anos. O WordPress primeiro ganhou fama como uma forma rápida e fácil de criar sites e depois ganhou reputação de pesadelo de segurança.
      Talvez isso já não seja verdade, mas o ceticismo é natural. Nas atualizações que verifico toda semana, vejo bastante CVE; talvez todos sejam de baixo risco ou relacionados a plugins quase não usados.
    • Quando eu era criança, uma das minhas primeiras experiências de programação foi abrir ingenuamente o index.php do WordPress para tentar entender como funcionava.
      Lembro que não consegui entender nada além do comentário “code is poetry” no topo do arquivo.
      Isso acabou mudando minha forma de pensar sobre código e me fez mergulhar ainda mais em programação.
    • Basta ir um pouco mais fundo para ficar claro o quanto o WordPress é uma bagunça.
      Se um post precisa de metadados, você instala o ACF; se tenta filtrar por esses metadados, as consultas SQL estouram o tempo limite assim que alguns poucos filtros são aplicados ao mesmo tempo. Ao olhar o esquema estranho do WP, dá para entender o motivo.
      O Gutenberg promete componentes React editáveis em WYSIWYG, mas toma decisões estranhas: armazena atributos dentro do HTML, coloca HTML renderizado no banco de dados e faz o desenvolvedor do componente manter um array de mudanças deprecated toda vez que altera alguma coisa.
      Há tentativas de refatorar o WordPress e acoplar Laravel para resolver isso[1], mas cada camada é um pesadelo, e até os autores de partes diferentes parecem ter dificuldade para determinar por que as coisas quebram aleatoriamente.
      O ecossistema de plugins pode ser atraente, mas as implementações variam tanto que é bem provável acabar empurrando para o usuário blocos inchados de CSS e JS.
      Eu migrei para Directus e Astro; para uma implantação PHP mais comum, acho que usaria um CMS baseado em Laravel, como October ou Statamic.
      [1]: https://roots.io/
    • Gostaria de saber se alguém pode recomendar uma forma melhor de entender e aprender WordPress de verdade.
      Em 2009–2011 trabalhei bastante com ele, inclusive escrevendo e modificando plugins, mas nunca senti que o entendia de verdade; eu só entendia ou aceitava as coisas em linhas gerais.

  • Gosto do WordPress. As pessoas instalam por conta própria, colocam dezenas de plugins inúteis, inseguros e cheios de bugs e, quando o site quebra com o tempo, dá para cobrar por uma solução mais segura e robusta

    • Em 2011, tive a oportunidade de dar uma olhada no plugin sociable, que era o 2º no ranking de plugins, e ele estava entre os códigos mais vulneráveis e inchados que já vi
      Parecia um projeto de fim de semana inacabado que se arrastou por tempo demais e acabou sendo publicado; havia um loop for de cinco telas girando em torno de uma enorme variável global, duplicado para processar alguma coisa
    • Ele certamente conseguiu fazer as pessoas quererem instalar plugins. Especialmente só por colocar aquela UI em primeiro plano; e, como as imagens não são comprimidas por padrão, virou um aliado perfeito de vários analisadores de SEO que exigem compressão de imagens

  • WordPress é meu exemplo favorito de “não precisa ser perfeito, só precisa funcionar”
    Muitos projetos legais morrem porque tornam o primeiro passo complicado demais. Depois que as pessoas começam a usar, sempre dá para melhorar mais tarde, mas primeiro é preciso lançar

    • Acho que, na verdade, ele prova o contrário. O WordPress basicamente transformou toda a base de código em uma API pública e, por isso, por causa dos plugins que dependem do estado existente, ficou preso para sempre a código legado, tornando difícil fazer melhorias significativas
      É tão grave que até os desenvolvedores da linguagem PHP não conseguem implementar alguns recursos ou correções. Isso porque a equipe do WordPress não quer migrar o código, e o WordPress representa uma grande fatia do uso de PHP
    • O próprio fato de as pessoas terem começado a usar WP há cerca de 25 anos não seria um contraexemplo a “sempre dá para melhorar mais tarde”?

  • WP é a ferramenta perfeita para 95% do trabalho, mas ajustar os 5% finais é incrivelmente frustrante
    Usei bastante e vejo o fato de ele ter sobrevivido por tanto tempo como prova de sua utilidade. Espero que continue por mais 21 anos

  • Sinceramente, nunca achei o WordPress fácil de usar. Tudo parece bonito só até você conseguir encontrar um bom tema e bons plugins; no momento em que precisa de uma alteração personalizada minúscula, as coisas começam a se enrolar

    • Eu me considerava um desenvolvedor web acima da média e, quando amigos pediam para eu corrigir algumas coisinhas em sites WordPress, eu dizia sem hesitar que conseguiria mudar facilmente
      Mas, quando abria o site, o código dos plugins/temas e os arquivos CSS, acabava lutando por horas para obter o efeito desejado e, mesmo quando conseguia, muitas vezes quebrava outra parte do site
      Deixando de lado a anedota depreciativa, o Matt mandou bem e a história final também foi boa
    • A configuração inicial do WordPress é muito fácil, mas com o tempo a manutenção fica bem difícil
      Atualizações exigem intervenção manual, temas precisam ser consertados e plugins são abandonados. Por não querer aceitar esse fardo, por volta de 2017 migrei todos os sites para Hugo/Jekyll/MkDocs etc.
    • Migrei para o Ghost; no começo era um pouco áspero, mas depois que surgiu a CLI global ficou bem melhor
      Para um blog, eu preferiria usar Ghost a WP, e também prefiro JS a PHP

  • É interessante que, quando várias pessoas dizem “sou desenvolvedor WordPress”, na prática isso significa experiências e conjuntos de habilidades completamente diferentes
    Para algumas pessoas, significa instalar temas e plugins no painel de administração do WordPress e escrever conteúdo de páginas
    Para outras, significa código PHP à moda antiga, escrevendo HTML com templates PHP e customizando o comportamento do WordPress, ou seja, temas clássicos
    Para outras ainda, significa escrever JS+React com Docker e CI/CD para os novos temas de blocos

    • Se você tiver uma clientela suficientemente diversa, para algumas pessoas isso pode significar tudo isso ao mesmo tempo

  • Gostaria que mais empresas adotassem a política de licença sabática da Automattic
    https://automattic.com/benefits/sabbatical/

    • É preciso levar em conta que, nos EUA, as férias anuais são de 2 semanas, então mesmo com uma licença sabática de 3 meses ainda é menos do que na Europa

  • O que faz você se sentir velho é ver “WP” e pensar em WordPerfect(https://en.wikipedia.org/wiki/WordPerfect), não em WordPress
    O WordPress agora já tem idade para ser considerado adulto até nos países mais conservadores, e o WordPerfect agora está entrando na idade da crise da meia-idade

    • Ainda sinto falta do WordPerfect. Eu gostava mais dele do que do MS Word, mas já faz 25 anos desde a última vez que usei

  • O impressionante no WordPress é que nerds da web esperam que ele obviamente seja fácil e ficam irritados quando não é
    Como qualquer outra coisa, WordPress também precisa ser aprendido e tem sua própria perspectiva
    Ele também tem uma história esquisita e, em especial, eu realmente não gosto da forma como trata itens de mídia, mas ainda assim existe uma metodologia
    Se eu dissesse que sei Go, JS, Perl, Java, Ruby e C e ficasse irritado porque Rust é difícil de aprender, obviamente alguém me contestaria
    WordPress parece fazer coisas simples, mas na prática é uma plataforma bastante ampla. Talvez seja preciso ler um pouco a documentação
    Se você herdou um site que usa Elementor, pergunte a quem o criou como fazer mudanças simples, e essa pessoa provavelmente poderá ajudar
    Se você herdou um site que usa Visual Composer ou Divi, dá vontade de atirar em quem o criou
    Se você acha que Gutenberg é ruim, hoje em dia não é nada disso. Lembrar da época do Divi mostra como aquilo era realmente terrível

    • Herdei um site que usa Divi para toda a estilização, e ele está entre os piores softwares comerciais que já vi
      Se houver qualquer timeout naquela execução horrível de UI em JavaScript sobre o WordPress, só o ato de salvar um post do blog pode deixar o site inteiro em um estado irrecuperável
      As localizações em italiano e francês são horríveis, no nível de jogos japoneses dos anos 90, e as opções responsivas praticamente não funcionam, a menos que você chame de responsivo ocultar e exibir conteúdo em certos breakpoints
      Como o “tema” do front-end é mais parecido com um dump ilegível de JavaScript da era do jQuery, tudo é extremamente frágil
      Tenho 100% de certeza de que ninguém usaria isso se a Elegant Themes não gastasse uma fortuna com publicidade
    • Fico curioso para saber qual é essa história esquisita