Ich habe vier oder fünf Codex-Seiten, ein Dutzend Stackexchange-Seiten und vier oder fünf Entwickler-Blogs durchgesehen, um dieses Problem zu lösen.
Ich habe einen benutzerdefinierten Beitragstyp namens "Autoren". Das CPT ist korrekt eingerichtet, ich habe das CPT-Framework aus dem Codex gezogen und es mit einem CPT-Generator verglichen. In den Admin-Bildschirmen werden Autorenbeiträge korrekt erstellt, bearbeitet und aufgelistet, und die URLs haben das richtige Format von example.com/author/post_name/
. Autorenarchive funktionieren auch.
Aber nichts, was ich tue, wird diese Seite im Frontend anzeigen. Es ist nichts als 404s.
Ich habe das Rewrite ein Dutzend Mal über die Permalinks-Seite und die WP-CLI gespült. Ich habe auch Custom Post Type Permalinks installiert und habe das gleiche Problem.
CPT ist hier:
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 );
}
Ich habe das Query Monitor-Plugin installiert und es teilt mir mit, dass die folgenden Umschreibungen übereinstimmen.
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]
Die zweite Abfrage ^author/([^/]*)/?
ist eine, die ich mit folgendem Befehl geschrieben habe:
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);
Die oberste Abfrage scheint jedoch zuerst abgeglichen zu werden, weshalb ich 404-Werte erhalte. Der Abfragemonitor zeigt die generierte Abfrage als name=catherine-collins&post_type=post
an, wenn sie name=catherine-collins &post_type=author
sein sollte.
Woher kommt diese Abfrage und wie stufe ich sie herab? Es gibt keinen anderen add_rewrite_rule
irgendwo in meinem Theme oder in irgendeinem Plugin, also schätze ich, dass dies der Kern ist. Das Theme ist Twenty-Seventeen mit meinem eigenen Plugin, das verschiedene Custom Post Types definiert.
Obwohl Sie das Problem bereits gefunden haben, finden Sie hier einen grundlegenden Code, um eine bestimmte Regel mit dem Filter rewrite_rules_array an das Ende der Umschreiberegeln zu verschieben, damit Benutzer auf ein ähnliches Problem stoßen.
Angenommen, ich möchte die Regel für ([^/]*)/([^/]*)/?$
verschieben:
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;
});
Beachten Sie, dass Sie die Regeln leeren/aktualisieren müssen, damit dies Auswirkungen hat. Das Speichern Ihrer Permalinks-Konfiguration im Backend reicht aus, um dies zu erreichen.
Ja, es war doch ein Benutzerfehler.
Vor Monaten hatte ich mit Yeost experimentiert und eine rewrite_rules_array is functions.php hinzugefügt. Es hatte Priorität vor der add_rewrite_rule. Nachdem ich das gelöscht hatte, funktionierten benutzerdefinierte Beitragstypen normal.
Hier ist der beleidigende Code:
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;
}
Dies wurde behoben, indem Atom eine nicht grep-bezogene Suche nach '([^/]*)/([^/]*)/?$'
für den gesamten Site-Ordner durchführte.