Métodos de integração de dados de plug-in com temas

15

Gostaria de obter algumas opiniões sobre as práticas recomendadas para o desenvolvimento de plugins do WordPress que fornecem integração de temas.

Para fazer sentido ao fazer essa pergunta, deixe-me começar com um exemplo hipotético de um cenário sobre o qual estou curioso. Imagine que eu crie um plugin chamado "Discografia". A Discografia registra três tipos de postagem personalizados: "Bandas", "Álbuns" e "Faixas". O plug-in também fornece caixas meta que fornecem detalhes para cada tipo de postagem, bem como taxonomias personalizadas para organizar cada tipo de postagem. Esses tipos de postagem estão vinculados ao plug-in Posts 2 Posts . Dentro do admin, o usuário pode adicionar novas bandas, que podem ser associadas a álbuns, os quais, por sua vez, são associados a faixas, todos os quais terão muitos outros dados adicionados a eles através de caixas meta e taxonomias.

Agora, não quero que esse plug-in simplesmente configure um administrador para que os usuários insiram essas informações. Eu gostaria que ele fornecesse algumas exibições padrão para os dados. Um usuário / desenvolvedor mais avançado estaria bem com apenas esse administrador. Seria fácil para ela pegar esses dados e usar o tema; no entanto, sem algumas exibições padrão, esse plug-in seria inútil para a maioria dos usuários. Para este exemplo, você pode exibir qualquer coisa como (os parênteses mostram as formas em que a informação pode ser exibida na ordem da hierarquia do modelo):

  • Bandas (single-prefix-band.php, single.php, index.php, shortcode)
  • Álbuns (single-prefix-album.php, single.php, index.php, shortcode)
  • Faixas (single-prefix-track.php, single.php, index.php, shortcode)
  • Listagem de banda (template-band-list.php, page-band-listing.php, page- {id} .php, page.php, index.php, shortcode)
  • Lista de álbuns (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
  • Timeline do álbum (template-album-timeline.php, page-album-timeline.php, page- {id} .php, page.php, index.php, shortcode)

É importante que haja alguma apresentação padrão para esses tipos de postagem, pois os arquivos de modelo padrão não exibirão todas as informações necessárias para cada um dos tipos de postagem. Por exemplo, o tema do Twenty Eleven, por padrão, mostraria apenas o nome, categorias, descrição e data de postagem de um álbum. Não é muito útil para um álbum. Eu gostaria de fornecer um único modelo de post que incluísse a banda, a data de lançamento, a gravadora, as versões do álbum, as faixas, etc. Como desenvolvedor de plugins, eu sentiria que isso seria importante para fornecer. Eu sei que o modelo não funcionaria para todos os temas, mas deve haver algum padrão que possa ser mais integrado ao tema do usuário.

Mais uma vez, estou curioso sobre qual é a melhor maneira de lidar com essa situação? Eu acho que você poderia fazer qualquer um dos seguintes.

Códigos de acesso

Os códigos de acesso podem ser usados como uma forma muito flexível e amigável para permitir que os não-desenvolvedores adicionem bandas, álbuns, faixas, listas de banda, etc. em qualquer lugar do site. Seria útil para apresentar bandas em páginas específicas ou criar páginas separadas para cada banda (não muito eficiente, mas alguns usuários abordam as coisas dessa maneira). O shortcode geraria o HTML, que seria vinculado a um arquivo CSS fornecido que forneceria uma boa visualização padrão dos dados desejados. Tudo estaria contido nos arquivos do plugin e nada precisaria ser feito com o tema.

Arquivos de modelo

O plugin também pode ser fornecido com arquivos de modelo. Os arquivos de modelo podem ser marcados e estilizados para uma bela exibição padrão. Você pode fornecer instruções para o usuário mover os arquivos para a pasta do tema, para que o tema encontre os modelos corretos quando os tipos de postagem forem exibidos. Você pode até mesmo fornecer uma interface para permitir que o usuário mova os arquivos com um único clique (nota: eu não criaria arquivos na pasta do tema do usuário na ativação porque adicionar arquivos ao tema sem iniciá-los é mal) .

Você também pode usar filtros para utilizar esses arquivos sem removê-los da pasta do plug-in, mantendo tudo contido. Eu vi os filtros "template_include" e "{$ type} _template" usados para essa finalidade. Na verdade, você poderia usar modelos da pasta de temas e, se eles não estiverem presentes, você poderá recorrer a esses filtros para fornecer as exibições padrão.

A questão

Eu gosto de saber o que os outros acham que são as melhores práticas para essas situações, se as idéias apresentadas são problemáticas de alguma forma, e quaisquer alternativas que eu não inclua.

Obrigado!

    
por tollmanz 12.08.2011 / 01:25

3 respostas

4

Eu não posso responder a cada Q que você pediu, já que ler o Q levou tempo suficiente até agora;), mas eu tentei dar algumas dicas sobre minha experiência pessoal com o desenvolvimento de plugins gratuitos e de código aberto.

1. Nunca faça demais. Recursos são a morte de todos os plugins. Crie uma versão básica primeiro e teste a reação de seus usuários. Se o seu plug-in recebe muita atenção, você pode integrar os recursos que são mais solicitados.

2. Evite preencher todos os casos de uso. Você precisa manter seu plugin. O WP oferece uma nova versão a cada três meses. E às vezes é difícil acompanhar todos os seus plugins. Para fazer um exemplo: uma nova versão da API de configurações está atualmente discutida no Trac . Quando isso for concluído, há a chance de que muitos desenvolvedores de plug-ins ou de temas precisem alterar uma grande parte do código, e algumas pessoas - como eu - já escreveram uma camada de abstração acima da API. Então você precisa voltar, reescrever sua camada base / abstração e então refazer tudo o que chama partes disso. Eu prometo que isso é muito trabalho. E ainda mais, se estiver preso ao seu código. Quando você começa a preencher muitos casos de uso, você também tem um monte de evolução do código principal do WP que precisa monitorar, assim como tem muito trabalho para manter seu código atualizado.

3. Nunca tente agrupar muitos exemplos de código (ou modelos) em seus plugins ou temas. Se você deseja segmentar desenvolvedores e usuários finais: Use seu blog para documentação. Os desenvolvedores detestam coisas assim e os usuários finais nunca estão satisfeitos (veja: preenchendo todos os casos de uso).

4. Divida seu código com sabedoria em arquivos únicos. Regra de ouro: um arquivo para uma parte. Exemplo: styles.php, scripts.php, taxonomies.php, cpts.php, etc. Carregue tudo de uma classe "mãe" (fábrica) e mantenha suas coisas "plugáveis". Se você precisa reescrever coisas, você vai encontrá-lo facilmente. Se os desenvolvedores estão procurando por algo: eles vão encontrá-lo facilmente. Um monte de arquivos bem nomeados, não te prejudiquem.

5. Se você tem uma lista de estilos básicos (classes), deixe para o usuário . As chances são simplesmente muito altas, que os estilos do tema ou outros plugins interceptem suas definições (não importa o quanto de especificidade você jogue). Apenas tente explicar em algum lugar com menos texto possível.

6. Ame seu plug-in. Mas deixe ir se você estiver entediado. :)

Agora - em poucas palavras - algo sobre sua ideia de plug-in em detalhes:

A. Os arquivos de modelo são ruins. Como eu disse: Documente em seu blog, ofereça exemplos de marcação e estilos lá. Seu blog vai lucrar (e você também se tiver anúncios).

B. Os códigos de acesso são kool. Eles não prejudicam ninguém se o plugin desaparecer (na maioria dos casos) e podem ser estendidos / evoluídos posteriormente para os botões do TinyMCE (que as pessoas adoram).

C. Deixe claro que seu plug-in precisa de outro plug-in. Questione isso e adicione uma nota a admin_notices (via register_activation_hook) se o outro plugin não sair (link neste caso) ou não estiver ativado (você pode fazer isso para o usuário na ativação). Observe também que este plug-in vem de uma fonte confiável e será mantido nos próximos anos.

Nota: Nada do que escrevi é mais do que minha opinião pessoal, o que reflete minha experiência.

    
por kaiser 12.08.2011 / 03:30
2

Em alguns aspectos, é preciso ponderar o equilíbrio entre a criação de um plug-in ou um tema. Se o cenário exigir muitos recursos / personalização, normalmente é sempre melhor criar um tema. Dessa forma, o usuário pode personalizar em termos de aparência, que é sempre mais fácil do que fazer com que o usuário personalize a funcionalidade (por meio de atalhos em todos os lugares), você tem maior controle de recursos, funciona com outros plugins etc.

Um plugin que tenta se integrar strongmente com toda a variedade de temas no mercado pode causar muitos problemas e, honestamente, muito trabalho para você.

Por exemplo, em vez de criar um plug-in muito integrado com base no gerenciamento de música e discografia, em vez disso, crie um tema para essa finalidade. Isso está se tornando mais popular para nichos de mercado que exigem trabalho personalizado. Um exemplo do mundo real seria um tema baseado em imóveis, não há como usar um plugin para isso, pois ele tem um conjunto de recursos tão profundo, em vez disso, ele é criado a partir do zero como tema, já que os temas podem aproveitar todos os recursos de plugins de qualquer maneira.

Também é provável que, de uma perspectiva de marketing, um tema de nicho seja melhor que um plugin ao equilibrar os recursos front-end.

    
por Wyck 12.08.2011 / 18:35
2

Páginas virtuais

Uma terceira técnica que vi foi atribuir uma página especial como o espaço reservado para o seu plugin e usar o filtro 'the_content' para produzir o que você precisa para imprimir.

Dessa forma, você pode criar modelos que combinam com a estrutura do tema, pois você não precisa lidar com cabeçalhos, barras laterais, rodapés e divs de wrapper.

Um ótimo exemplo disso pode ser encontrado no plug-in bbPress:

enlace

    
por scribu 12.08.2011 / 17:15