Méthodes d'intégration des données de plug-in aux thèmes

15

J'aimerais connaître votre avis sur les meilleures pratiques pour développer des plugins WordPress fournissant une intégration de thèmes.

Afin de donner un sens à cette question, permettez-moi de commencer par un exemple hypothétique d'un scénario qui m’intrigue. Imaginez que je crée un plugin appelé "Discography". Discography enregistre trois types de messages personnalisés: "Bandes", "Albums" et "Pistes". Le plugin fournit également des méta-boîtes 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 publication sont liés avec le plug-in Posts 2 Posts . Au sein de l’administrateur, l’utilisateur peut ajouter de nouveaux groupes, qui peuvent être associés à des albums, lesquels, à leur tour, sont associés à des pistes, qui se verront ajouter de nombreuses autres données via des méta-boîtes et des taxonomies.

Maintenant, je ne veux pas que ce plugin mette simplement en place un administrateur pour que les utilisateurs entrent cette information; Je voudrais qu'il fournisse des affichages par défaut pour les données. Un utilisateur / développeur plus expérimenté serait bien de n'avoir que 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 n’importe quoi de semblable (les parenthèses indiquent la manière 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-listing.php, page- {id} .php, page.php, index.php, shortcode)
  • Liste des albums (template-album-list.php, page-album-listing.php, page- {id} .php, page.php, index.php, shortcode)
  • Chronologie de l'album (modèle-album-timeline.php, page-album-timeline.php, page- {id} .php, page.php, index.php, shortcode)

Il est important qu’il existe une présentation par défaut pour ces types de publication, car les fichiers de modèle par défaut n’afficheront 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 souhaiterais fournir un seul modèle de publication indiquant le groupe, la date de sortie, le label, les versions de l'album, les pistes, etc. En tant que développeur de plug-in, j'estimerais qu'il serait important de le fournir. Je sais que le modèle ne fonctionnerait pas pour tous les thèmes, mais il devrait y avoir des paramètres par défaut pouvant être intégrés au thème de l'utilisateur.

Encore une fois, je suis curieux de savoir quel est le meilleur moyen de gérer cette situation? Je pense que vous pouvez faire l’un des choix suivants.

Codes courts

Les codes courts peuvent être utilisés comme un moyen très souple et convivial permettant aux non-développeurs d’ajouter des groupes, des albums, des pistes, des listes de groupes, etc. n'importe où sur le site. Cela serait utile pour présenter des groupes sur des pages spécifiques ou créer des pages séparées pour chaque groupe (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 ne devrait être fait avec le thème.

Fichiers de modèle

Le plugin pourrait également être livré avec des fichiers de modèle. Les fichiers de gabarit peuvent être balisés et stylés pour une belle vue par défaut. Vous pouvez indiquer à votre utilisateur comment déplacer les fichiers dans le dossier du thème afin que celui-ci trouve les bons modèles lorsque les types d'articles sont affichés. Vous pourriez même aller jusqu'à fournir une interface permettant à l'utilisateur de déplacer les fichiers en un seul clic (note: je ne créerais pas de fichiers dans le dossier du thème de l'utilisateur lors de l'activation, car l'ajout de fichiers à leur thème sans que celui-ci ne l'ait initié est mauvais) .

Vous pouvez également utiliser des filtres pour utiliser ces fichiers sans les sortir du dossier du plug-in, tout en les maintenant autonomes. J'ai vu les filtres "template_include" et "{$ type} _template" utilisés à cette fin. En fait, vous pouvez utiliser des modèles du dossier themes et s’ils ne sont pas présents, vous pouvez utiliser 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 façon que ce soit et quelles que soient les alternatives que je n'ai pas incluses.

Merci!

    
posée tollmanz 12.08.2011 - 01:25

3 réponses

4

Je ne peux pas répondre à toutes les questions que vous avez posées, car la lecture de la question a pris suffisamment de temps;), mais j'essaie de vous donner un aperçu de mon expérience personnelle avec le développement de plugins gratuits et à code source ouvert.

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

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

3. N'essayez jamais de regrouper de nombreux exemples de code (ou modèles) dans vos plugins ou vos thèmes. Si vous souhaitez cibler les utilisateurs finaux et des développeurs: utilisez votre blog pour la documentation. Les développeurs détestent ce genre de choses 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 de base: Un fichier pour une partie. Exemple: styles.php, scripts.php, taxonomies.php, cpts.php, etc. Chargez tout depuis une classe "mère" (usine) et gardez vos fichiers "connectables". Si vous avez besoin de réécrire des choses, vous les trouverez facilement. Si les développeurs cherchent quelque chose, ils le trouveront facilement. Beaucoup de fichiers bien nommés, ne vous faites pas de mal.

5. . Si vous avez une liste de styles de base (classes), le laisse à l'utilisateur . Les chances sont simplement trop élevées, que les styles du thème ou d'autres plugins interceptent vos définitions (peu importe la précision que vous ajoutez). Essayez simplement de l'expliquer quelque part avec le moins de texte possible.

6. aimez votre plugin. Mais laisse-toi aller si tu t'ennuies. :)

Maintenant - en quelques mots - quelque chose au sujet de 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 tirera profit (et vous aussi si vous avez des annonces).

B. Les codes courts sont kool. Ils ne font de mal à personne si le plug-in est parti (dans la plupart des cas) et pourrait ultérieurement être étendu / évolué vers les boutons TinyMCE (que les gens adorent).

C. Indiquez clairement que votre plug-in a besoin d'un autre plug-in. Questionnez ceci et ajoutez une note à admin_notices (via register_activation_hook) si l'autre plugin ne se ferme pas (le lier 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 qu'il sera maintenu pour les prochaines années.

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

    
réponse donnée kaiser 12.08.2011 - 03:30
2

À certains égards, vous devez peser de poids entre créer un plugin ou 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 personnaliser l'apparence, ce qui est toujours plus facile que de demander à l'utilisateur de personnaliser la fonctionnalité (en bloquant des codes abrégés partout), vous disposez d'un meilleur contrôle des fonctionnalités, cela fonctionne avec d'autres plugins, etc.

Un plugin qui tente de s’intégrer strongment à toute la variété de thèmes disponibles sur le marché vous causera énormément 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, de créer un thème à cette fin, il devient de plus en plus populaire pour les marchés de niche qui nécessitent un travail personnalisé. Un exemple concret serait un thème basé sur l'immobilier. Il est impossible d'utiliser un plugin pour cela, car il contient un ensemble de fonctionnalités aussi complet. Il est créé à partir du sol en tant que thème, car les thèmes peuvent en tirer parti. 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 pour équilibrer les fonctionnalités frontales.

    
réponse donnée Wyck 12.08.2011 - 18:35
2

Pages virtuelles

Une troisième technique que j’ai vue consistait à assigner une page spéciale en tant qu’espace réservé à votre plug-in et à utiliser le filtre 'the_content' pour générer tout ce dont vous avez besoin.

De cette manière, vous pouvez créer des modèles qui se fondent dans la structure du thème, car vous n'avez pas à vous occuper des en-têtes, des barres latérales, des pieds de page et des objets div.

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

enlace

    
réponse donnée scribu 12.08.2011 - 17:15

Lire d'autres questions sur les étiquettes