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

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

Para fazer sentido ao fazer esta pergunta, deixe-me começar com um exemplo hipotético de um cenário que me interessa. Imagine que eu criei um plugin chamado "Discography". A discografia registra três tipos de postagem personalizados: "Bandas", "Álbuns" e "Faixas". O plug-in também fornece meta boxes que fornecem detalhes para cada tipo de postagem, bem como taxonomias personalizadas para organizar cada tipo de postagem. Esses tipos de postagens estão vinculados ao plug-in Postagens 2 Postagens . Dentro do administrador, o usuário pode adicionar novas bandas, que podem ser associadas a álbuns, as quais, por sua vez, são associadas a faixas, todas as quais terão muitos outros dados adicionados a eles por meio de meta boxes e taxonomias.

Agora, não quero que este 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 seria bom em ter apenas esse administrador. Seria fácil o suficiente para ela pegar esses dados e usá-los no tema; no entanto, sem algumas visualizações padrão, esse plug-in seria inútil para a maioria dos usuários. Neste exemplo, você pode exibir qualquer coisa como (parênteses mostram como as informações podem ser exibidas na ordem da hierarquia do modelo):

• Bandas (prefixo único-band.php, single.php, index.php, código de acesso)
• Álbuns (prefixo-único-album.php, single.php, index.php, código de acesso)
• Faixas (single-prefix-track.php, single.php, index.php, shortcode)
• Listagem de Bandas (template-band-list.php, page-band-list.php, page- {id} .php, page.php, index.php, shortcode)
• Listagem de álbum (template-album-list.php, page-album-Listing.php, página- {id} .php, page.php, index.php, shortcode)
• Linha do tempo do álbum (template-album-timeline.php, page-album-timeline.php, página- {id} .php, page.php, index.php, shortcode)

É importante que exista 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 tipo de postagem. Por exemplo, o tema Twenty Eleven, por padrão, mostraria apenas o nome, categorias, descrição e data de publicação de um álbum. Não é muito útil para um álbum. Eu gostaria de fornecer um único modelo de postagem que inclua a banda, data de lançamento, gravadora, versões de álbuns, faixas etc. Como desenvolvedor de plug-ins, eu sentiria que isso seria importante. 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 maneira muito flexível e amigável para permitir que os não-desenvolvedores adicionem bandas, álbuns, faixas, listas de bandas etc. em qualquer lugar do site. Seria útil 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 código abreviado geraria 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 de plug-in e nada precisaria ser feito com o tema.

Arquivos de modelo

O plug-in também pode ser enviado com arquivos de modelo. Os arquivos de modelo podem ser marcados e estilizados para uma boa visualizaçã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 certos quando os tipos de postagem forem exibidos. Você pode até fornecer uma interface para permitir que o usuário mova os arquivos com um único clique (nota: eu não criaria arquivos na pasta de temas do usuário na ativação porque adicionar arquivos ao tema deles sem que eles iniciassem é ruim) .

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

A questão

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 maneira e quaisquer alternativas que não incluí.

Obrigado!

Não consigo responder a todas as perguntas que você perguntou, pois a leitura demorou bastante tempo;), mas tento fornecer algumas idéias sobre minha experiência pessoal no 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 dos seus usuários. Se o seu plugin chamar muita atenção, você poderá integrar os recursos 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 seguir com todos os seus plugins. Para dar um exemplo: Atualmente, uma nova versão da API de configurações é discutida no Trac. Quando isso terminar, haverá a chance de muitos desenvolvedores de plugins ou temas precisarem alterar uma grande parte do código e algumas pessoas - como eu - até escreverem uma camada de abstração acima da API. Então, você precisa voltar, reescrever sua camada de base / abstração e refazer tudo o que chama partes dela. Eu prometo que isso é muito trabalho. E ainda mais se estiver vinculado ao seu código. Quando você começa a preencher muitos casos de uso, também tem muita evolução do código principal do WP que precisa monitorar, além de 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 direcionar desenvolvedores e usuários finais: use seu blog para documentação. Os desenvolvedores odeiam coisas assim e os usuários finais nunca ficam satisfeitos (consulte: preenchendo todos os casos de uso).

4. Divida seu código com sabedoria em arquivos únicos. Regra geral: 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 "conectáveis". Se você precisar reescrever coisas, encontrará com facilidade. Se os desenvolvedores estão procurando por algo: eles o encontrarão facilmente. Muitos arquivos bem nomeados não o prejudicam.

5. Se você possui uma lista de estilos básicos (classes), deixe para o usuário . As chances são muito altas, pois os estilos do tema ou de outros plugins interceptam suas definições (não importa quanta especificidade você use). Apenas tente explicá-lo em algum lugar com o mínimo de texto possível.

6. Ame seu plugin. Mas deixe ir se você estiver entediado. :)

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

A. Arquivos de modelo são ruins. Como eu disse: documente no seu blog, ofereça exemplos de marcação e estilos lá. Seu blog terá lucro (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 plug-in for desativado (na maioria dos casos) e posteriormente poderão ser estendidos / evoluídos para os botões TinyMCE (que as pessoas adoram).

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

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

Em alguns aspectos, você deve avaliar o equilíbrio entre criar um plug-in ou um tema, se o seu cenário exigir muita personalização / recursos, geralmente é sempre melhor criar um tema. Dessa forma, o usuário pode personalizar em termos de aparência, o que é sempre mais fácil do que fazer com que ele personalize a funcionalidade (bloqueando códigos de acesso em qualquer lugar), você tem maior controle de recursos, funciona com outros plugins, etc.

Um plug-in que tenta se integrar fortemente a toda a variedade de temas do mercado provavelmente 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 de criar um tema para esse fim, isso está se tornando mais popular para nichos de mercado que exigem trabalho personalizado. Um exemplo do mundo real seria um tema imobiliário, não há como usar um plug-in para isso, pois ele possui um conjunto de recursos tão profundo, em vez disso, ele é criado desde o início como um tema, pois os temas podem tirar proveito todos os recursos dos plugins de qualquer maneira.

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

Páginas virtuais

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

Dessa forma, você pode criar modelos que se misturam à estrutura do tema, pois não é necessário lidar com cabeçalhos, barras laterais, rodapés e divs de wrapper.

Um ótimo exemplo disso pode ser encontrado no plugin bbPress:

http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compatibility.php?rev=3434#L931