Entfernen Sie Slugs aus benutzerdefinierten Beitragstyp-Beitrags-URLs


48

Es scheint, dass alle Webressourcen, die auf dem Thema des Entfernens eines benutzerdefinierten Beitragstyps basieren, z

yourdomain.com/CPT-SLUG/post-name 

Inzwischen sind Lösungen sehr veraltet, die häufig auf vor WP 3.5 installierte Versionen verweisen. Eine übliche ist:

'rewrite'   => array( 'slug' => false, 'with_front' => false ),  

innerhalb Ihrer register_post_type Funktion. Das funktioniert nicht mehr und ist irreführend. Also frage ich die Community im 3. Quartal 2018 am Rande von WordPress 5 ...

Was sind die modernen und effizienten Möglichkeiten, um den Post Type Slug aus der URL eines benutzerdefinierten Post Type-Posts innerhalb des Rewrite-Arguments oder irgendwo anders zu entfernen?

UPDATE: Es scheint verschiedene Möglichkeiten zu geben, dies zu erzwingen, um mit regulären Ausdrücken zu arbeiten. Insbesondere die Antwort von Jan Beck, falls Sie beständig bereit sind, die Erstellung von Inhalten zu überwachen, um sicherzustellen, dass keine widersprüchlichen Seiten- / Post-Namen erstellt werden . Beides als Option / Hook beim Erstellen eines CPT oder eines erweiterten Optionssatzes für Permalinks. Bitte unterstützen Sie das Track-Ticket.

Fußnote: Bitte unterstützen Sie dieses Trac-Ticket, indem Sie es ansehen / bewerben: https://core.trac.wordpress.org/ticket/34136#ticket


Ich schätze, ich kratzte mir am Kopf, warum du das machen willst. Verwirrt.
Michael Ecklund

3
@MichaelEcklund, da jeder CPT, der zum Erstellen öffentlich zugänglicher Webseiten verwendet wird, einen erzwungenen Slug-Namen in der URL hat. Es gibt tatsächlich viele wp-Entwickler, die versuchen, die Schnecke sicher zu entfernen.
Ben Racicot

Antworten:


60

Der folgende Code funktioniert, aber Sie müssen nur bedenken, dass Konflikte leicht auftreten können, wenn der Slug für Ihren benutzerdefinierten Post-Typ mit dem einer Seite oder des Slugs eines Posts identisch ist ...

Zuerst entfernen wir den Slug aus dem Permalink:

function na_remove_slug( $post_link, $post, $leavename ) {

    if ( 'events' != $post->post_type || 'publish' != $post->post_status ) {
        return $post_link;
    }

    $post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );

    return $post_link;
}
add_filter( 'post_type_link', 'na_remove_slug', 10, 3 );

Nur die Schnecke zu entfernen ist nicht genug. Im Moment erhalten Sie eine 404-Seite, da WordPress nur erwartet, dass sich Posts und Seiten so verhalten. Sie müssen außerdem Folgendes hinzufügen:

function na_parse_request( $query ) {

    if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
        return;
    }

    if ( ! empty( $query->query['name'] ) ) {
        $query->set( 'post_type', array( 'post', 'events', 'page' ) );
    }
}
add_action( 'pre_get_posts', 'na_parse_request' );

Ändern Sie einfach "Ereignisse" in Ihren benutzerdefinierten Beitragstyp und schon kann es losgehen. Möglicherweise müssen Sie Ihre Permalinks aktualisieren.


Vielen Dank. Denken Sie, dass dies besser ist, als die Umschreibungen manuell zu erstellen? Ich habe diese Lösung gesehen und sie könnte die von Ihnen erwähnten Konflikte in Schach halten.
Ben Racicot

1
Es scheitert mit Nginx an der Bedingung 2 != count( $query->query ). Mit nginx können Sie $ query-> query as haben array('page' => '', 'name' => '...', 'q' => '...'). Also @NateAllen, was ist die Bedeutung dieser Bedingung?
Fabio Montefuscolo

3
Wir brauchen etwas Besseres. Unterstützung für das Entfernen des integrierten Slugs, damit später keine widersprüchlichen URLs erstellt werden können. Die Art und Weise, wie normale Beiträge und Seiten ihre URLs erstellen.
Ben Racicot

3
Bin es nur ich oder unterbricht dies einige WordPress-bedingte Tags wie is_single () und is_singular ()?
Rob-Gordon

1
Diese Lösung verursachte leider einige defekte Links und mein Blog zeigte keine Beiträge mehr und war nur eine normale Seite. Unten sehen Sie eine bessere Lösung von Matt Keys.
Radley Sustaire

20

Schreiben Sie den folgenden Code in die Taxonomie-Registrierung.

'rewrite' => [
  'slug' => '/',
  'with_front' => false
]

Das Wichtigste, was Sie nach einer Codeänderung tun müssen

Nachdem Sie Ihr benutzerdefiniertes Taxonomiedokument für den Beitragstyp geändert haben, gehen Sie zu Einstellungen> Permalinks und speichern Sie Ihre Einstellungen erneut . Andernfalls wird die Seite 404 nicht gefunden.

Überprüfen Sie hier die beste Lösung: http://www.krazzycodes.com/how-to-remove-custom-post-type-taxonomy-base-from-url-in-wordpress/


Das funktioniert tatsächlich, ich weiß nicht, wie das vorher noch niemand bemerkt hat. Natürlich kann dies andere Seiten stören, wenn sie denselben Permalink haben, aber wenn dies nicht der Fall ist, ist dies eine großartige Lösung.
Aleksandar

4
Versuchte dies heraus. Es gibt das gewünschte Ergebnis für meine benutzerdefinierten Posttyp-Links. Es "fängt" jedoch alle POST- oder PAGE-Post-Typ-Slugs ab und versucht, sie als URL für meinen benutzerdefinierten Post-Typ aufzulösen, dann 404s. (Ja, ich habe Permalinks gespeichert).
Matt Keys

4
Das geht nicht. Gibt 404, auch wenn Sie Permalinks aktualisiert haben.
Christine Cooper

3
Auch nach dem erneuten Speichern der Permalink-Einstellungen funktionieren Posts und Seiten nicht mehr (404)
amklose

1
Diese Lösung dient zum Entfernen des Slugs aus der URL. Aber die Archivseiten funktionieren nicht mehr.
Annapurna

13

Ich habe vor nicht allzu langer Zeit versucht, das herauszufinden, und die kurze Antwort von dem, was ich weiß, ist nein . Zumindest nicht innerhalb des Rewrite-Arguments.

Die lange Erklärung wird deutlich, wenn Sie sich den tatsächlichen Code register_post_typein wp-includes / post.php Zeile 1454 ansehen :

add_permastruct( $post_type, "{$args->rewrite['slug']}/%$post_type%", $permastruct_args );

Sie können die Präfixe $args->rewrite['slug']vor dem %$post_type%Umschreibetag sehen. Man könnte denken "Lass uns einfach die Schnecke auf nulldann stellen", bis du ein paar Zeilen nachschaust:

if ( empty( $args->rewrite['slug'] ) )
    $args->rewrite['slug'] = $post_type;

Sie können sehen, dass die Funktion immer einen Slug-Wert erwartet, der nicht leer ist und ansonsten den Post-Typ verwendet.


Vielen Dank an JanBeck. Gibt es einen wichtigen Grund dafür? Warum nicht diese Kerndatei mit einer Bedingung hacken, um bestimmte Beitragstypen aus dieser Regel herauszulassen?
Ben Racicot

9
Sie sollten die Antwort an Jan Beck vergeben. WordPress benötigt den post_type-Slug, um Anforderungen ordnungsgemäß weiterzuleiten. Diese Regel verhindert Namenskonflikte zwischen nativen WP-Seiten (die ohne Slug gerendert werden) und benutzerdefinierten Beitragstypen. Wenn Sie den Slug-Out hacken, wird WordPress den Unterschied zwischen einer Seite mit dem Namen "Picknick" und einem Ereignis (benutzerdefinierter Beitragstyp) mit dem Namen "Picknick" nicht erkennen.
Dswebsme

3
@dswebsme Einverstanden, aber es gibt Situationen, in denen Sie die URL unbedingt ändern müssen. Also abgesehen davon, warum Sie nicht von Haus aus können und sollten, wie machen Sie das so effizient?
Ben Racicot

7

Als Antwort auf meine vorherige Antwort : Sie könnten natürlich den rewriteParameter auf setzen, falsewenn Sie einen neuen Beitragstyp registrieren, und die Umschreiberegeln selbst so handhaben

<?php
function wpsx203951_custom_init() {

    $post_type = 'event';
    $args = (object) array(
        'public'      => true,
        'label'       => 'Events',
        'rewrite'     => false, // always set this to false
        'has_archive' => true
    );
    register_post_type( $post_type, $args );

    // these are your actual rewrite arguments
    $args->rewrite = array(
        'slug' => 'calendar'
    );

    // everything what follows is from the register_post_type function
    if ( is_admin() || '' != get_option( 'permalink_structure' ) ) {

        if ( ! is_array( $args->rewrite ) )
            $args->rewrite = array();
        if ( empty( $args->rewrite['slug'] ) )
            $args->rewrite['slug'] = $post_type;
        if ( ! isset( $args->rewrite['with_front'] ) )
            $args->rewrite['with_front'] = true;
        if ( ! isset( $args->rewrite['pages'] ) )
            $args->rewrite['pages'] = true;
        if ( ! isset( $args->rewrite['feeds'] ) || ! $args->has_archive )
            $args->rewrite['feeds'] = (bool) $args->has_archive;
        if ( ! isset( $args->rewrite['ep_mask'] ) ) {
            if ( isset( $args->permalink_epmask ) )
                $args->rewrite['ep_mask'] = $args->permalink_epmask;
            else
                $args->rewrite['ep_mask'] = EP_PERMALINK;
        }

        if ( $args->hierarchical )
            add_rewrite_tag( "%$post_type%", '(.+?)', $args->query_var ? "{$args->query_var}=" : "post_type=$post_type&pagename=" );
        else
            add_rewrite_tag( "%$post_type%", '([^/]+)', $args->query_var ? "{$args->query_var}=" : "post_type=$post_type&name=" );

        if ( $args->has_archive ) {
            $archive_slug = $args->has_archive === true ? $args->rewrite['slug'] : $args->has_archive;
            if ( $args->rewrite['with_front'] )
                $archive_slug = substr( $wp_rewrite->front, 1 ) . $archive_slug;
            else
                $archive_slug = $wp_rewrite->root . $archive_slug;

            add_rewrite_rule( "{$archive_slug}/?$", "index.php?post_type=$post_type", 'top' );
            if ( $args->rewrite['feeds'] && $wp_rewrite->feeds ) {
                $feeds = '(' . trim( implode( '|', $wp_rewrite->feeds ) ) . ')';
                add_rewrite_rule( "{$archive_slug}/feed/$feeds/?$", "index.php?post_type=$post_type" . '&feed=$matches[1]', 'top' );
                add_rewrite_rule( "{$archive_slug}/$feeds/?$", "index.php?post_type=$post_type" . '&feed=$matches[1]', 'top' );
            }
            if ( $args->rewrite['pages'] )
                add_rewrite_rule( "{$archive_slug}/{$wp_rewrite->pagination_base}/([0-9]{1,})/?$", "index.php?post_type=$post_type" . '&paged=$matches[1]', 'top' );
        }

        $permastruct_args = $args->rewrite;
        $permastruct_args['feed'] = $permastruct_args['feeds'];
        add_permastruct( $post_type, "%$post_type%", $permastruct_args );
    }
}
add_action( 'init', 'wpsx203951_custom_init' );

Sie können sehen, dass der add_permastructAnruf den Slug jetzt nicht mehr enthält. Ich habe zwei Szenarien getestet:

  1. Wenn ich eine Seite mit dem Slug "calendar" erstellt habe, wird diese Seite durch das Archiv des Post-Typs überschrieben, das auch den Slug "calendar" verwendet.

Bildbeschreibung hier eingeben

  1. Wenn ich eine Seite mit dem Slug "my-event" und einem Event (CPT) mit dem Slug "my-event" erstellt habe, wird der benutzerdefinierte Beitragstyp angezeigt.

Bildbeschreibung hier eingeben

  1. Alle anderen Seiten funktionieren auch nicht. Wenn Sie sich das Bild oben ansehen, wird klar, warum: Die benutzerdefinierte Post-Typ-Regel wird immer mit einem Seiten-Slug verglichen. Da WordPress nicht erkennen kann, ob es sich um eine Seite oder einen benutzerdefinierten Beitragstyp handelt, der nicht vorhanden ist, wird 404 zurückgegeben. Aus diesem Grund benötigen Sie einen Slug, um die Seite oder den CPT zu identifizieren. Eine mögliche Lösung wäre, den Fehler abzufangen und nach einer Seite zu suchen, die möglicherweise ähnlich zu dieser Antwort existiert .

Wenn also das Ziel darin besteht, den Slug für CPTs zu entfernen, können wir das CPT nicht als etwas Einzigartiges bezeichnen, das nicht kollidieren würde, da es sowieso nie in der URL zu sehen sein wird? Oder ist der Post-Name der mögliche Konflikt, wenn er wie eine Seite benannt wird?
Ben Racicot

Ich habe meine Antwort aktualisiert, um zu zeigen, dass dies tatsächlich alle Seiten zerstört. Ohne einen Slug sucht WP nach einem CPT anstelle einer Seite und gibt einen Fehler zurück, wenn dieser nicht gefunden wird. Es hat also eigentlich nichts mit dem Post-Namen zu tun.
Jan Beck

1
Aha. Es sollte Umschreibungsregeln geben, die '-1' an zukünftige widersprüchliche URLs anhängen, wie z. B. native WP-Posts gegenüber Seiten. Ich habe ein Trac-Ticket erstellt. Core.trac.wordpress.org/ticket/34136#ticket würde Ihre Gedanken lieben.
Ben Racicot

7

Wenn ich mir die Antworten hier ansehe, gibt es meines Erachtens Raum für eine bessere Lösung, die einige der oben genannten Erkenntnisse kombiniert und die automatische Erkennung und Verhinderung von doppelten Post-Slugs hinzufügt.

HINWEIS: Stellen Sie sicher, dass Sie in meinem Beispiel unten "custom_post_type" für Ihren eigenen CPT-Namen ändern. Es gibt viele Vorkommen, und ein Suchen / Ersetzen ist ein einfacher Weg, um sie alle zu finden. Der gesamte Code kann in Ihrer functions.php oder in einem Plugin gespeichert werden.

Schritt 1: Deaktivieren Sie das erneute Schreiben für Ihren benutzerdefinierten Beitragstyp, indem Sie beim Registrieren des Beitrags das erneute Schreiben auf "false" setzen:

register_post_type( 'custom_post_type',
    array(
        'rewrite' => false
    )
);

Schritt 2: Fügen Sie unsere benutzerdefinierten Umschreibungen manuell am unteren Rand der WordPress-Umschreibungen für unseren benutzerdefinierten Post-Typ hinzu

function custom_post_type_rewrites() {
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/?$', 'index.php?attachment=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/trackback/?$', 'index.php?attachment=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?attachment=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/attachment/([^/]+)/embed/?$', 'index.php?attachment=$matches[1]&embed=true', 'bottom');
    add_rewrite_rule( '([^/]+)/embed/?$', 'index.php?custom_post_type=$matches[1]&embed=true', 'bottom');
    add_rewrite_rule( '([^/]+)/trackback/?$', 'index.php?custom_post_type=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '([^/]+)/page/?([0-9]{1,})/?$', 'index.php?custom_post_type=$matches[1]&paged=$matches[2]', 'bottom');
    add_rewrite_rule( '([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?custom_post_type=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '([^/]+)(?:/([0-9]+))?/?$', 'index.php?custom_post_type=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/?$', 'index.php?attachment=$matches[1]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/trackback/?$', 'index.php?attachment=$matches[1]&tb=1', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$', 'index.php?attachment=$matches[1]&feed=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$', 'index.php?attachment=$matches[1]&cpage=$matches[2]', 'bottom');
    add_rewrite_rule( '[^/]+/([^/]+)/embed/?$', 'index.php?attachment=$matches[1]&embed=true', 'bottom');
}
add_action( 'init', 'custom_post_type_rewrites' );

HINWEIS: Abhängig von Ihren Anforderungen möchten Sie möglicherweise die obigen Änderungen vornehmen (Deaktivieren von Trackbacks, Feeds usw.). Dies sind die 'Standard'-Arten von Umschreibungen, die generiert worden wären, wenn Sie die Umschreibungen in Schritt 1 nicht deaktiviert hätten

Schritt 3: Erstelle wieder einen Permalink zu deinem benutzerdefinierten Post-Typ "pretty"

function custom_post_type_permalinks( $post_link, $post, $leavename ) {
    if ( isset( $post->post_type ) && 'custom_post_type' == $post->post_type ) {
        $post_link = home_url( $post->post_name );
    }

    return $post_link;
}
add_filter( 'post_type_link', 'custom_post_type_permalinks', 10, 3 );

HINWEIS: Sie können hier aufhören, wenn Sie nicht befürchten, dass Ihre Benutzer einen in Konflikt stehenden (doppelten) Beitrag in einem anderen Beitragstyp erstellen, wodurch eine Situation entsteht, in der nur einer von ihnen geladen werden kann, wenn die Seite angefordert wird.

Schritt 4: Verhindern Sie doppelte Pfostenschnecken

function prevent_slug_duplicates( $slug, $post_ID, $post_status, $post_type, $post_parent, $original_slug ) {
    $check_post_types = array(
        'post',
        'page',
        'custom_post_type'
    );

    if ( ! in_array( $post_type, $check_post_types ) ) {
        return $slug;
    }

    if ( 'custom_post_type' == $post_type ) {
        // Saving a custom_post_type post, check for duplicates in POST or PAGE post types
        $post_match = get_page_by_path( $slug, 'OBJECT', 'post' );
        $page_match = get_page_by_path( $slug, 'OBJECT', 'page' );

        if ( $post_match || $page_match ) {
            $slug .= '-duplicate';
        }
    } else {
        // Saving a POST or PAGE, check for duplicates in custom_post_type post type
        $custom_post_type_match = get_page_by_path( $slug, 'OBJECT', 'custom_post_type' );

        if ( $custom_post_type_match ) {
            $slug .= '-duplicate';
        }
    }

    return $slug;
}
add_filter( 'wp_unique_post_slug', 'prevent_slug_duplicates', 10, 6 );

HINWEIS: Dadurch wird die Zeichenfolge '-duplicate' an das Ende aller doppelten Slugs angehängt. Dieser Code kann doppelte Bugs nicht verhindern, wenn diese bereits vor der Implementierung dieser Lösung vorhanden waren. Achten Sie darauf, zuerst nach Duplikaten zu suchen.

Ich würde gerne von allen anderen hören, die dies ausprobieren, um zu sehen, ob es auch für sie gut funktioniert.


Ich habe es gerade getestet und es scheint, als würde es bisher funktionieren.
Christine Cooper

War hoffnungsvoll für diesen Ansatz, gibt mir aber eine 404 für meine CPT-Posts, auch nach dem erneuten Speichern der Permalinks.
Garconis

Tut mir leid, dass es bei dir nicht geklappt hat, Garconis. Ich hatte vor einiger Zeit mit jemand anderem darüber gesprochen und sie hatten auch Probleme damit auf ihrer Website. Ich scheine mich zu erinnern, dass es wichtig war, ob Ihre Blog-Posts Permalinks ein Präfix haben. Auf der von mir entwickelten Seite verwenden die Blog-Posts die Permalink-Struktur: / blog /% postname% /. Wenn Sie in Ihren Blog-Posts kein Präfix haben und dies akzeptabel ist, probieren Sie es aus und lassen Sie mich wissen, wie es geht!
Matt Keys

2
Das hat bei mir funktioniert. Im Gegensatz zu anderen Lösungen auf der Seite wurden normale Seiten oder das Blog-Layout nicht beschädigt und es wurden keine unendlichen Weiterleitungen verursacht. Es wird sogar die richtige URL im Bereich "Permalink" angezeigt, wenn diese Cpt-Seiten bearbeitet werden. Ziemlich gute Lösung hier, nur der Vorbehalt, dass die Archivseite nicht funktioniert. Denken Sie daran , "custom_post_type" auszutauschen und anschließend Ihre Permalinks zu aktualisieren .
Radley Sustaire

@MattKeys, die Standardeinstellungen für Permalink haben eine benutzerdefinierte Struktur von /%category%/%postname%/. Wenn Sie Ihren Code hinzufügen, sehen die CPT-Slugs OK aus (obwohl der abschließende Schrägstrich fehlt) ... und die Konfliktüberprüfung funktioniert auch. Aber der eigentliche Beitrag ergibt sich auf einem 404.
Garconis

1

Sie brauchen nicht so viel Hardcode. Benutze einfach ein leichtes Plugin:

Es hat anpassbare Optionen.


Jetzt weiß ich, warum du abgelehnt wurdest. Es verhindert, dass normale Seitenlinks aufgelöst werden. Ich habe es nicht gesehen, weil ich trotz Aktualisierung zwischengespeicherte Kopien der vorhandenen Seiten erhalten habe.
Walf

@Walf Kannst du mir das Problem im Detail erklären?
T.Todua

Das Folgen von Links zu Seiten (die nicht dem benutzerdefinierten Beitragstyp entsprachen) aus dem Hauptmenü ergab 404 Fehler, als ob die Seite nicht vorhanden wäre. das ist es.
Walf

@Walf kannst du mir eine Beispiel-URL für deinen Anlass geben? (Sie können Domain-Namen abdecken, wenn Sie wollen, ich brauche nur ein Ex-Beispiel) Danke, ich werde es aktualisieren
T.Todua

1

Hatte hier die gleichen Probleme und es scheint keine Bewegung auf der WordPress-Seite zu geben. In meiner speziellen Situation, in der für einzelne Blogposts die Struktur / blog /% postname% / benötigt wurde, war diese Lösung

https://kellenmace.com/remove-custom-post-type-slug-from-permalinks/

endete in einer Reihe von 404s

Aber zusammen mit diesem wunderbaren Ansatz, der nicht die Backend-Permalink-Struktur für den Blogpost verwendet, funktioniert es endlich wie Charme. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Vielen Dank.


0

und wir können einige Änderungen an der oben genannten Funktion vornehmen:

function na_parse_request( $query ) {

if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
    return;
}

if ( ! empty( $query->query['name'] ) ) {
    $query->set( 'post_type', array( 'post', 'events', 'page' ) );
}
}

zu:

function na_parse_request( $query ) {

if ( ! $query->is_main_query() || 2 != count( $query->query ) || ! isset( $query->query['page'] ) ) {
    return;
}

if ( ! empty( $query->query['name'] ) ) {

    global $wpdb;
    $pt = $wpdb->get_var(
        "SELECT post_type FROM `{$wpdb->posts}` " .
        "WHERE post_name = '{$query->query['name']}'"
    );
    $query->set( 'post_type', $pt );
}
}

um den richtigen post_type Wert zu setzen.



0

Für alle, die dies lesen und Probleme mit untergeordneten Posts hatten, wie ich es tat, war es der beste Weg, Ihre eigenen Umschreiberegeln hinzuzufügen.

Das Hauptproblem, das ich hatte, war, dass WordPress die Weiterleitung von Seiten mit einer Tiefe von 2 Ebenen (untergeordnete Posts) ein wenig anders behandelt als 3 Ebenen (untergeordnete Posts).

Das bedeutet, wenn ich / post-type / post-name / post-child / habe, kann ich / post-name / post-child verwenden und es wird mich zu dem mit post-type vor umleiten, aber wenn ich post-type habe / post-name / post-child / post-grandchild dann kann ich post-name / post-child / post-grandchild nicht verwenden.

Wenn Sie sich die Umschreiberegeln ansehen, sieht es so aus, als würde sie für andere Dinge als Seitennamen auf der ersten und zweiten Ebene passen (ich denke, die zweite Ebene entspricht dem Anhang), und dann wird dort etwas unternommen, um Sie zum richtigen Beitrag umzuleiten. Auf drei Ebenen funktioniert es nicht.

Als erstes müssen Sie den Beitragstyp-Link auch von Kindern entfernen. Diese Logik sollte hier vorkommen, wenn Sie sich die Antwort von Nate Allen oben ansehen:

$post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );

Ich selbst habe eine Mischung verschiedener Bedingungen verwendet, um zu überprüfen, ob der Beitrag Kinder hat und was nicht, um zum richtigen Permalink zu gelangen. Dieser Teil ist nicht zu knifflig und Sie werden Beispiele von Leuten finden, die es woanders machen.

Der nächste Schritt ist jedoch, wo sich die Dinge von der gegebenen Antwort ändern. Anstatt der Hauptabfrage Dinge hinzuzufügen (die für benutzerdefinierte Posts und ihre Kinder, aber nicht für die weiteren Kinder funktionierten), habe ich ein Umschreiben hinzugefügt, das an die Unterseite der WordPress-Regeln ging, sodass, wenn der Seitenname nicht ausgecheckt hat und es im Gange war Wenn Sie auf 404 klicken, wird ein letzter Test durchgeführt, um festzustellen, ob eine Seite innerhalb des benutzerdefinierten Beitragstyps denselben Namen hat. Andernfalls wird 404 verworfen.

Hier ist die Umschreiberegel, die ich verwendet habe, unter der Annahme, dass 'event' der Name Ihres CPT ist

function rewrite_rules_for_removing_post_type_slug()
{
    add_rewrite_rule(
        '(.?.+?)?(:/([0-9]+))?/?$',
        'index.php?event=$matches[1]/$matches[2]&post_type=event',
        'bottom'
    );
}

add_action('init', 'rewrite_rules_for_removing_post_type_slug', 1, 1);

Hoffe, das hilft jemand anderem, ich konnte nichts anderes finden, was mit Child-of-Child-Posts und dem Entfernen der Schnecke von diesen zu tun hatte.


Es scheint einen Tippfehler in der Regex zu geben. Zwischen '(:' und '?' Wird benötigt, um es als nicht aufzeichnendes Untermuster zu verwenden => '(?:'. Das dritte? Scheint fehl am Platz zu sein, da es ein leeres erstes Untermuster zulässt. Ohne diesen Tippfehler ist der Ausdruck derselbe wie für den eingebauten Beitragstyp 'page' (Seite)
notiere den
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.