web-dev-qa-db-fra.com

Comment gérer une hiérarchie avec des types d'article personnalisés

Je me suis installé dans WordPress pendant quelques jours et j'ai été assez impressionné par toutes les fonctionnalités, plugins et thèmes disponibles. J'ai passé pas mal de temps à lire la documentation sur les thèmes et les types personnalisés. Jusqu'ici, tout va bien ... Maintenant que j'essaie de faire de vraies choses, il semble (mais il se peut que je manque quelque chose) que WP a quelques limitations sévères.

Je veux proposer un site ISV classique. Une hiérarchie typique serait:

  • Des produits
  • - Produit A
  • ---- Aperçu
  • ---- Historique des versions
  • ------- Version 1.5
  • ------- Version 1.4
  • ------- Version 1.3
  • ------- etc.
  • ---- Caractéristiques
  • ---- etc.
  • - Produit B
  • ---- Aperçu
  • Élément de liste
  • etc...

En mettant l'accent sur l'historique des versions, j'ai proposé:

  • un type de contenu personnalisé: "releases".
  • une taxonomie personnalisée pour spécifier le produit associé à une "version" spécifique.
  • J'ai créé un modèle pour afficher la liste des "communiqués".
  • Création d'un single-release.php pour afficher les détails d'une version.
  • Créé une page basée sur mon modèle.

L’URL de la page qui affiche la liste des "releases" s’intégrera dans la hiérarchie (/ products/product-a/release-history /). Cependant, l'URL du type de message personnalisé sera quelque chose comme: /% post_type% /% post_slug%/(c'est-à-dire:/releases/version 1.2 /

Je me bats pendant 2 jours pour essayer de trouver une solution permettant de proposer un schéma d'URL cohérent.

J'ai essayé d'utiliser le plugin Custom post permalinks pour créer une URL qui inclurait ma taxonomie personnalisée représentant le produit (mieux que rien, même si ce n'est pas parfait), mais pour une raison quelconque, le plugin ne fonctionne pas de mon côté.

Dans l’ensemble, à moins que quelque chose ne me manque, les types de messages personnalisés sonnent bien mais sont plutôt cauchemardesques si vous n’avez pas une structure plate. J'aurais certainement préféré un concept de type de contenu personnalisé qui ne dépend pas de l'URL ou un moyen simple de brancher un type de publication personnalisé à n'importe quel niveau de la hiérarchie des pages.

Cela dit, il se peut que je passe complètement à côté de la question. Quelqu'un a-t-il une idée ou une expérience lors de la création d'un site avec ce type de hiérarchie? Toute aide appréciée ...

[Mettre à jour]

Je ne sais pas exactement quelles sont les conventions lors de la mise à jour ici, mais je vais laisser le texte initial par souci de clarté. Le but de cette mise à jour est de clarifier et d'ajouter des détails supplémentaires.

Produits
Création d'une WP page "Produits" - pas de parent - URL: http: /// products /

Produit A (produit spécifique)
Création d'une WP page "Produit A" - parent: "Produits" - URL: http: /// products/product-a /

Vue d'ensemble
Création d'une WP page 'Overview' - parent: 'Product A' - URL: http: /// products/product-a/overview /

Communiqués (liste des communiqués du produit spécifique)
Création d'une WP page 'Quoi de neuf' - applique un modèle qui affiche une liste de toutes les versions disponibles (chaque version comporte un lien pour afficher les détails de cette version spécifique) - parent: ' Product A '- URL: http: /// products/product-a/product-releases /.
Les versions sont implémentées en utilisant un type personnalisé (voir ci-dessous). Il était donc très facile de mettre en œuvre le modèle et le lien pour libérer le permalien. Bien que je ne l'ait pas encore implémenté, mon idée était que le modèle afficherait la liste des versions pour tout produit basé sur une taxonomie (product-id) définie au niveau de la page. Je pourrais donc avoir une autre page utilisant le même modèle que celui qui afficherait les versions d'un autre produit en associant la taxonomie appropriée "id-produit" à cette autre page.

Release (détail d'une release)
Les versions sont implémentées en utilisant un type de publication personnalisé (appelons-le 'version du produit'). De plus, j'utilise une taxonomie personnalisée (product-id) pour attacher chaque version à un produit spécifique (évidemment, je ne souhaite pas créer un type de publication personnalisé pour les versions associées à un autre produit).
Création d'un fichier 'single-product-release.php' pour afficher une version spécifique. Le problème avec cette approche est qu’une version spécifique sera affichée avec l’URL suivante: http://<root>/product-releases/release-xx

  • Ce n'est pas vraiment descriptif, le moins que l'on puisse dire (je devrais au moins obtenir un identifiant de produit dans l'URL)
  • cela brise quelque peu la hiérarchie (bien que l'on puisse certainement se demander si c'est faux ou pas)

Mes options (autant que je sache en tant que débutant sur WordPress)

Débarrassez-vous du truc permalien
Je pourrais peut-être afficher les détails d'une version à l'aide d'un modèle et transmettre des arguments dans l'URL. Je pourrais utiliser ce modèle avec une page qui irait exactement là où je veux dans la hiérarchie.
Évidemment, ce n’est pas une approche que je suivrais ... pour de nombreuses raisons que je ne détaillerai pas ici (c’est déjà un long post/une question).

Trouver un moyen d'ajouter (ou plutôt de préfixer) ma valeur 'product-id' au permalink Custom Post Type
Nous pourrions avoir quelque chose comme http: /// product-a/product-releases/release-x. Je devrais accepter que les versions vivent un peu en dehors de la hiérarchie "naturelle", à savoir http: ///products/product-a/product-releases/release-x.
Je pourrais aller encore plus loin en préfixant "produits" - quelque chose comme:/products /% product-id% /% product-release% /. Cependant, je me demande si cette règle de réécriture ne serait pas incompatible avec les "pages" créées sous la page "produits" ...

Toute entrée appréciée.

[Mettre à jour]

J'ai mis en œuvre l'approche proposée par bobdiaes. Cela fonctionne bien pour mon type de contenu, mais cela va entrer en conflit avec les pages WP qui sont mélangées dans la hiérarchie. En utilisant un bout de code de bobdiaes, j’ai créé l’option Permaling suivante pour mon type de publication personnalisé de publication du produit:
/products/%product-id%/product-releases/%product-release%
Je disposerai donc de l'URL du produit approprié pour afficher les détails d'une version d'un produit spécifique. ie: /products/my-great-product/product-releases/release-1-5/

Cependant, je veux avoir quelques WP pages dans le mélange:

  • /products/my-great-product/ devrait fournir un aperçu du produit.
  • /products/my-great-product/product-releases/ devrait afficher la liste des versions et les détails de la dernière version.

Au début, il semble assez naturel de créer WP pages pour faire ce dont j'ai besoin. Je vais organiser ma hiérarchie de pages afin que les pages tiennent dans le schéma d'URL exact. Cependant, cette approche se heurtera à la réécriture d'URL utilisée pour le type de contenu personnalisé "version du produit" et je ne pourrai pas parcourir les pages (404).

Bien bien bien...

Alors, quelles sont mes options maintenant

Abandonne l'idée d'utiliser WP
Eh bien, je pense que je vais insister davantage. Outre ce problème, il y a beaucoup de choses à aimer avec WP.

Utiliser Pod CMS
Bien que je ne l’aie pas encore testé. Cela ressemble à un cadre/outil de Nice. Cependant, je perdrais la possibilité de traduire facilement mon contenu à l'aide de WPML.
Le fait qu’ils pourront utiliser des types de publication personnalisés plutôt que leur propre tableau dans la version 2.0 leur permettra certainement de s’appuyer sur les plugins actuels à des fins de traduction. Ce qu'ils préparent pour la version 2.0 semble intéressant. Ils pourront utiliser le type de message personnalisé au lieu de leurs propres tables.
Pod CMS 2.0 pourrait être LA SOLUTION .

Utilisation de WP pages au lieu d'un type de publication personnalisée "version du produit"
L’idée ici serait de créer une page pour chaque version du produit (avec la page des versions du produit en tant que parent). Je suppose qu'il doit être facile de parcourir les pages enfants pour afficher la liste des versions.
Évidemment, cela présente quelques inconvénients:

  • L’interface actuelle de la page d’administration peut ne pas être très pratique pour gérer des centaines de pages ...
  • Comme la page est déjà un type de publication personnalisé spécialisé (pour autant que je sache), je devrais me souvenir des champs personnalisés spécifiques dont j'ai besoin chaque fois que j'utilise une page comme un type de pseudo-contenu, à moins que je ne veuille créer tous les champs susceptibles de contenir. être nécessaire sur tout le site Web. Une solution assez horrible si vous me demandez.

Remplacez WP pages par un type de publication personnalisé
Pas sûr du conflit possible entre les règles de réécriture, mais voici l’idée. Plutôt que d'avoir une page d'aperçu, je pourrais créer un type de publication personnalisé "présentation du produit" et utiliser une règle de réécriture de lien permanent de la même manière que pour le type de publication personnalisé "publication du produit". Mettra à jour avec mes conclusions.

Je suis sûr que je ne suis pas le seul à faire face à cet enfer d'URL WordPress. Bien que je doive admettre que la généralisation d'un "message" dans un type de message personnalisé est assez astucieuse, les éléments du lien permanent sont assortis de leurs propres contraintes.

Un mot de prudence - étant nouveau avec WP, j'ai peut-être oublié quelque chose de tout à fait évident

[Mettre à jour]

Eh bien, aussi frustrant que cela puisse être, il semble que cela soit tout simplement impossible. Eh bien, il existe certainement une solution qui implique une réécriture d'URL délicate, mais certainement rien de trivial pour une approche qui est cependant assez courante.
Fondamentalement, je pense qu’à ce stade, il convient de se lier à un schéma d’URL plutôt simple. Je vais essayer le forum wordpress, mais je n'ai pas beaucoup d'espoir.

custom-post-typespermalinkshierarchical
5
Frederic L

Lors de la planification de sites Wordpress plus complexes, j'essaie de penser à la hiérarchie page/url en termes de valeur par défaut WordPress Database Schema . Déterminez ensuite le meilleur réécriture d'URL schéma et structure de données. De manière très générale, j'estime que les objets de données les plus importants pour l'utilisateur doivent exister sous la forme d'un type de publication personnalisé ou d'un objet de publication, que les relations entre publications personnalisées doivent utiliser des taxonomies personnalisées et que les valeurs uniques doivent être stockées dans postmeta.

Plus précisément , si je proposais des produits avec des mises à jour de version, je pourrais créer un type d'article personnalisé pour chaque produit (en supposant un nombre limité de produits avec mises à jour de version) et créer un nouvel article pour chaque nouvelle version ( WP stocke les publications chronologiquement par défaut, de sorte que plusieurs versions devraient bien fonctionner). En d'autres termes, chaque nouvelle version existerait sous la forme d'une publication unique sous le type d'article personnalisé et chaque nouvelle publication contiendrait les détails de cette version. Vous pouvez ensuite afficher les détails de la publication la plus récente sur une page pour le type de publication personnalisée. En forçant chaque publication à être paginée, vous devriez également pouvoir avoir des URL séparées pour fonctionnalités, etc., et vous devriez pouvoir les rendre jolies en réécrivant l'URL.

visuellement :

/products/%custom-post-type%/
/products/product-a/

/products/%custom-post-type%/archive/
/products/product-a/releases/

/products/%custom-post-type%/%post-name%/
/products/product-a/release-xx/

/products/%custom-post-type%/%post-name%/page/2/
/products/product-a/release-xx/features/
3
joelhaus

Je pense que vous devez vous accrocher à la fonction get_permalink (). Cet article que j'ai sauvegardé dans mes notes de type de message personnalisé peut être utile: http://shibashake.com/wordpress-theme/add-custom-taxonomy-tags-to-your-wordpress-permalinks

0
bobdiaes