J'ai parcouru quatre ou cinq pages du Codex, une douzaine de pages Stackexchange et quatre ou cinq blogs de développeurs essayant de résoudre ce problème.
J'ai un type de message personnalisé appelé auteurs. Le CPT est configuré correctement, j'ai extrait le framework CPT du Codex et je l'ai vérifié par rapport à un générateur CPT. Les écrans d’administrateur créent, modifient et répertorient correctement les publications d’auteur, et les URL ont le format correct example.com/author/post_name/
. Les archives des auteurs fonctionnent également.
Mais rien de ce que je fais ne pourra afficher cette page au recto. Ce n'est rien mais 404s.
J'ai vidé la réécriture une douzaine de fois via la page Permalinks et WP-CLI. J'ai également installé des permaliens de type message personnalisé et ai le même problème.
Le CPT est ici:
add_action( 'init', 'to4_cpt_author' );
function to4_cpt_author() {
$labels = array(
'name' => _x( 'Authors', 'post type general name' ),
'singular_name' => _x( 'Author', 'post type singular name' ),
'menu_name' => _x( 'Authors', 'admin menu' ),
'name_admin_bar' => _x( 'Author', 'add new on admin bar' ),
'add_new' => _x( 'Add New', 'author' ),
'add_new_item' => __( 'Add New Author' ),
'new_item' => __( 'New Author' ),
'edit_item' => __( 'Edit Author' ),
'view_item' => __( 'View Author' ),
'all_items' => __( 'All Authors' ),
'search_items' => __( 'Search Authors' ),
'parent_item_colon' => __( 'Parent Authors:' ),
'not_found' => __( 'No authors found.' ),
'not_found_in_trash' => __( 'No authors found in Trash.' )
);
$args = array(
'labels' => $labels,
'description' => __( 'Author post type.' ),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => 'author',
'rewrite' => array('slug' => 'author', 'with_front' => true ),
'capability_type' => 'post',
'has_archive' => true,
'hierarchical' => false,
'menu_position' => 9,
'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ),
'taxonomies' => array( 'admin_tag', 'post_tag' ),
'menu_icon' => 'dashicons-id-alt'
);
register_post_type( 'author', $args );
}
J'ai installé le plug-in Query Monitor et il me dit que les réécritures suivantes correspondent.
All Matching Rewrite Rules
Rule Query
([^/]*)/([^/]*)/?$ post_type=post
&name=$matches[2]
&meta=$matches[1]
^author/([^/]*)/? post_type=author
&name=$matches[1]
author/([^/]+)(?:/([0-9]+))?/?$ author=$matches[1]
&page=$matches[2]
(.?.+?)(?:/([0-9]+))?/?$ pagename=$matches[1]
&page=$matches[2]
La deuxième requête ^author/([^/]*)/?
est celle que j’ai écrite en utilisant:
function to4_rewrite_rule() {
add_rewrite_rule( '^author/([^/]*)/?', 'index.php?post_type=author&name=$matches[1]','top' );
}
add_action('init', 'to4_rewrite_rule', 10, 0);
Mais la première requête semble être mise en correspondance en premier, c'est pourquoi je reçois 404. Le Moniteur de requêtes affiche la requête générée sous la forme name=catherine-collins&post_type=post
alors qu'elle devrait être name=catherine-collins &post_type=author
D'où vient cette requête et comment puis-je la rétrograder? Il n'y a pas d'autre add_rewrite_rule
dans mon thème ni dans aucun plugin, alors je suppose que c'est fondamental. Le thème est vingt-dix-sept avec mon propre plugin personnalisé définissant plusieurs types de publication personnalisés.
Bien que vous ayez déjà trouvé le problème, voici un code de base permettant de déplacer une règle spécifique à la fin des règles de réécriture avec le filtre rewrite_rules_array pour les personnes rencontrant un problème similaire.
Dites que je veux déplacer la règle pour ([^/]*)/([^/]*)/?$
:
add_filter("rewrite_rules_array", function($rules) {
$keys = array_keys($rules);
foreach($keys as $rule) {
if($rule == '([^/]*)/([^/]*)/?$') {
$value = $rules[$rule];
unset($rules[$rule]);
$rules[$rule] = $value;
break;
}
}
return $rules;
});
Notez que vous devrez vider/mettre à jour les règles pour que cela ait un effet. L'enregistrement de la configuration de vos permaliens dans le backend suffit pour cela.
Oui, donc c'était une erreur de l'utilisateur après tout.
Il y a quelques mois, j'avais expérimenté Yeost et ajouté un rewrite_rules_array is functions.php. C'était prioritaire sur add_rewrite_rule. Une fois que j'ai supprimé cela, les types de messages personnalisés fonctionnaient normalement.
Voici le code incriminé:
add_filter( 'rewrite_rules_array', 'my_rewrite_rules_array');
function my_rewrite_rules_array($rules) {
$rules = array('([^/]*)/([^/]*)/?$' => 'index.php?post_type=post&name=$matches[2]&meta=$matches[1]') + $rules;
return $rules;
}
Ce problème a été résolu en utilisant Atom pour effectuer une recherche non-grep de '([^/]*)/([^/]*)/?$'
sur tout le dossier du site.