web-dev-qa-db-fra.com

Créer un type de message personnalisé en tant que plugin? Pourquoi?

J'ai essayé de créer un type de message personnalisé en tant que plug-in (car je l'ai déjà recommandé à différents endroits).

Mais j'ai une question pas à propos du comment, mais plutôt le pourquoi de la construction de CPT en tant que plugin.

Oui ... Ajouter le CPT en tant que plugin garde mon functions.php Sympa et bien rangé.

Mais...

  1. En supposant que j'ai activé has_archive, j'ai encore besoin de créer archive-cpt.php, n'est-ce pas?
  2. Aussi: afin d'afficher le CPT, j'ai besoin de créer une boucle personnalisée, donc j'ai toujours besoin de créer single-cpt.php ... non?
  3. Et ces fichiers doivent être créés dans le thème, n'est-ce pas?

Si je comprends bien,

  1. Si je désactive le plug-in: I toujours doit supprimer (ou masquer ou autre) les pages archive-cpt.php et single-cpt.php.
  2. Si je change de thème: il me reste à ajouter ces deux pages dans le nouveau thème. Droite?

Je n'ai même pas abordé la question de l'ajout d'un CPT à la boucle par défaut (et ses implications sur les cpt à base de plugin).

Alors, pourquoi un CPT plugin?

custom-post-typesplugin-development
7
sleeper

la réponse de toscho est correcte en ce qui concerne les raisons techniques pour définir votre CPT dans un plugin, mais il me semble qu'une bonne partie de votre question découle d'un malentendu de la hiérarchie des modèles. Presque, mais pas tout à fait, chaque fichier de modèle que vous avez vu est facultatif.

À l'exception du fichier de modèle index.php de base, les développeurs de thèmes peuvent choisir s'ils souhaitent ou non implémenter un fichier de modèle particulier. Si WordPress ne parvient pas à trouver un fichier de modèle avec un nom correspondant, il passe directement au nom de fichier suivant dans la hiérarchie. Si WordPress ne trouve aucun fichier de modèle correspondant, index.php (le fichier de modèle de page d'accueil du thème) sera utilisé.

http://codex.wordpress.org/Template_Hierarchy

WordPress utilisera les fichiers spécialisés particuliers s’ils existent, mais retombera dans un autre fichier - finalement index.php-- s’il n’ya pas de fichiers spécialisés. Votre thème n'a pas à implémenter quoi que ce soit de spécial pour traiter ou compenser les CPT de votre plugin. Le thème peut mais pas doit.

  1. En supposant que j'ai activé has_archive, j'ai encore besoin de créer archive-cpt.php, n'est-ce pas?

archive.php sera utilisé et si cela échoue, alors index.php

  1. Aussi: afin d'afficher le CPT, j'ai besoin de créer une boucle personnalisée, donc j'ai toujours besoin de créer single-cpt.php ... non?

Encore une fois, non. Même raison. single.php sera utilisé et si non index.php.

  1. Et ces fichiers doivent être créésdans le thème, non?

Oui, mais ils sont optionnels. Vous n'en avez pas besoin du tout.

  1. Si je désactive le plugin: Iencoredevez supprimer (ou masquer ou quelque chose de ce genre) les pages archive-cpt.php et single-cpt.php.

Non, vous n'avez rien à faire. Les modèles ne seront pas utilisés.

  1. Si je change de thème : Je dois encore ajouter ces deux pages au nouveau thème. Droite?

Faux. Les modèles sont facultatifs. Vous n'en aurez besoin que si vous souhaitez un affichage personnalisé pour le type d'article.

Lorsque vous comprenez que le thème et le CPT ne sont pas aussi intimement liés que le semble votre question, une autre logique devrait alors être un peu plus logique.

4
s_ha_dum

Le thème n'est pas chargé lorsque la constante SHORTINIT est définie sur TRUE (gestionnaires personnalisés AJAX, importateurs ou API), aucune publication ne peut être ajoutée à un tel type de publication ou une telle taxonomie personnalisée.

Les modèles sont les vues pour le contenu personnalisé, ils ne doivent pas définir ou s'appuyer sur la logique.

En outre, après un changement de thème, l'utilisateur ne peut plus accéder au contenu du type de publication ni en modifier le contenu, car il n'y aurait pas d'interface sans l'enregistrement.

Après avoir désactivé un plugin, vous n'avez pas besoin de changer de thème. Les modèles ne sont tout simplement plus utilisés.

Update: Un autre avantage des plugins est la possibilité de les activer network wide . Je suis le développeur principal de Presse multilingue , et nous proposons à nos utilisateurs une fonctionnalité permettant de traduire et de connecter des publications de type publication personnalisées. Mais cela ne peut pas fonctionner s'ils sont liés à un thème, car un thème est toujours actif par site, et non sur l'ensemble du réseau. Les types de publications thématiques sont très difficiles à traduire.

Voir aussi: Où mettre mon code: plugin ou functions.php?

3
fuxia