Eliminarea slug-ului din URL-urile postărilor pentru tipuri de postări personalizate

Analizând răspunsurile de aici, cred că există loc pentru o soluție mai bună care combină câteva lucruri învățate mai sus și adaugă detectarea automată și prevenirea slug-urilor duplicate pentru articole.

NOTĂ: Asigurați-vă că înlocuiți 'custom_post_type' cu numele propriului CPT în tot exemplul meu de mai jos. Există multe apariții, iar un 'find/replace' este o modalitate ușoară de a le prinde pe toate. Tot acest cod poate fi introdus în functions.php sau într-un plugin.

Pasul 1: Dezactivați rescrierile pentru tipul de postare personalizat setând rewrites la 'false' la înregistrarea postării:

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

Pasul 2: Adăugați manual rescrierile personalizate în partea de jos a rescrierilor WordPress pentru custom_post_type

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' );

NOTĂ: În funcție de nevoile dvs., este posibil să doriți să modificați rescrierile de mai sus (dezactivați trackback-uri? feed-uri?, etc.). Acestea reprezintă tipurile 'implicite' de rescrieri care ar fi fost generate dacă nu ați fi dezactivat rescrierile în pasul 1

Pasul 3: Faceți din nou permalink-urile către tipul de postare personalizat 'prietenoase'

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 );

NOTĂ: Puteți opri aici dacă nu vă faceți griji cu privire la faptul că utilizatorii pot crea o postare conflictuală (duplicat) într-un alt tip de postare care va crea o situație în care doar una dintre ele se va încărca atunci când este solicitată pagina.

Pasul 4: Prevenirea slug-urilor duplicate pentru postări

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 ) {
        // Salvarea unei postări custom_post_type, verifică duplicate în POST sau PAGE
        $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 {
        // Salvarea unui POST sau PAGE, verifică duplicate în custom_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 );

NOTĂ: Acest cod va adăuga șirul '-duplicate' la sfârșitul oricărui slug duplicat. Acest cod nu poate preveni slug-uri duplicate dacă acestea există deja înainte de implementarea acestei soluții. Asigurați-vă că verificați mai întâi dacă există duplicate.

Aș fi bucuros să aud de la alții care încerce această soluție pentru a vedea dacă a funcționat bine și pentru ei.

Introdu următorul cod în înregistrarea taxonomiei.

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

Cel mai important lucru pe care trebuie să-l faci după modificarea codului

După ce ai modificat documentul taxonomiei pentru tipul personalizat de postare, încearcă să mergi la Setări > Legături permanente și salvează din nou setările, altfel vei primi eroarea 404 pagină negăsită.

Am încercat să înțeleg acest lucru nu demult și răspunsul scurt din câte știu este nu. Cel puțin nu din argumentul rewrite.

Explicația detaliată devine evidentă dacă analizezi codul actual al funcției register_post_type în wp-includes/post.php linia 1454:

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

Poți observa că adaugă prefixul $args->rewrite['slug'] la eticheta de rescriere %$post_type%. S-ar putea credea "hai să setăm slug-ul la null atunci", dar dacă te uiți câteva linii mai sus:

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

Se poate observa că funcția mereu așteaptă o valoare pentru slug care să nu fie goală și altfel folosește tipul de postare.

Rezumat Plugin-uri

Este aproape 2020 și multe dintre aceste răspunsuri nu mai funcționează. Iată un rezumat al opțiunilor actuale:

• Răspunsul lui Matt Keys pare să fie singurul pe drumul cel bun dacă doriți o soluție personalizată. Niciunul dintre plugin-urile pe care le-am găsit nu poate face tot ceea ce este listat aici, în special verificarea duplicatelor. Această abordare pare a fi o oportunitate foarte bună pentru un plugin, dacă cineva ar dori să o preia.
• Permalink Manager Lite
  • Cel mai bun dintre plugin-urile gratuite pe care le-am încercat.
  • Oferă control complet asupra întregii structuri de permalinkuri pentru Pagini/Articole/CPT și permite ca acestea să fie identice. Interfața grafică este cu mult cea mai bogată în funcționalități.
  • Permite suprascrierea completă pentru fiecare post și vă permite să vedeți care ar fi permalinkul original/implicit și să îl resetați la valoarea implicită dacă este necesar.
  • Suportă multi-site.
  • Nu verifică duplicatele între tipurile de postări, ceea ce este păcat. Dacă o pagină și un CPT au același URL, pagina se încarcă și CPT-ul devine inaccesibil. Fără avertismente sau erori, trebuie să faceți verificări manuale pentru duplicate.
  • Toate funcționalitățile legate de taxonomii sunt în versiunea PRO. Notificările pentru upgrade sunt destul de insistente.
• Custom Permalinks
  • Versiunea gratuită face multe. Doar permalinkurile pentru taxonomii și suportul premium par să fie reținute pentru versiunea pro.
  • Vă permite să modificați întregul permalink pentru orice pagină/articol/CPT individual.
  • Suportă multi-site.
  • Nu vă permite să modificați structura implicită, așa că tipurile dvs. de postări personalizate vor rămâne de forma exemplu.com/cpt-slug/titlu-postare, dar le puteți modifica individual.
  • Nu verifică duplicatele între tipurile de postări, ceea ce este păcat.
• Custom Post Type Permalinks
  • Permite utilizatorilor non-developeri să modifice lucrurile care sunt deja ușor de schimbat cu register_post_type
  • Nu vă permite să modificați slug-ul de bază al CPT-ului - doar partea care vine după acesta - deci practic inutil pentru dezvoltatori și pentru problema din această întrebare.
• remove base slug... - neactualizat de câțiva ani... nu-l folosiți.

Ca răspuns la anterioarea mea soluție: desigur, puteți seta parametrul rewrite la false atunci când înregistrați un nou tip de postare și să gestionați manual regulile de rescriere, astfel:

<?php
function wpsx203951_custom_init() {

    $post_type = 'event';
    $args = (object) array(
        'public'      => true,
        'label'       => 'Evenimente',
        'rewrite'     => false, // întotdeauna setați acest parametru la false
        'has_archive' => true
    );
    register_post_type( $post_type, $args );

    // acestea sunt argumentele actuale de rescriere
    $args->rewrite = array(
        'slug' => 'calendar'
    );

    // tot ce urmează este preluat din funcția register_post_type
    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' );

Puteți observa că apelul add_permastruct nu mai include slug-ul. Am testat două scenarii:

1. Când am creat o pagină cu slug-ul "calendar", acea pagină este suprascrisă de arhiva tipului de postare care folosește același slug "calendar".

2. Când am creat o pagină cu slug-ul "my-event" și un eveniment (CPT) cu același slug "my-event", este afișat conținutul tipului de postare personalizat.

3. Orice alte pagini nu funcționează. Dacă vă uitați la imaginea de mai sus, devine clar de ce: regula tipului de postare personalizat se va potrivi întotdeauna cu un slug de pagină. Deoarece WordPress nu are cum să identifice dacă este vorba despre o pagină sau un tip de postare personalizat care nu există, va returna eroarea 404. De aceea aveți nevoie de un slug pentru a identifica fie pagina, fie CPT. O soluție posibilă ar fi să interceptați eroarea și să căutați o pagină care ar putea exista similar cu acest răspuns.

Context

Chiar după ce am căutat peste tot, nu am găsit o soluție adecvată pentru eliminarea slug-ului CPT din permalinkuri care să funcționeze efectiv și să fie consistentă cu modul în care WordPress analizează cererile. Se pare că toți ceilalți care caută aceeași soluție se află în aceeași situație ca mine.

După cum s-a dovedit, aceasta este de fapt o soluție în două părți.

1. Eliminarea slug-ului CPT din permalinkuri
2. Instruirea WordPress-ului cum să găsească postările din noile permalinkuri

Prima parte este destul de simplă și multe răspunsuri existente o au deja corect. Iată cum arată:

// elimină slug-ul CPT din permalinkuri
function remove_cpt_slug( $post_link, $post, $leavename ) {

    if ( $post->post_type != 'custom_post_type' ) {
        return $post_link;
    } else {
        $post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );
        return $post_link;
    }
}
add_filter( 'post_type_link', 'remove_cpt_slug', 10, 3 );

A doua parte este unde lucrurile devin complicate. După rezolvarea primei părți, permalinkurile CPT nu mai au slug-uri CPT. Dar acum problema este că WordPress nu știe cum să găsească postările din acele permalinkuri noi, deoarece tot ce știe este că permalinkurile CPT au slug-uri CPT. Așadar, fără un slug CPT în permalink, nu poate găsi postarea. De aceea, atunci când faci o cerere pentru postările tale în acest moment, primești o eroare 404 not found.

Deci, tot ce trebuie să faci acum este să instruiești WordPress cum să găsească postările tale folosind noile permalinkuri. Dar aceasta este partea în care răspunsurile existente nu funcționează foarte bine. Să ne uităm la câteva dintre aceste răspunsuri, de exemplu:

Funcția de mai jos funcționează destul de bine, dar va funcționa doar dacă structura permalinkurilor este setată pe Numele postării.

function parse_request_remove_cpt_slug( $query ) {

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

    if ( ! empty( $query->query['name'] ) ) {
        global $wpdb;
        $cpt = $wpdb->get_var("SELECT post_type FROM $wpdb->posts WHERE post_name = '{$query->query['name']}'");

        // Adaugă CPT la lista de tipuri de postări pe care WordPress le va include când interoghează pe baza numelui postării.
        $query->set( 'post_type', $cpt );
    }
}
add_action( 'pre_get_posts', 'parse_request_remove_cpt_slug' );

Funcția de mai jos funcționează bine pentru tipul tău de postare personalizată, indiferent de structura permalinkului, dar va arunca o eroare pentru toate celelalte tipuri de postări.

function rewrite_rule_remove_cpt_slug() {

    add_rewrite_rule(
        '(.?.+?)(?:/([0-9]+))?/?$',
        'index.php?custom_post_type=$matches[1]/$matches[2]&post_type=custom_post_type',
        'bottom'
    );
}
add_action( 'init', 'rewrite_rule_remove_cpt_slug', 1, 1 );

Există un alt răspuns care ar trebui să funcționeze ca o soluție independentă, dar care ajunge să creeze mai multe probleme decât soluții, cum ar fi erori în postările CPT, precum și în altele. Aceasta necesită modificarea argumentului rewrite în înregistrarea CPT, după cum urmează:

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

Până acum, toate răspunsurile existente pe care le-am găsit sunt ca cele de mai sus. Fie funcționează parțial, fie nu mai funcționează. Acest lucru se întâmplă probabil pentru că WordPress nu oferă o modalitate simplă de a elimina slug-ul CPT din permalinkurile tipurilor de postări personalizate și, prin urmare, aceste răspunsuri se bazează fie pe anumite scenarii particulare, fie pe o metodă improvizată.

Răspuns

Iată ce am creat încercând să găsesc o soluție care funcționează în majoritatea, dacă nu în toate, scenariile. Aceasta va elimina corect slug-ul CPT din permalinkurile CPT, precum și va instrui WordPress să găsească postările CPT din acele permalinkuri noi. Nu rescrie regulile în baza de date, așa că nu va trebui să resalvezi structura permalinkurilor. În plus, această soluție este consistentă cu modul în care WordPress analizează cererile pentru a găsi postări din permalinkuri, ceea ce o face o soluție mai acceptabilă.

Asigură-te să înlocuiești custom_post_type cu numele propriului tip de postare personalizată. Apare o dată în fiecare funcție, deci în total de două ori.

// elimină slug-ul CPT din permalinkuri
function remove_cpt_slug( $post_link, $post, $leavename ) {

    if ( $post->post_type != 'custom_post_type' ) {
        return $post_link;
    } else {
        $post_link = str_replace( '/' . $post->post_type . '/', '/', $post_link );
        return $post_link;
    }
}
add_filter( 'post_type_link', 'remove_cpt_slug', 10, 3 );


// instruiește WordPress cum să găsească postările din noile permalinkuri
function parse_request_remove_cpt_slug( $query_vars ) {

    // returnează dacă este în panoul de administrare
    if ( is_admin() ) {
        return $query_vars;
    }

    // returnează dacă permalinkurile frumoase nu sunt activate
    if ( ! get_option( 'permalink_structure' ) ) {
        return $query_vars;
    }

    $cpt = 'custom_post_type';

    // stochează valoarea slug-ului postării într-o variabilă
    if ( isset( $query_vars['pagename'] ) ) {
        $slug = $query_vars['pagename'];
    } elseif ( isset( $query_vars['name'] ) ) {
        $slug = $query_vars['name'];
    } else {
        global $wp;
        
        $path = $wp->request;

        // folosește calea URL ca slug
        if ( $path && strpos( $path, '/' ) === false ) {
            $slug = $path;
        } else {
            $slug = false;
        }
    }

    if ( $slug ) {
        $post_match = get_page_by_path( $slug, 'OBJECT', $cpt );

        if ( ! is_admin() && $post_match ) {

            // elimină orice element de eroare 404 not found din array-ul query_vars deoarece există deja o potrivire în CPT
            if ( isset( $query_vars['error'] ) && $query_vars['error'] == 404 ) {
                unset( $query_vars['error'] );
            }

            // elimină elementele inutile din array-ul query_vars original
            unset( $query_vars['pagename'] );
    
            // adaugă elementele necesare în array-ul query_vars
            $query_vars['post_type'] = $cpt;
            $query_vars['name'] = $slug;
            $query_vars[$cpt] = $slug; // construiește elementul "cpt=>post_slug"
        }
    }

    return $query_vars;
}
add_filter( 'request', "parse_request_remove_cpt_slug" , 1, 1 );

Considerații:

1. Această soluție exclude în mod intenționat structura de permalink Simplu din sfera sa, deoarece nu este una dintre structurile de permalink frumoase. Deci, va funcționa cu toate structurile de permalink, cu excepția celei Simple.

2. Deoarece WordPress nu previne automat crearea de slug-uri duplicate în diferite tipuri de postări, poți întâmpina probleme la accesarea postărilor care au același slug din cauza pierderii unicității în permalinkurile CPT după eliminarea slug-urilor CPT. Acest cod nu include nicio funcționalitate pentru a preveni acest comportament, așa că poți dori să găsești o soluție separată pentru a rezolva această problemă.

3. În cazul în care există un permalink duplicat, acest cod va da prioritate CPT-ului tău față de altele și, prin urmare, va afișa postarea din CPT-ul tău atunci când este solicitată.

și putem face câteva modificări la funcția menționată mai sus:

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' ) );
}
}

în:

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 );
}
}

pentru a seta valoarea corectă a post_type.

Aceasta a funcționat pentru mine: 'rewrite' => array('slug' => '/')

Pentru cei care citesc acest lucru și au avut probleme cu postările copil (child posts) așa cum am avut și eu, am descoperit că cea mai bună soluție este să adăugați propriile reguli de rescriere (rewrite rules).

Principala problemă pe care o întâmpinam era că WordPress tratează redirecționarea pentru paginile care sunt la 2 niveluri (postări copil) puțin diferit față de cele la 3 niveluri (copil al unei postări copil).

Asta înseamnă că atunci când am o structură ca /tip-post/nume-post/post-copil/, pot folosi /nume-post/post-copil și voi fi redirecționat către varianta cu tipul postului în față. Dar dacă am /tip-post/nume-post/post-copil/post-nepot, nu pot folosi /nume-post/post-copil/post-nepot.

Analizând regulile de rescriere, se pare că WordPress caută alte lucruri în afară de pagename la primul și al doilea nivel (cred că al doilea nivel se potrivește cu atașamente) și apoi face ceva acolo pentru a vă redirecționa către postarea corectă. La trei niveluri adâncime, acest mecanism nu funcționează.

Primul lucru pe care trebuie să-l faceți este să eliminați link-ul tipului de post și pentru postările copil. Această logică ar trebui să fie implementată așa cum se vede în răspunsul lui Nate Allen de mai sus:

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

Eu am folosit o combinație de condiționale pentru a verifica dacă postarea are copii și alte aspecte pentru a obține permalink-ul corect. Această parte nu este prea complicată și veți găsi exemple de implementare în alte locuri.

Următorul pas este cel în care lucrurile se schimbă față de răspunsul dat. În loc să adăugăm elemente la interogarea principală (care a funcționat pentru postările personalizate și copiii lor, dar nu și pentru descendenții mai îndepărtați), am adăugat o regulă de rescrire care se adaugă la sfârșitul regulilor WordPress, astfel încât dacă pagename nu se potrivește și este pe cale să returneze un 404, va face o ultimă verificare pentru a vedea dacă o pagină din tipul de postare personalizată are același nume, altfel va returna 404.

Iată regula de rescriere pe care am folosit-o, presupunând că 'event' este numele CPT-ului vostru:

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);

Sper că acest lucru va ajuta pe cineva altcineva, deoarece nu am găsit nicio altă soluție care să abordeze postările copil ale copiilor și eliminarea slug-ului din acestea.

Am avut aceleași probleme aici și se pare că nu există nicio mișcare pe site-ul WordPress. În situația mea particulară, unde pentru articolele individuale de blog era necesară structura /blog/%postname%/, această soluție

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

a dus la o grămadă de erori 404

Dar împreună cu această abordare minunată, care nu folosește structura de permalink din backend pentru articolul de blog, în cele din urmă funcționează perfect. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Mulțumesc mult.

Pentru mine a funcționat acum:

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

Introduceți în interiorul funcției register_post_type().

Acesta este ceea ce a funcționat pentru mine. Înlocuiește podcast cu slug-ul tău CPT:

add_action('init', function () {
    register_post_type(
        'podcast',
        [
            'rewrite' => false,
        ]
    );
});

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

    return $post_link;
}, 10, 3);

add_action('init', function () {
    add_rewrite_rule('(.+?)/?$', 'index.php?podcast=$matches[1]', 'bottom');
});

Plugin-ul "Remove CPT base" funcționează.

https://wordpress.org/plugins/remove-cpt-base/

Nu ai nevoie de atât de mult cod hardcodat. Folosește simplu un plugin ușor:

• Remove Base Slug From Custom Post

Are opțiuni personalizabile.