web-dev-qa-db-fra.com

Pourquoi un type d'article personnalisé a-t-il besoin du paramètre d'arguments '' hiérarchique ''?

J'ai du mal à comprendre certaines choses sur les TPC et je pourrais le faire avec de l'aide. Je peux voir que les taxonomies doivent souvent être hiérarchiques, mais je ne vois pas comment/quand un type de message personnalisé serait?

c'est-à-dire que j'ai un CPT appelé 'projets'. Une taxonomie est enregistrée pour ce type de post appelé "champs". Sous "champs", j'ai beaucoup de sous-éléments comme:

  • 'Documentaires'
  • 'Documentaires'> 'Self Commisions'
  • 'Documentaires'> 'Classique'
  • 'Entreprise'
  • 'Corporate'> 'Marketing numérique'
  • etc...

Donc, pour voir un projet dans 'Documentaires'> 'Classique', j'utilise l'URL suivante: mydomain.com/field/classic/

C’est là que j’ai en fait environ 30 questions :) mais je vais simplement poser les deux questions les plus pressantes:

  1. Pourquoi et comment le CPT "projets" serait-il jamais hiérarchisé?
  2. Est-il possible d'afficher les éléments dans le champ "classique" comme suit: mydomain.com/projects/classic (mydomain.com/projects affiche tous les éléments, mais le détail des forages le casse)

Toute aide appréciée, j'ai passé environ 3 heures à jouer avec cela et à lire et je n'arrive pas à comprendre!

Merci!

Ci-dessous mon code (recadré) pour référence:

function register_cpt_projects() {
$labels = array(
    'name' => _x('Projects', 'projects'),
    // all other labels etc..
);

$args = array(
    'labels' => $labels,
    'hierarchical' => true,
    'supports' => array('title', 'editor', 'author', 'thumbnail'),
    'taxonomies' => array('field'),
    'public' => true,
    'show_ui' => true,
    'show_in_menu' => true,
    'show_in_nav_menus' => true,
    'publicly_queryable' => true,
    'exclude_from_search' => false,
    'has_archive' => true,
    'query_var' => true,
    'can_export' => true,
    'rewrite' => true,
    'capability_type' => 'post'
);
register_post_type('projects', $args);
}

add_action('init', 'register_cpt_projects');

function create_projects_tax(){
    register_taxonomy('field', 'projects', array(
       'hierarchical' => true,
       'label' => 'Fields'
    ));
}
add_action('init', 'create_projects_tax');
3
Mere Development

Lorsque vous avez deux objets de contenu avec une interface similaire ou des propriétés partagées, vous avez un bon candidat pour les types de publication hiérarchiques.

Prenons places à titre d'exemple (voir cette réponse ):

  • Asie
  • L'Europe 
    • Allemagne
      • Berlin
    • L'Autriche
      • Vienne

Chaque place a des métadonnées similaires: population, coordonnées géographiques, langues parlées. Vous pouvez simplement réutiliser la même interface.

De plus, si vous créez un type de publication personnalisé distinct pour chaque type d’emplacement, vous rencontrerez WordPress ’ table de relations manquante entre publications .

3
fuxia

Un type de publication personnalisé nécessite uniquement le paramètre hiérarchique si vous souhaitez que le type de publication se comporte comme des pages.

Si vous voulez pouvoir choisir un parent et disposer de la commande de menu metabox, vous devez également ajouter 'page-attributs' au tableau de supports.

L'argument hierarchical vous permet également de traiter des types d'article hiérarchique différents des autres en utilisant la balise conditionnelle is_post_type_hierarchical(). Il prend en charge l'objet de publication, le nom du type de publication ou l'ID de publication en tant que paramètre unique.

Est-il possible d'afficher les éléments dans le champ "classique" comme suit: mydomain.com/projects/classic (mydomain.com/projects affiche tous les éléments, mais le détail des forages le casse)

Vous pouvez utiliser l’argument rewrite pour définir l’apparence des URL de type publication unique:

slug: la slug avec laquelle vous souhaitez préfixer vos publications.
with_front: Indique si votre type de publication doit utiliser la base avant à partir de vos paramètres de permalien.

'rewrite' => array( 'slug' => 'classic', 'with_front' => false ),

rendrait vos urls pour les articles d'un seul projet ressemblant à ceci:

yoursite.com/classic/post-name

Si vous souhaitez définir les URL de vos archives: mydomain.com/projects/classic, vous devez appliquer des règles de réécriture similaires à vos arguments register_taxonomy.

Vous devez définir le slug de réécriture sur les projets et with_front sur false. A noter également que le tableau de réinscription register_taxonomy prend également en charge: 'hierarchical' - true or false allow hierarchical urls Ceci vous permet d’utiliser la hiérarchie complète des termes de taxonomie dans vos URL:

3
Chris_O