wake-up-neo.com

Umschreiberegeln für benutzerdefinierten Beitragstyp funktionieren nicht. Wie kann die Umschreibereihenfolge geändert werden?

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.

custom-post-typesurl-rewritingrewrite-rules404-erroradd-rewrite-rule
3
Slam

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.

1
janh

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.

0
Slam