Durante o dia do colaborador do WordCamp US neste fim de semana, Matt Mullenweg publicou uma nova chamada para que as equipes do WordPress ‘Make adotem uma abordagem de plug-in primeiro ao desenvolver novos recursos para o núcleo. Ele reviveu a noção de plug-ins canônicos, introduzidos pela primeira vez na comunidade WordPress em 2009 como um meio de fornecer recursos opcionais aos usuários com um nível mais alto de confiança do que os plug-ins comuns:
Os plug-ins canônicos seriam plug-ins desenvolvidos pela comunidade (vários desenvolvedores, não apenas uma pessoa) e atendem às solicitações de funcionalidade mais populares com execução superlativa. Esses plugins seriam GPL e estariam no repositório WordPress.org, e seriam desenvolvidos em estreita conexão com o núcleo do WordPress. Haveria uma relação muito forte entre o núcleo e esses plug-ins que garantiria que a) o código do plug-in fosse seguro e o melhor exemplo possível de padrões de codificação, e b) que novas versões do WordPress fossem testadas contra esses plug-ins antes do lançamento para garantir a compatibilidade. Haveria uma tela dentro da seção Plugins do administrador do WordPress para apresentar esses plugins canônicos como uma espécie de escolha do editor ou garantia verificada. Esses plugins seriam uma verdadeira extensão do núcleo do WordPress em termos de compatibilidade, segurança e suporte.
Jen Mylo – Plugins canônicos (dizer o quê?)
O diretório de plugins do WordPress está a apenas um plugin de ultrapassar 60.000 (no momento da publicação). Em contraste com a ideia de plugins canônicos, o diretório oficial ainda é como o velho oeste em termos do que os usuários podem esperar dos autores de plugins. Mullenweg citou vários cenários de plugins que não são ideais para os usuários – como um plugin sendo controlado por uma única empresa e evoluindo para uma versão pro ou removendo funcionalidades anteriormente gratuitas e colocando-as atrás de uma atualização.
Os plugins canônicos destinam-se a fornecer uma alternativa confiável para plugins onde as motivações dos autores podem não colocar os usuários em primeiro lugar. Ele também fornece um caminho para os principais colaboradores demonstrarem a demanda por recursos que desejam colocar no WordPress. Alguns projetos como MP6, Gutenberg e a API REST seguiram esse caminho para o núcleo.
“Estamos chegando a um ponto em que o núcleo precisa ser mais editorial e dizer ‘não’ aos recursos que chegam tão ad hoc quanto às vezes, e minha esperança é que mais equipes de Make usem isso como uma oportunidade para influenciar o futuro do WordPress por meio de uma abordagem de plug-in em primeiro lugar que dá a eles o luxo de ciclos de desenvolvimento e lançamento mais rápidos (em vez de três vezes por ano), menos sobrecarga de revisão e um caminho para entrar no núcleo se o plug-in se tornar um grande sucesso”, disse Mullenweg.
“Estou muito consciente de que quando as pessoas pretendem ter algo no núcleo, um ‘não’ ou ‘não agora’ pode ser frustrante e às vezes criar pressão artificial para colocar algo antes que esteja pronto, como acredito que aconteceu com a API REST em WP 4.4.”
Em um post relacionado que inspirou a discussão renovada sobre plugins canônicos, Mullenweg avaliou a controversa proposta WebP por padrão que recentemente recebeu novas objeções dos desenvolvedores líderes do WordPress. Os colaboradores têm trabalhado fervorosamente para revisar sua abordagem a tempo para 6.1.
Mullenweg recomendou esses novos recursos como o principal candidato para o caminho do plug-in canônico, sugerindo que daria mais tempo para o ecossistema em torno do WebP amadurecer:
Estou interessado em oferecer suporte a novos formatos e melhorar o desempenho, mas acho que essa mudança sendo enviada por padrão aos usuários quando eles atualizam para 6.1 é muito para agora, inclusive com algumas das interações desajeitadas que os sistemas operacionais ainda têm em torno do webp (e HEIC! ) arquivos.
Estou feliz que o suporte para trabalhar com arquivos webp e HEIC permaneça no núcleo, pois devemos ser liberais no que aceitamos e com o que trabalhamos, mas não com a mudança para converter tudo em webp quando os JPEGs são carregados.
A equipe de desempenho planeja discutir isso no bate-papo agendado para amanhã. Ainda não está claro se o WebP recente, por padrão, será direcionado para o status de plug-in canônico ou se alguma parte dele ainda pode chegar à versão 6.1.
As respostas ao pedido de plugins mais canônicos foram mistas, já que alguns reconheceram imediatamente o aumento da carga sobre os mantenedores desses plugins.
“O WP só precisa superar sua aversão a recursos opcionais”, disse o desenvolvedor do WordPress Jon Brown. “Recursos que podem ser ativados/desativados. ‘Decisões, não opções’ é um ótimo ethos quando se trata de manter as coisas simples para os usuários, mas parece ter sido jogado pela janela com o Gutenberg UX e se transformado em axioma ao discutir a adição de opções trivialmente simples à página de configurações. ”
O colaborador patrocinado pelo iThemes, Timothy Jacobs, disse que não é necessariamente a favor da adição de mais opções ao Core, mas acha que os plugins canônicos podem ser apresentados de maneira semelhante às opções.
“Isso não significa que a interface do usuário precisa estar apenas pesquisando no diretório de plugins por algo que você deseja”, disse Jacobs. “Os plugins canônicos podem ser expostos em uma interface de usuário tipo ‘configurações’. Acho que os métodos de importação estão um pouco escondidos no menu Ferramentas, mas algo assim talvez.”
O principal colaborador Torsten Landsiedel disse que a diferença entre plugins canônicos e plugins de recursos não é clara. A distinção pode ser que os plugins canônicos incluem aqueles que podem nunca pertencer ao núcleo, mas ainda são importantes para os usuários.
“Parece que o plugin ‘WordPress importador’ pode ser um plugin canônico”, disse Landsiedel. “Não tenho certeza se este é um bom exemplo para um plugin * próspero *. Não suporta imagens em destaque, luta com grandes quantidades de postagens/mídia, etc.
“O útil plugin Health Check luta com pessoas desaparecidas ajudando.
“Como impedimos que esses plugins (seja lá o que for chamado) não recebam contribuidores suficientes? Eu acho que um importador é uma ferramenta crucial, mas também não é necessária no núcleo (eu posso instalá-lo se eu precisar, tudo bem) – mas deve funcionar e no momento isso não funciona bem. Mas não vejo muito interesse da comunidade dev em ajudar a corrigir isso (talvez porque eles usam WP CLI e não se importam com esse plugin?)”
O principal colaborador do WordPress, Colin Stewart, disse que, embora concorde que os recursos como plug-ins são úteis para novos recursos, ele requer “uma métrica muito melhor do que ‘sucesso descontrolado’ para inclusão no núcleo.
“Alguns recursos são importantes para a estabilidade e protegem os usuários de problemas que causam dor de cabeça várias vezes durante a vida útil do site, mas não são algo que os usuários possam pensar em procurar no repositório de plugins ou instalar à vista”, disse Stewart. “A reversão é um recurso, assim como a Saúde do Site, Exportação/Apagamento de Privacidade e outros.
“Um processo formal de tomada de decisão para propostas seria incrivelmente útil. Este tópico está surgindo regularmente agora.”
Mullenweg ofereceu quase duas dúzias de ideias para plugins canônicos que as equipes do Make poderiam considerar e sugeriu que as próprias equipes provavelmente poderiam ter ideias melhores. Imaginar todos esses novos recursos em jogo, seria como um renascimento da inovação no admin. Esta é uma perspectiva empolgante que pode beneficiar os usuários do WordPress, desde que os plugins sejam apresentados de forma que sejam fáceis de adotar. Os primeiros comentaristas sobre a ideia levantam preocupações legítimas sobre a falta de mantenedores, já que a história mostra que o suporte para alguns dos plugins canônicos existentes é um pouco irregular.
“Espero que desperte a discussão no dia do contribuidor e além sobre como podemos utilizar plugins melhor para aumentar a velocidade de evolução do WordPress, manter o núcleo leve, rápido e opinativo, e fazê-lo enquanto diz ‘sim’ a mais ideias e experimentação, disse Mullenweg.
[ad_2]
