Rimuovere lo slug dagli URL dei post dei tipi di contenuto personalizzati

Esaminando le risposte qui presenti, credo ci sia spazio per una soluzione migliore che combina alcune cose che ho imparato sopra e aggiunge il rilevamento automatico e la prevenzione di slug di post duplicati.

NOTA: Assicurati di sostituire 'custom_post_type' con il nome del tuo CPT nell'esempio qui sotto. Ci sono molte occorrenze, e un 'trova/sostituisci' è un modo semplice per catturarle tutte. Tutto questo codice può essere inserito nel tuo functions.php o in un plugin.

Passo 1: Disabilita i rewrite sul tuo custom post type impostando rewrites a 'false' quando registri il post:

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

Passo 2: Aggiungi manualmente i nostri rewrite personalizzati in fondo ai rewrite di WordPress per il nostro 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' );

NOTA: A seconda delle tue esigenze, potresti voler modificare i rewrite sopra indicati (disabilitare i trackback? i feed?, ecc.). Questi rappresentano i rewrite 'predefiniti' che sarebbero stati generati se non avessi disabilitato i rewrite nel passo 1

Passo 3: Rendi nuovamente 'belli' i permalink per il tuo custom post type

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

NOTA: Puoi fermarti qui se non sei preoccupato che i tuoi utenti creino un post conflittuale (duplicato) in un altro tipo di post che creerà una situazione in cui solo uno di essi potrà essere caricato quando la pagina viene richiesta.

Passo 4: Previeni slug di post duplicati

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 ) {
        // Salvataggio di un post di tipo custom_post_type, controlla duplicati nei tipi di post POST o 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 {
        // Salvataggio di un POST o PAGE, controlla duplicati nel tipo di post 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 );

NOTA: Questo aggiungerà la stringa '-duplicate' alla fine di qualsiasi slug duplicato. Questo codice non può prevenire slug duplicati se già esistono prima di implementare questa soluzione. Assicurati di controllare prima i duplicati.

Mi piacerebbe avere feedback da chiunque provi questa soluzione per vedere se ha funzionato bene anche per loro.

Scrivi il seguente codice nella registrazione della tassonomia.

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

La cosa più importante che devi fare dopo aver modificato il codice

Dopo aver modificato il documento della tassonomia del tuo custom post type, prova ad andare in Impostazioni > Permalink e risalva le impostazioni, altrimenti otterrai un errore 404 pagina non trovata.

Ho cercato di capirlo non molto tempo fa e la risposta breve, per quanto ne so, è no. Almeno non dall'interno dell'argomento rewrite.

La spiegazione lunga diventa evidente se guardi il codice effettivo di register_post_type in wp-includes/post.php riga 1454:

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

Puoi vedere che antepone $args->rewrite['slug'] al tag di rewrite %$post_type%. Si potrebbe pensare "allora impostiamo semplicemente lo slug a null" fino a quando non si guarda qualche riga più sopra:

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

Puoi vedere che la funzione si aspetta sempre un valore di slug che non sia vuoto e altrimenti utilizza il post type.

Rassegna Plugin

Siamo quasi nel 2020 e molte di queste risposte non funzionano più. Ecco la mia panoramica sulle opzioni attuali:

• La risposta di Matt Keys sembra essere l'unica sulla strada giusta se cerchi una soluzione personalizzata. Nessuno dei plugin che ho trovato fa tutto ciò che è elencato qui, soprattutto il controllo dei duplicati. Questo approccio sembra un'ottima opportunità per un plugin se qualcuno volesse cimentarsi.
• Permalink Manager Lite
  • Il migliore tra i plugin gratuiti che ho provato.
  • Offre il controllo completo sulla struttura dei permalink di Pagine/Articoli/CPT e permette che siano uguali. L'interfaccia grafica è di gran lunga la più ricca di funzionalità.
  • Permette di sovrascrivere completamente ogni singolo articolo e mostra qual era il permalink originale/predefinito, con la possibilità di resettarlo se necessario.
  • Supporta il multi-sito.
  • Non controlla i duplicati tra tipi di contenuto, il che è un peccato. Se una pagina e un CPT hanno lo stesso URL, viene caricata la pagina e il CPT risulta inaccessibile. Nessun avviso o errore, devi controllare manualmente i duplicati.
  • Tutte le funzionalità relative alle tassonomie sono nella versione PRO. I reminder per l'aggiornamento sono piuttosto invadenti.
• Custom Permalinks
  • La versione gratuita offre molte funzionalità. I permalink per le tassonomie e il supporto premium sembrano essere le uniche cose riservate alla versione pro.
  • Permette di modificare il permalink completo per ogni singola pagina/articolo/CPT.
  • Supporta il multi-sito.
  • Non permette di modificare la struttura predefinita, quindi i tuoi Custom Post Type avranno ancora la forma esempio.com/slug-cpt/titolo-articolo ma puoi modificarli individualmente.
  • Non controlla i duplicati tra tipi di contenuto, il che è un peccato.
• Custom Post Type Permalinks
  • Permette agli utenti non sviluppatori di modificare le cose che sono già facili da cambiare con register_post_type
  • Non permette di modificare lo slug base del CPT - solo la parte che viene dopo - quindi praticamente inutile per gli sviluppatori e per il problema sollevato in questa domanda.
• remove base slug... - abbandonato da diversi anni... da non usare.

In risposta alla mia precedente risposta: potresti ovviamente impostare il parametro rewrite su false quando registri un nuovo post type e gestire manualmente le regole di riscrittura in questo modo

<?php
function wpsx203951_custom_init() {

    $post_type = 'event';
    $args = (object) array(
        'public'      => true,
        'label'       => 'Eventi',
        'rewrite'     => false, // impostare sempre su false
        'has_archive' => true
    );
    register_post_type( $post_type, $args );

    // questi sono i tuoi argomenti effettivi per la riscrittura
    $args->rewrite = array(
        'slug' => 'calendario'
    );

    // tutto ciò che segue è preso dalla funzione 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' );

Puoi vedere che la chiamata add_permastruct ora non include più lo slug. Ho testato due scenari:

1. Quando ho creato una pagina con lo slug "calendario", quella pagina viene sovrascritta dall'archivio del post type che utilizza anch'esso lo slug "calendario".

2. Quando ho creato una pagina con lo slug "mio-evento" e un evento (CPT) con lo slug "mio-evento", viene visualizzato il custom post type.

3. Qualsiasi altra pagina non funziona. Se guardi l'immagine sopra diventa chiaro il perché: la regola del custom post type corrisponderà sempre a uno slug di pagina. Poiché WordPress non ha modo di identificare se si tratta di una pagina o di un custom post type che non esiste, restituirà un errore 404. Ecco perché hai bisogno di uno slug per identificare se si tratta di una pagina o di un CPT. Una possibile soluzione sarebbe intercettare l'errore e cercare una pagina che potrebbe esistere similmente a questa risposta.

Contesto

Anche dopo aver cercato ovunque, non sono riuscito a trovare una soluzione adeguata per rimuovere lo slug CPT dai permalink che funzioni davvero e sia coerente con il modo in cui WordPress analizza effettivamente le richieste. Sembra che tutti gli altri alla ricerca della stessa soluzione siano nella mia stessa situazione.

Si scopre che si tratta in realtà di una soluzione in due parti.

1. Rimuovere lo slug CPT dai permalink
2. Indicare a WordPress come trovare i post dai nuovi permalink

La prima parte è abbastanza semplice e molte risposte esistenti l'hanno già corretta. Ecco come si presenta:

// rimuovi lo slug CPT dai permalink
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 );

Ora, la seconda parte è dove le cose si complicano. Dopo aver risolto la prima parte, i tuoi permalink CPT non hanno più gli slug CPT. Ma ora il problema è che WordPress non sa come trovare i tuoi post da quei nuovi permalink perché tutto ciò che sa è che i permalink CPT hanno gli slug CPT. Quindi, senza uno slug CPT nel permalink, non riesce a trovare il tuo post. Ecco perché quando fai una richiesta per i tuoi post a questo punto, restituisce un errore 404 non trovato.

Quindi, tutto ciò che devi fare ora è indicare a WordPress come trovare i tuoi post utilizzando i nuovi permalink. Ma questa è la parte in cui le risposte esistenti non funzionano molto bene. Diamo un'occhiata ad alcune di queste risposte per esempio:

La funzione qui sotto funziona abbastanza bene ma funzionerà solo se la struttura dei permalink è impostata su Nome articolo.

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

        // Aggiungi CPT alla lista dei tipi di post che WP includerà quando esegue una query basata sul nome del post.
        $query->set( 'post_type', $cpt );
    }
}
add_action( 'pre_get_posts', 'parse_request_remove_cpt_slug' );

La funzione qui sotto funziona bene per il tuo tipo di post personalizzato indipendentemente dalla struttura del permalink, tuttavia genererà un errore su tutti gli altri tipi di post.

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

C'è un'altra risposta che dovrebbe funzionare come soluzione autonoma ma finisce per causare più problemi che soluzioni, come generare errori nei tuoi post CPT così come in altri. Questa richiede la modifica dell'argomento rewrite nella registrazione del tuo CPT come segue:

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

Finora, tutte le risposte esistenti che ho trovato sono come quelle sopra. O funzionano parzialmente o non funzionano più. Questo probabilmente perché WordPress non fornisce un modo semplificato per rimuovere lo slug CPT dai permalink dei tipi di post personalizzati e quindi queste risposte sono basate su scenari particolari o su un modo approssimativo.

Risposta

Ecco cosa ho ideato cercando di creare una soluzione che funziona nella maggior parte se non in tutti gli scenari. Questo rimuoverà correttamente lo slug CPT dai permalink CPT e indicherà a WordPress come trovare i post CPT da quei nuovi permalink. Non riscrive le regole nel database quindi non sarà necessario salvare nuovamente la struttura dei permalink. Inoltre, questa soluzione è coerente con il modo in cui WordPress analizza effettivamente le richieste per trovare i post dai permalink, il che aiuta a renderla una soluzione più accettabile.

Assicurati di sostituire custom_post_type con il nome del tuo tipo di post personalizzato. Appare una volta in ogni funzione quindi due occorrenze in totale.

// rimuovi lo slug CPT dai permalink
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 );


// indica a wordpress come trovare i post dai nuovi permalink
function parse_request_remove_cpt_slug( $query_vars ) {

    // esci se siamo nel pannello di amministrazione 
    if ( is_admin() ) {
        return $query_vars;
    }

    // esci se i permalink personalizzati non sono abilitati
    if ( ! get_option( 'permalink_structure' ) ) {
        return $query_vars;
    }

    $cpt = 'custom_post_type';

    // memorizza il valore dello slug del post in una variabile
    if ( isset( $query_vars['pagename'] ) ) {
        $slug = $query_vars['pagename'];
    } elseif ( isset( $query_vars['name'] ) ) {
        $slug = $query_vars['name'];
    } else {
        global $wp;
        
        $path = $wp->request;

        // usa il percorso dell'url come 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 ) {

            // rimuovi qualsiasi elemento di errore 404 non trovato dall'array query_vars perché esiste già una corrispondenza nel cpt
            if ( isset( $query_vars['error'] ) && $query_vars['error'] == 404 ) {
                unset( $query_vars['error'] );
            }

            // rimuovi elementi non necessari dall'array query_vars originale
            unset( $query_vars['pagename'] );
    
            // aggiungi elementi necessari nell'array query_vars
            $query_vars['post_type'] = $cpt;
            $query_vars['name'] = $slug;
            $query_vars[$cpt] = $slug; // questo costruisce l'elemento "cpt=>post_slug"
        }
    }

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

Considerazioni:

1. Questa soluzione lascia intenzionalmente fuori dal suo ambito la struttura di permalink Semplice poiché non è una delle strutture di permalink personalizzati. Quindi, funzionerà con tutte le strutture di permalink tranne quella Semplice.

2. Poiché WordPress non previene automaticamente la creazione di slug duplicati tra diversi tipi di post, potresti riscontrare problemi nell'accesso ai post che hanno lo stesso slug a causa della perdita di unicità nei permalink CPT dopo la rimozione degli slug CPT. Questo codice non include alcuna funzionalità per prevenire tale comportamento, quindi potresti voler trovare una soluzione separata per affrontare questo problema.

3. In caso di un permalink duplicato, questo codice darà priorità al tuo CPT rispetto agli altri e quindi visualizzerà il post nel tuo CPT quando richiesto.

e possiamo apportare alcune modifiche alla funzione menzionata sopra:

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

in:

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

per impostare il valore corretto di post_type.

Questo ha funzionato per me: 'rewrite' => array('slug' => '/')

Per chiunque stia leggendo questo post e abbia avuto problemi con i post figli come ho avuto io, ho scoperto che il modo migliore è aggiungere le proprie regole di rewrite.

Il problema principale che ho riscontrato è che WordPress gestisce il reindirizzamento da pagine che sono a 2 livelli di profondità (post figli) in modo leggermente diverso rispetto a pagine a 3 livelli di profondità (figli di post figli).

Ciò significa che quando ho /tipo-di-post/nome-post/figlio-post/ posso usare /nome-post/figlio-post e verrò reindirizzato alla versione con tipo-di-post all'inizio, ma se ho tipo-di-post/nome-post/figlio-post/nipote-post allora non posso usare nome-post/figlio-post/nipote-post.

Analizzando le regole di rewrite, sembra che corrisponda a elementi diversi da pagename al primo e secondo livello (penso che il secondo livello corrisponda agli allegati) e poi esegue qualcosa per reindirizzarti al post corretto. A tre livelli di profondità non funziona.

La prima cosa da fare è rimuovere il link del post type anche dai figli. Questa logica dovrebbe avvenire qui se guardi la risposta di Nate Allen sopra:

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

Personalmente ho usato un mix di diversi condizionali per verificare se il post aveva figli e simili per ottenere il permalink corretto. Questa parte non è troppo complicata e troverai esempi di persone che lo fanno altrove.

Il passo successivo però è dove le cose cambiano rispetto alla risposta data. Invece di aggiungere elementi alla query principale (che funzionava per i post personalizzati e i loro figli ma non per i figli successivi) ho aggiunto una regola di rewrite che andava in fondo alle regole di WordPress in modo che se pagename non fosse verificato e fosse sul punto di restituire un 404, avrebbe effettuato un ultimo controllo per vedere se una pagina all'interno del custom post type aveva lo stesso nome, altrimenti avrebbe restituito il 404.

Ecco la regola di rewrite che ho usato assumendo che 'event' sia il nome del tuo CPT

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

Spero che questo aiuti qualcun altro, non ho trovato nient'altro che riguardasse i figli dei post figli e la rimozione dello slug da quelli.

Ho avuto gli stessi problemi qui e lì e sembra non esserci alcun movimento sul sito WordPress. Nella mia situazione particolare, in cui per i singoli articoli del blog era necessaria la struttura /blog/%postname%/, questa soluzione

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

ha prodotto una serie di errori 404

Ma insieme a questo meraviglioso approccio, che non utilizza la struttura dei permalink del backend per l'articolo del blog, alla fine funziona perfettamente. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Grazie mille.

Per me ha funzionato ora:

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

Inserisci all'interno della funzione register_post_type().

Questo è ciò che ha funzionato per me. Sostituisci podcast con lo slug del tuo CPT (Custom Post Type):

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

Il plugin "Remove CPT base" funziona.

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

Non è necessario scrivere così tanto codice hard-code. Basta utilizzare un plugin leggero:

• Remove Base Slug From Custom Post

Ha opzioni personalizzabili.