web-dev-qa-db-fra.com

Permaliens: structure personnalisée pour la taxonomie - balises?

Dans mes paramètres de permalien Wordpress, j'ai défini le Tag-Base sur "". Donc, /tag/whatever est la structure d'url courante pour ma page de balise.

Cependant, j'ai un custom-post-type avec un custom-taxonomy qui l'utilise également comme rewrite_slug.

register_taxonomy(
        'event_tags',
        'wr_event',
        array(
            'label' => 'Tags',
            'singular_label' => 'Tag',
            'hierarchical' => false,
            'query_var' => true,
            'rewrite' => array('slug' => 'tag'),
        )
    );

Cela signifie que les deux (balises pour les publications normales et les balises pour mon type de publication personnalisé) doivent avoir la même structure de permalien pour leurs balises.

Cependant, cela ne fonctionne pas. Lorsque je règle également la variable rewrite- slug de ma taxonomie personnalisée sur "balise", l'archive normale des balises-archives pour les articles de blog génère un 404.

Je sais que je pourrais facilement résoudre ce problème en utilisant simplement deux bases de réécriture différentes pour les deux types. Cependant, je me demande s’il est possible de faire en sorte que cela fonctionne également. Ainsi, les balises normales des articles de blog et les balises de mon type de message personnalisé ont la même structure de réécriture.

Des idées à ce sujet?

1
mathiregister

Si vous vous connectez au filtre 'rewrite_rules_array', effectuez un print_r on $ rules et vous verrez les énormes paires clé-valeur preg-match.

add_filter( 'rewrite_rules_array','mess_with_rewrite_rules' );
function mess_with_rewrite_rules( $rules ) {
        print_pre($rules);
    return $rules;
}

Voyez où se trouve votre règle dans la pile. WordPress parcourt cette liste en cherchant tout ce qui correspond aux clés, qui sont des motifs regex, et applique les valeurs capturées à la valeur associée via un preg_match (). Je ne sais pas avec certitude, mais je soupçonne que lors du premier match, il cesse de chercher. Donc, si les tags dans le sens post_tag, il cesse de regarder. C’est probablement pourquoi cela n’atteint pas le vôtre.

Si je me trompe, cela signifie que WordPress n’arrête pas de chercher, mais je doute que ce soit le cas. Comme la balise n'existe pas dans votre taxonomie post_tag, elle renvoie 404. Essayez de définir un terme dans post_tags avec le même slug et voyez si vous finissez par atterrir sur ce terme.

Je ne pense pas qu'il y ait un moyen de faire ce que vous demandez. Le seul moyen pour WordPress de savoir ce que vous recherchez via l’URI est le modèle du lien permanent. Si vous avez deux choses avec le même motif, il n'y a aucune information pour les différencier.

Solution A: Utilisez plutôt une taxonomie hiérarchique. Transformez les étiquettes en une taxonomie hiérarchique pouvant contenir les deux ensembles de termes. Le principal problème que je soupçonne alors serait l'interface utilisateur. En rendant les posts_tags hiérarchiques, la métabox basculera vers la liste des cases à cocher de style catégorie. Si vous souhaitez conserver la structure de balise non hiérarchique, vous aurez probablement besoin de créer une métabox personnalisée pour ne contenir que les enfants de 'event_tags' et une autre pour tous les autres.

Solution B: Modifiez quelque chose à propos de votre modèle 'event_tags'. Par exemple, vous pouvez par exemple avoir/tag/events /. Ensuite, vous insérez un modèle spécial pour rechercher /tag/events/(.+?)$%i. En l'insérant en haut du tableau de règles de réécriture, il correspond en premier et cesse de regarder. Vous pouvez ensuite appliquer le terme correspondant à index.php?taxonomy=event_tags&term_slug=$matches[1]. Cela fonctionnerait, mais cela briserait n'importe quel post_tag dont le slug se trouvait être 'événements'.

Note: Je ne sais pas si term_slug est la bonne variable de requête, je devine en quelque sorte. Regardez cela en regardant le tableau de règles de réécriture et en trouvant un exemple d'autres utilisations des taxonomies personnalisées.

0
eddiemoya