Enquanto pesquisava um plugin para um vídeo lá do meu canal no YouTube – pronto, assim o jabá já fica feito – descobri que a recomendação oficial é manter bibliotecas e frameworks dentro do seu plugin e não como plugins separados. Nesse caso se encaixam aqueles que não fornecem interface visual, mas que são componentes necessários para outros plugins, como o CMB2 e o Carbon Fields, por exemplo.
A justificativa é que o desenvolvedor entende essa dependência, mas o usuário não. Uma lista de possíveis problemas:
- O usuário pode não reconhecer o plugin e exclui-lo, quebrando o site.
- O usuário pode não reconhecer o plugin e achar que o site dele foi invadido.
- Ao atualizar um dos dois plugins, a biblioteca ou o plugin que depende dela, tudo pode quebrar.
- Diferentes plugins podem precisar do mesmo framework, mas com versões diferentes.
Por essas e outras não são mais aceitos plugins novos com essas características no repositório oficial. O Carbon Fields, por exemplo, agora só disponibiliza versões através do GitHub, deixando a versão do repositório desatualizada, mas com um tópico no fórum explicando o motivo.
Confesso que fiz errado até bem pouco tempo atrás, instalando o CMB2 como plugin separado. Como a gente vive pra aprender, fica a dica pra você que também não sabia disso 🙂
Não lembro se já falei isso aqui no blog antes, mas no vídeo que eu fiz sobre território de temas e plugins, comentei sobre o teste feito pelo WooCommerce Correios para verificar a disponibilidade do WooCommerce. Os códigos relacionados são este e este aqui. Eles envolvem a action plugins_loaded, executada depois que todos os plugins estão carregados, e a action admin_notices, usada para exibir avisos no Painel.
