Méthodes d'intégration de données de plugin avec des thèmes

J'aimerais avoir des avis sur les meilleures pratiques pour développer des plugins WordPress qui fournissent une intégration de thème.

Afin de donner un sens à ma question, permettez-moi de commencer par un exemple hypothétique d'un scénario qui m'intéresse. Imaginez que je crée un plugin appelé "Discographie". La discographie enregistre trois types de messages personnalisés: "Bandes", "Albums" et "Pistes". Le plugin fournit également des métadonnées qui fournissent des détails pour chaque type de publication, ainsi que des taxonomies personnalisées pour organiser chaque type de publication. Ces types de messages sont liés avec le plugin Posts 2 Posts . Au sein de l'administrateur, l'utilisateur peut ajouter de nouveaux groupes, qui peuvent être associés à des albums, qui à leur tour sont associés à des pistes, qui auront toutes beaucoup d'autres données ajoutées via des métadonnées et des taxonomies.

Maintenant, je ne veux pas que ce plugin configure simplement un administrateur pour que les utilisateurs entrent ces informations; Je voudrais qu'il fournisse des affichages par défaut pour les données. Un utilisateur / développeur plus avancé serait bien d'avoir seulement cet administrateur. Il serait assez facile pour elle de saisir ces données et de les utiliser dans le thème; cependant, sans certaines vues par défaut, ce plugin serait inutile pour la plupart des utilisateurs. Pour cet exemple, vous pouvez afficher quelque chose comme (les parenthèses indiquent la façon dont les informations peuvent être affichées dans l'ordre de la hiérarchie des modèles):

• Bandes (single-prefix-band.php, single.php, index.php, shortcode)
• Albums (single-prefix-album.php, single.php, index.php, shortcode)
• Pistes (single-prefix-track.php, single.php, index.php, shortcode)
• Liste des bandes (template-band-list.php, page-band-list.php, page- {id} .php, page.php, index.php, shortcode)
• Liste d'albums (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
• Chronologie de l'album (template-album-timeline.php, page-album-timeline.php, page- {id} .php, page.php, index.php, shortcode)

Il est important qu'il y ait une présentation par défaut pour ces types de publication car les fichiers de modèle par défaut n'afficheraient pas toutes les informations nécessaires pour chacun des types de publication. Par exemple, le thème Twenty Eleven, par défaut, afficherait simplement le nom, les catégories, la description et la date de publication d'un album. Pas très utile pour un album. Je voudrais fournir un modèle de publication unique qui intègre le groupe, la date de sortie, le label, les versions d'album, les pistes, etc. En tant que développeur de plugins, je pense que ce serait important à fournir. Je sais que le modèle ne fonctionnerait pas pour chaque thème, mais il devrait y avoir une valeur par défaut qui peut être davantage intégrée au thème de l'utilisateur.

Encore une fois, je suis curieux de savoir quelle est la meilleure façon de gérer cette situation? Je pense que vous pourriez faire l'une des choses suivantes.

Shortcodes

Les shortcodes peuvent être utilisés comme un moyen très flexible et convivial pour permettre aux non-développeurs d'ajouter des groupes, des albums, des pistes, des listes de groupes, etc. partout dans le site. Il serait utile de présenter des bandes sur des pages spécifiques ou de créer des pages distinctes pour chaque bande (pas très efficace, mais certains utilisateurs abordent les choses de cette façon). Le shortcode générerait du HTML, qui serait lié à un fichier CSS fourni qui fournirait une belle vue par défaut des données souhaitées. Tout serait contenu dans les fichiers du plugin et rien n'aurait besoin d'être fait avec le thème.

Fichiers de modèle

Le plugin peut également être livré avec des fichiers de modèle. Les fichiers de modèle peuvent être marqués et stylisés pour une belle vue par défaut. Vous pouvez fournir des instructions à votre utilisateur pour déplacer les fichiers vers le dossier du thème afin que le thème trouve les bons modèles lorsque les types de publication sont affichés. Vous pourriez même aller jusqu'à fournir une interface pour permettre à l'utilisateur de déplacer les fichiers en un seul clic (remarque: je ne créerais pas de fichiers dans le dossier de thème de l'utilisateur lors de l'activation, car ajouter des fichiers à leur thème sans les initier est mauvais) .

Vous pouvez également utiliser des filtres pour utiliser ces fichiers sans les déplacer hors du dossier du plugin, en gardant tout autonome. J'ai vu les filtres "template_include" et "{$ type} _template" utilisés à cet effet. En fait, vous pouvez utiliser des modèles du dossier des thèmes et s'ils ne sont pas présents, vous pouvez vous rabattre sur ces filtres pour fournir les vues par défaut.

La question

J'aime savoir ce que les autres pensent être les meilleures pratiques pour ces situations, si les idées présentées sont problématiques de quelque manière que ce soit, et toutes les alternatives que je n'ai pas incluses.

Je vous remercie!

Je ne peux pas répondre à tous les Q que vous avez demandés, car la lecture du Q a pris suffisamment de temps jusqu'à présent;), mais j'essaie de vous donner un aperçu de mon expérience personnelle avec le développement de plugins open source gratuits.

1. Ne faites jamais trop. Les fonctionnalités sont la mort de chaque plugin. Créez d'abord une version de base et testez la réaction de vos utilisateurs. Si votre plugin reçoit beaucoup d'attention, vous pouvez intégrer les fonctionnalités les plus demandées.

2. Évitez de remplir chaque cas d'utilisation. Vous devez maintenir votre plugin. WP propose une nouvelle version tous les trois mois. Et parfois, il est difficile de suivre tous vos plugins. Pour faire un exemple: Une nouvelle version de l'API Paramètres est actuellement discutée sur Trac. Lorsque cela sera terminé, il y a la possibilité que beaucoup de développeurs de plugins ou de thèmes aient besoin de modifier une grande partie du code et certaines personnes - comme moi - ont même écrit une couche d'abstraction au-dessus de l'API. Vous devez donc revenir en arrière, réécrire votre couche de base / abstraction, puis retravailler tout ce qui en appelle des parties. Je promets que c'est beaucoup de travail. Et encore plus s'il est étroitement lié à votre code. Lorsque vous commencez à remplir de nombreux cas d'utilisation, vous avez également beaucoup d'évolution du code de base WP que vous devez surveiller, ainsi que beaucoup de travail pour garder votre code à jour.

3. N'essayez jamais de regrouper de nombreux exemples de code (ou modèles) dans vos plugins ou thèmes. Si vous souhaitez cibler les développeurs et les utilisateurs finaux: utilisez votre blog pour la documentation. Les développeurs détestent des trucs comme ça et les utilisateurs finaux ne sont jamais satisfaits (voir: remplir tous les cas d'utilisation).

4. Divisez judicieusement votre code en fichiers uniques. Règle générale: un fichier pour une partie. Exemple: styles.php, scripts.php, taxonomies.php, cpts.php, etc. Chargez tout à partir d'une classe "mère" (usine) et gardez vos fichiers "enfichables". Si vous avez besoin de réécrire des trucs, vous les trouverez facilement. Si les développeurs recherchent quelque chose: ils le trouveront facilement. Beaucoup de fichiers bien nommés, ne vous font pas de mal.

5. Si vous avez une liste de styles de base (classes), laissez-la à l'utilisateur . Les chances sont tout simplement trop élevées, que les styles du thème ou d'autres plugins intercepteront vos définitions (quelle que soit la spécificité que vous ajoutez). Essayez simplement de l'expliquer quelque part avec le moins de texte possible.

6. Aimez votre plugin. Mais lâchez prise si vous vous ennuyez. :)

Maintenant - en bref - quelque chose sur votre idée de plugin en détail:

A. Les fichiers de modèle sont incorrects. Comme je l'ai dit: documentez-le sur votre blog, offrez-y des exemples de balises et de styles. Votre blog en profitera (et vous aussi si vous avez des publicités).

B. Les shortcodes sont kool. Ils ne nuisent à personne si le plugin a disparu (dans la plupart des cas) et pourrait être étendu / évolué plus tard vers les boutons TinyMCE (que les gens adorent).

C. Indiquez clairement que votre plugin a besoin d'un autre plugin. Questionnez-le et ajoutez une note à admin_notices (via register_activation_hook) si l'autre plugin ne se ferme pas (liez-le dans ce cas) ou n'est pas activé (vous pouvez le faire pour l'utilisateur lors de l'activation). Notez également que ce plugin provient d'une source fiable et sera maintenu pour les prochaines années.

Remarque: rien de ce que j'ai écrit n'est plus que mon opinion personnelle, qui reflète mon expérience.

À certains égards, vous devez peser l'équilibre entre la création d'un plugin ou d'un thème, si votre scénario nécessite beaucoup de personnalisation / fonctionnalités, il est généralement préférable de créer un thème à la place. De cette façon, l'utilisateur peut ensuite personnaliser en termes de look, ce qui est toujours plus facile que de demander à l'utilisateur de personnaliser les fonctionnalités (en bloquant les shortcodes partout), vous avez un meilleur contrôle des fonctionnalités, cela fonctionne avec d'autres plugins, etc.

Un plugin essayant de s'intégrer fortement avec toute la variété des thèmes sur le marché est susceptible de vous causer beaucoup de problèmes et honnêtement beaucoup de travail.

Par exemple, au lieu de créer un plugin très intégré basé sur la gestion de la musique et de la discographie, créez plutôt un thème à cet effet, cela devient de plus en plus populaire pour les marchés de niche qui nécessitent un travail personnalisé. Un exemple du monde réel serait un thème basé sur l'immobilier, il n'y a aucun moyen d'utiliser un plugin pour cela car il a un ensemble de fonctionnalités aussi approfondi, au lieu de cela, il est créé à partir de zéro en tant que thème, car les thèmes peuvent tirer parti de toutes les fonctionnalités des plugins de toute façon.

Il est également probable que d'un point de vue marketing, un thème de niche fera mieux qu'un plugin lors de l'équilibrage des fonctionnalités frontales.

Pages virtuelles

Une troisième technique que j'ai vue consistait à assigner une page spéciale comme espace réservé pour votre plugin et à utiliser le filtre 'the_content' pour sortir tout ce dont vous avez besoin pour sortir.

De cette façon, vous pouvez créer des modèles qui se fondent dans la structure du thème, car vous n'avez pas à gérer les en-têtes, les barres latérales, les pieds de page et les diviseurs de wrapper.

Un bon exemple de cela peut être trouvé dans le plugin bbPress:

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