Como criar uma API para o meu plugin?

Eu desenvolvi plugins para WordPress, a maioria dos plugins que desenvolvi usa duas ou três classes, portanto não tão grandes quanto o Buddypress ou o WooCommerce.

Estou planejando desenvolver dois plugins de código aberto para fornecer algum tipo de sistema complexo (não é possível compartilhar detalhes no momento, mas mais tarde durante o desenvolvimento), onde outros desenvolvedores podem personalizar funções e o sistema para eles precisa ser o mesmo que Buddypress e WooCommerce .

Enquanto eu verifico esses arquivos de plugins e percebo que eles registraram suas próprias ações e filtros que os desenvolvedores podem modificar conforme a necessidade. No entanto, meu problema é ser incapaz de entender completamente, como devo escrever um plug-in no qual outras pessoas tenham a flexibilidade de substituir funções e adicionar suas próprias.

Sei que é difícil dar uma resposta definitiva, mas preciso de algum tipo de guia de inicialização para poder seguir na direção certa. Preciso registrar minhas próprias ações e filtros? Se sim, como? caso contrário, quais são minhas opções?

Seu conselho vai me ajudar muito ... Obrigado

A API que você oferece em um plug-in ou tema depende da lógica desse código específico. Provavelmente não existe um guia que se aplique a todas as situações.

Sou colaborador de vários plugins com APIs e o que aprendi até agora é:

1. Não ofereça uma API até saber realmente como as pessoas usam seu código.

   Libere as duas ou três primeiras versões sem nenhuma API. Nenhuma ação ou filtro personalizado, nenhum método ou função pública (e nunca nenhuma variável global), se possível. Aguarde solicitações de seus usuários, mas não adicione o código até saber que sua estrutura interna de código funcionará a longo prazo.

   É difícil manter a compatibilidade com versões anteriores de uma API . Isso pode impedir as melhorias necessárias em outros lugares. Pense em todas as variáveis ​​globais que o WordPress não pode remover hoje em dia. Essa é uma API ruim e estamos presos a ela por muitos anos, porque as pessoas já a usam .

2. Considere separar sua API do restante do código (consulte o link anterior para uma ideia).
   Sua API deve ser útil não apenas para desenvolvedores de terceiros, mas também para você. Não adicione restrições se não for necessário.

3. Coma sua própria comida de cachorro.
   Se você oferece ganchos personalizados, use-os no seu código. Isso dará a outros desenvolvedores exemplos úteis e você poderá ver possíveis falhas em breve.
   Se o núcleo do WordPress usasse a API de configurações internamente, não teríamos essa bagunça hoje. Talvez.

4. Lidere pelo exemplo.
   Use as partes boas da API principal do WordPress em seu plug-in. Evite objetos anônimos , constantes, variáveis ​​globais e qualquer tipo de código imprevisível .

5. Verifique se você está usando um esquema de nomenclatura consistente (não uma bagunça ) e coloque tudo sob seu próprio espaço para nome.

6. Escreva a documentação primeiro. Libere uma nova (parte de uma) API posteriormente.
   Crie exemplos úteis para tudo. Você ficará surpreso ao ver quantos buracos e redundâncias você encontrará.

7. Evite o inferno de retorno de chamada.
   Ofereça ferramentas específicas para depurar sua API quando as coisas não funcionarem como deveriam (incluindo scripts e folhas de estilo não minificados). Eu escrevi um exemplo de como depurar o AJAX , apenas para ilustrar como você pode ser criativo aqui. Novamente, essas ferramentas devem ser explicadas na sua documentação antes de serem liberadas.

8. Uma alternativa ao paradigma de retorno de chamada do WordPress poderia ser o padrão Observer . Isso aumentaria a barreira para desenvolvedores de terceiros, mas poderia resultar em um código melhor para os dois lados.