Est-ce un problème d'avoir une taxonomie personnalisée et un type d'article personnalisé qui utilise la même structure de réécriture?
J'ai une taxonomie personnalisée people
et une publication personnalisée de type people_bio
. L'idée est que vous obteniez une liste de messages sur une personne avec une courte biographie en haut de la page. Je les combine dans mon fichier de modèle taxonomy-people.php
. Le permalien est /people/[person-slug]
.
La taxonomie personnalisée et le type de publication personnalisé ont tous les deux l'argument rewrite
à array('slug' => 'people')
. Cela semble fonctionner: get_term_link('seth-godin', 'people')
renvoie /people/seth-godin/
et, pour un type de publication personnalisé avec slug seth-godin
, get_permalink()
renvoie également /people/seth-godin/
. La taxonomie est définie en premier, et il semble "gagner": sur une page /people/[slug]
, is_tax()
est vrai, alors que is_single()
est faux.
Donc, ça marche, mais je ne me sens pas à l'aise avec ça. Quelqu'un a-t-il plus d'expérience avec le moteur de réécriture et pouvez-vous me dire s'il risque de casser autre chose?
La partie pertinente du fichier de plug-in, appelée dans l'action init
:
register_taxonomy(
'people',
'post',
array(
'labels' => array(
'name' => 'People',
'singular_name' => 'Person',
'search_items' => 'Search people',
'popular_items' => 'Popular people',
'all_items' => 'All people',
'parent_item' => null,
'parent_item_colon' => null,
'edit_item' => 'Edit person',
'update_item' => 'Update person',
'add_new_item' => 'Add person',
'new_item_name' => 'New person',
'separate_items_with_commas' => 'Separate people with commas',
'add_or_remove_items' => 'Add or remove people',
'choose_from_most_used' => 'Choose from the most used people',
),
'public' => true,
'show_ui' => true,
'show_tagcloud' => true,
'hierarchical' => false,
'update_count_callback' => '',
'rewrite' => array(
'slug' => 'people',
'with_front' => true,
),
'query_var' => 'people',
'capabilities' => array(),
'show_in_nav_menus' => true,
)
);
register_post_type(
'people_bio',
array(
'label' => 'People Bio',
'labels' => array(
'name' => 'Biographies',
'singular_name' => 'Biography',
'add_new' => 'Add new',
'add_new_item' => 'Add new biography',
'edit_item' => 'Edit biography',
'new_item' => 'New biography',
'view_item' => 'View biography',
'search_items' => 'Search biographies',
'not_found' => 'No biographies found',
'not_found_in_trash' => 'No biographies found in trash',
'parent_item_colon' => null,
),
'description' => 'Biography pages of interesting people',
'public' => true,
'exclude_from_search' => true,
'publicly_queryable' => true,
'show_ui' => true,
'menu_position' => null,
'menu_icon' => null,
'capability_type' => 'post',
'capabilities' => array(),
'hierarchical' => false,
'supports' => array(
'title',
'editor',
//'author',
'thumbnail',
'excerpt',
//'trackbacks',
'custom-fields',
//'comments',
//'revisions',
//'page-attributes',
),
'register_meta_box_cb' => null,
'taxonomies' => array(),
'permalink_epmask' => EP_PERMALINK,
//'rewrite' => false,
'rewrite' => array(
'slug' => 'people',
'with_front' => true,
),
'query_var' => true,
'can_export' => true,
'show_in_nav_menus' => true,
)
);
register_taxonomy_for_object_type('people', 'people_bio');
(j'utilise toujours tous les paramètres avec register_*()
, beaucoup avec leurs valeurs par défaut, comme documentation supplémentaire, tant que le Codex n'est pas à jour)
Le fichier modèle taxonomy-people.php
:
<?php
get_header();
$people_biography = get_posts(array(
'numberposts' => -1,
'post_type' => 'people_bio',
'taxonomy' => 'people',
'term' => $wp_query->get_queried_object()->slug,
));
?>
<div class="container_24">
<div class="grid_18" id="content" role="main">
<?php if ($people_biography) :
foreach ($people_biography as $bio) : ?>
<h1><?php echo get_the_title($bio->ID); ?></h1>
<?php
echo get_the_post_thumbnail($bio->ID);
echo apply_filters('the_content', $bio->post_content); ?>
<?php
endforeach;
else: ?>
<h1><?php esc_html_e($wp_query->get_queried_object()->name); ?></h1>
<?php endif; ?>
<?php get_template_part( 'loop', 'archive' ); ?>
</div><!-- .content -->
<div class="grid_6" id="default_sidebar">
<?php dynamic_sidebar('default-sidebar'); ?>
</div><!-- #default_sidebar -->
</div><!-- .container_24 -->
<div class="clear"></div>
<?php
get_footer();
?>
La sortie de mon Rewrite Analyzer semble me dire que la taxonomie "gagne" pour les pages de taxonomie régulières (ce que j'ai remarqué), mais le type de publication personnalisé récupère toutes les autres URL (y compris les secondes pages, les flux, ...). C’est ce dont j’avais peur et que je devrai approfondir.
Oui, cela donnera des problèmes. Les quatre règles de réécriture générées par la taxonomie personnalisée sont également utilisées par le type de publication personnalisé. Celui que vous enregistrez en premier est écrasé par celui que vous enregistrez par la suite. En fonction de la configuration exacte (hiérarchique ou non hiérarchique), des règles similaires peuvent se retrouver dans la liste finale des règles de réécriture, mais seul le premier "gagne".
Cela peut avoir pour effet que /people/seth-godin/
interroge une taxonomie personnalisée, mais /people/seth-godin/page/2/
interroge un type de publication personnalisé.
Question: Est-ce un problème d’avoir une taxonomie personnalisée et un type de publication personnalisé qui utilise la même structure de réécriture?
Réponse: oui.
S'ils partagent exactement la même structure, vous obtiendrez une situation de concurrence critique, de sorte que l'une d'elles ne fonctionnera pas. Mais je suppose que votre scénario ne conduit pas automatiquement aux mêmes règles de réécriture car les deux éléments sont préfixés différemment.
Cela est dû au fait que les règles de réécriture de permastructure (qui incluent celles créées en enregistrant post_types et taxonomies) sont exécutées via array_merge (). Array_merge remplacera toutes les règles rewrite par le même regex à l'emplacement actuel du tableau, mais ajoutera celles qui ne seront pas en conflit à la fin du tableau.
Votre meilleure option peut être de définir l'argument 'rewrite' sur false pour l'un des deux enregistrements et d'ajouter du code séparé pour ajouter les règles de réécriture nécessaires manquantes à rewrite_rules_top.