Como criar uma API para o meu plugin?

20

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

Estou planejando desenvolver dois plug-ins de software livre para fornecer algum tipo de sistema complexo (não é possível compartilhar detalhes no momento, mas posteriormente durante o desenvolvimento), onde outros desenvolvedores podem personalizar funções e o sistema precisa ser o mesmo Buddypress e WooCommerce.

Ao verificar esses arquivos de plugins e perceber que eles registraram suas próprias ações e filtros, os desenvolvedores podem modificar conforme a necessidade. No entanto, meu problema é ser incapaz de entender completamente, como eu deveria escrever um plugin onde outros têm a flexibilidade de substituir funções, bem como adicionar seus próprios.

Eu sei que é difícil dar uma resposta definitiva, mas eu preciso de algum tipo de guia inicial para que eu possa ir na direção certa. Preciso registrar minhas próprias ações e filtros? Se sim como? se não, quais são minhas opções?

Seu conselho vai me ajudar muito ... Obrigado

    
por pixelngrain 08.05.2013 / 12:23

1 resposta

24

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.

Eu sou um colaborador de vários plug-ins com APIs e o que aprendi até agora é:

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

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

    Manter a compatibilidade com versões anteriores de uma API é difícil . Pode impedir 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 (veja 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 para você mesmo se não precisar.

  3. Coma sua própria comida de cachorro.
    Se você oferecer ganchos personalizados, use-os em 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 chamada API de configurações internamente, não teríamos essa bagunça hoje. Talvez.

  4. Liderar pelo exemplo.
    Use as partes boas da API principal do WordPress no seu plugin. 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 tal confusão ) e coloque tudo sob seu próprio namespace.

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

  7. Evite o inferno do 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 minificadas). Eu escrevi um exemplo de como depurar AJAX , apenas para ilustrar o quão criativo você pode estar aqui. Novamente, essas ferramentas devem ser explicadas em sua documentação antes de serem lançadas.

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

por fuxia 08.05.2013 / 20:36