Rimuovi la lumaca dagli URL di post personalizzati del tipo di post


48

Sembra che tutte le risorse web basate sull'argomento della rimozione di una lumaca di tipo post personalizzato, ad es

yourdomain.com/CPT-SLUG/post-name 

ora sono soluzioni molto obsolete che spesso fanno riferimento a installazioni precedenti alla versione 3.5 di WP. Uno comune è quello di:

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

all'interno della tua funzione register_post_type. Questo non funziona più ed è fuorviante. Quindi chiedo alla community nel terzo trimestre del 2018 sull'orlo di WordPress 5 ...

Quali sono i modi moderni ed efficienti per rimuovere la lumaca del tipo di post dall'URL di un post di tipo post personalizzato dall'argomento di riscrittura o in qualsiasi altro luogo?

AGGIORNAMENTO: sembrano esserci diversi modi per forzare questo a funzionare con regex. In particolare, la risposta di Jan Beck dovrebbe essere costantemente disposta a monitorare la creazione di contenuti per assicurarsi che non vengano creati nomi di pagine / post in conflitto .... Comunque sono convinto che questa sia una delle principali debolezze del core di WP dove dovrebbe essere gestita per noi . Sia come opzione / hook durante la creazione di un CPT o un set avanzato di opzioni per permalink. Si prega di supportare il ticket traccia.

Nota a piè di pagina: supporta questo ticket trac guardandolo / promuovendolo: https://core.trac.wordpress.org/ticket/34136#ticket


Immagino di grattarmi la testa sul perché vorresti farlo? Confuso.
Michael Ecklund,

3
@MichaelEcklund perché qualsiasi CPT utilizzato per creare pagine Web rivolte al pubblico ha un nome di lumaca forzata nell'URL. In realtà ci sono molti sviluppatori wp che cercano di rimuovere la lumaca in modo sicuro.
Ben Racicot,

Risposte:


60

Il seguente codice funzionerà, ma devi solo tenere presente che i conflitti possono verificarsi facilmente se la lumaca per il tuo tipo di post personalizzato è uguale alla lumaca di una pagina o post ...

In primo luogo, rimuoveremo la lumaca dal 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 );

Basta rimuovere la lumaca non è abbastanza. In questo momento, otterrai una pagina 404 perché WordPress si aspetta solo che post e pagine si comportino in questo modo. Dovrai anche aggiungere quanto segue:

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

Basta cambiare "eventi" per il tuo tipo di post personalizzato e sei a posto. Potrebbe essere necessario aggiornare i permalink.


Grazie. Pensi che sia meglio che creare manualmente le riscritture? Ho visto quella soluzione e potrebbe tenere a bada i conflitti di cui parli?
Ben Racicot,

1
Non riesce con nginx a causa della condizione 2 != count( $query->query ). Con nginx, puoi avere $ query-> query come array('page' => '', 'name' => '...', 'q' => '...'). Quindi @NateAllen, qual è il significato di quella condizione?
Fabio Montefuscolo,

3
Abbiamo bisogno di qualcosa di meglio di questo. Supporto per rimuovere la lumaca integrata in modo da non poter creare in seguito URL in conflitto. Il modo in cui i post e le pagine normali creano i loro URL.
Ben Racicot,

3
Sono solo io o questo rompe alcuni tag condizionali wordpress come is_single () e is_singular ()?
rob-gordon,

1
Questa soluzione purtroppo ha causato alcuni link non funzionanti e il mio blog ha smesso di mostrare post ed era solo una pagina normale. Di seguito trovi una soluzione migliore di Matt Keys.
Radley Sustaire,

20

Scrivi il seguente codice nella registrazione della tassonomia.

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

La cosa più importante che devi fare dopo la modifica del codice

Dopo aver modificato il documento di tassonomia del tipo di posta personalizzato, prova ad andare su Impostazioni> Permalink e salvare nuovamente le tue impostazioni , altrimenti otterrai 404 pagine non trovate.

Controlla qui per la migliore soluzione: http://www.krazzycodes.com/how-to-remove-custom-post-type-taxonomy-base-from-url-in-wordpress/


In realtà funziona, non so come nessuno l'abbia notato prima. Naturalmente questo può interferire con altre pagine se hanno lo stesso permalink, ma in caso contrario questa è un'ottima soluzione.
Aleksandar Đorđević,

4
Ho provato questo. Fornisce il risultato desiderato per i miei collegamenti di tipo post personalizzati. Tuttavia, "cattura" tutte le lumache di tipo POST o PAGE e cerca di risolverle come un URL per il mio tipo di post personalizzato, quindi 404s. (sì, ho salvato i permalink).
Matt Keys,

4
Questo non funziona Fornisce 404 anche quando hai aggiornato i permalink.
Christine Cooper

3
Ancora una volta, anche dopo aver salvato nuovamente le impostazioni del permalink, i post e le pagine non funzionano più (404)
amklose,

1
Questa soluzione funziona per rimuovere la lumaca dall'URL. Ma le pagine dell'archivio non funzionano più.
Annapurna,

13

Ho provato a capirlo non molto tempo fa e la risposta breve da quello che so è no . Almeno non dall'argomento riscrittura.

La lunga spiegazione diventa evidente se guardi il codice reale della riga 1454register_post_type in wp-Includes / post.php :

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

Puoi vederlo come prefisso $args->rewrite['slug']al %$post_type%tag di riscrittura. Si potrebbe pensare "impostiamo la lumaca su nullallora" fino a quando si guardano alcune righe:

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

Puoi vedere che la funzione si aspetta sempre un valore di lumaca che non è vuoto e che altrimenti utilizza il tipo di post.


Grazie @JanBeck. C'è una ragione principale per l'esistenza di questo? Perché non hackerare questo file core con una condizione per omettere determinati tipi di post da questa regola?
Ben Racicot,

9
Dovresti assegnare la risposta a Jan Beck. WordPress ha bisogno della lumaca post_type per indirizzare correttamente le richieste. Questa regola impedisce conflitti di denominazione tra le pagine WP native (che vengono visualizzate senza la lumaca) e qualsiasi tipo di post personalizzato. Se elimini la lumaca, WordPress non conoscerà la differenza tra una pagina chiamata "picnic" e un evento (tipo di post personalizzato) chiamato "picnic".
dswebsme,

3
@dswebsme D'accordo, ma ci sono situazioni in cui è assolutamente necessario modificare l'URL. Quindi, a parte il motivo per cui non puoi nativamente e non dovresti, come fai in modo così efficiente?
Ben Racicot,

7

In risposta alla mia precedente risposta : puoi ovviamente impostare il rewriteparametro su falsequando registri un nuovo tipo di post e gestire tu stesso le regole di riscrittura

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

Puoi vedere che la add_permastructchiamata ora non include più la lumaca. Ho testato due scenari:

  1. Quando ho creato una pagina con il "calendario" della lumaca, quella pagina viene sovrascritta dall'archivio del tipo di post che utilizza anche la lumaca "calendario".

inserisci qui la descrizione dell'immagine

  1. Quando ho creato una pagina con la lumaca "my-event" e un evento (CPT) con la lumaca "my-event", viene visualizzato il tipo di post personalizzato.

inserisci qui la descrizione dell'immagine

  1. Anche altre pagine non funzionano. Se guardi l'immagine qui sopra, diventa chiaro perché: la regola del tipo di post personalizzato corrisponderà sempre a una lumaca di pagina. Poiché WordPress non ha modo di identificare se si tratta di una pagina o di un tipo di post personalizzato che non esiste, restituirà 404. Ecco perché è necessario uno slug per identificare la pagina o il CPT. Una possibile soluzione sarebbe quella di intercettare l'errore e cercare una pagina che potrebbe esistere in modo simile a questa risposta .

Quindi, se l'obiettivo è rimuovere la lumaca per CPT, non potremmo nominare il CPT qualcosa di unico che non si scontrerebbe dal momento che non sarà mai visto nell'URL? O il post-name è il possibile conflitto se lo stesso nome di una pagina?
Ben Racicot,

Ho aggiornato la mia risposta per dimostrare che questo effettivamente interrompe tutte le pagine. Senza una lumaca, WP cercherà un CPT anziché una pagina e, se non lo trova, restituirà un errore. Quindi in realtà non è correlato al post-nome.
Jan Beck,

1
Vedo. Dovrebbero esserci delle regole di riscrittura che aggiungono '-1' a futuri URL in conflitto come post WP nativi e pagine. Ho creato un biglietto trac core.trac.wordpress.org/ticket/34136#ticket amerebbe i tuoi pensieri.
Ben Racicot,

7

Guardando le risposte qui penso che ci sia spazio per una soluzione migliore che combina alcune cose che ho imparato sopra e aggiunge il rilevamento automatico e la prevenzione di duplicati post lumache.

NOTA: assicurati di cambiare "custom_post_type" per il tuo nome CPT nel mio esempio di seguito. Ci sono molte occorrenze e un 'trova / sostituisci' è un modo semplice per catturarle tutte. Tutto questo codice può andare nel tuo function.php o in un plugin.

Passaggio 1: disabilita le riscritture sul tipo di post personalizzato impostando le riscritture su "false" quando registri il post:

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

Passaggio 2: aggiungi manualmente le nostre riscritture personalizzate nella parte inferiore delle riscritture di WordPress per il nostro tipo_cartella_postale

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 esigenze, è possibile che si desideri modificare le riscritture di cui sopra (disabilitare trackback? Feed ?, ecc.). Questi rappresentano i tipi "predefiniti" di riscritture che sarebbero stati generati se non si disabilitassero le riscritture nel passaggio 1

Passaggio 3: Rendi nuovamente permalink il tuo tipo di post personalizzato "carino"

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 (duplicato) in conflitto in un altro tipo di post che creerà una situazione in cui solo uno di loro può caricare quando viene richiesta la pagina.

Passaggio 4: prevenire duplicati post slug

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

NOTA: questo aggiungerà la stringa '-duplicate' alla fine di qualsiasi lumaca duplicata. Questo codice non può impedire le lumache duplicate se esistono già prima dell'implementazione di questa soluzione. Assicurati di controllare prima i duplicati.

Mi piacerebbe avere notizie da chiunque lo provi per vedere se ha funzionato bene anche per loro.


L'ho appena provato e sembra che stia funzionando finora.
Christine Cooper

Era fiducioso per questo approccio, ma mi dà un 404 sui miei post CPT, anche dopo aver salvato i permalink.
Garconis,

Mi dispiace che non abbia funzionato per te Garconis. Ne avevo parlato con qualcun altro qualche tempo fa e avevano anche problemi con questo sul loro sito. Mi sembra di ricordare che importava se i tuoi post sul blog hanno un prefisso su di essi. Sul sito l'ho sviluppato per i post del blog che utilizzano la struttura del permalink: / blog /% postname% /. Se non hai un prefisso nei post del tuo blog ed è accettabile farlo, provalo e fammi sapere come va!
Matt Keys,

2
Questo ha funzionato per me. A differenza di altre soluzioni sulla pagina, non ha interrotto le pagine normali o il layout del blog e non ha causato reindirizzamenti infiniti. Mostra anche l'URL corretto nell'area "Permalink" durante la modifica di quelle pagine cpt. La soluzione abbastanza buona qui, l'unico avvertimento è che la pagina di archivio non funziona. RICORDA di sostituire "custom_post_type" e di aggiornare successivamente i permalink .
Radley Sustaire,

@MattKeys, le impostazioni predefinite Permalink hanno una struttura personalizzata di /%category%/%postname%/. Quando aggiungi il tuo codice, le lumache CPT sembrano OK (sebbene manchi la barra finale) ... e anche il controllo dei conflitti funziona. Ma il post effettivo risulta su una 404.
Garconis,

1

Non hai bisogno di così tanto hard-code. Usa solo plugin leggeri:

Ha opzioni personalizzabili.


Ora so perché sei stato sottoposto a downgrade, impedisce la normale risoluzione dei collegamenti alle pagine. Non l'ho visto perché stavo ricevendo copie cache delle pagine esistenti nonostante l'aggiornamento.
Walf,

@Walf Puoi parlarmi in dettaglio del problema?
T.Todua,

I seguenti collegamenti a pagine (che non erano il tipo di post personalizzato) dal menu principale davano 404 errori, come se la pagina non esistesse; questo è tutto.
Walf,

@Walf puoi darmi qualche esempio di URL della tua occasione? (puoi coprire il nome di dominio se vuoi, ho solo bisogno di un esempio) grazie, lo aggiornerò
T.Todua,

1

Ho avuto gli stessi problemi qui e sembra che non ci siano movimenti sul sito di wordpress. Nella mia particolare situazione in cui per singoli blogposts era necessaria questa soluzione / struttura / blog /% postname% /

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

è finito in un mucchio di 404 secondi

Ma insieme a questo meraviglioso approccio, che non utilizza il backend permalink strukture per il blogpost, alla fine funziona come un incantesimo. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Grazie mille.


0

e possiamo apportare alcune modifiche alla funzione sopra menzionata:

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

per:

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 giusto valore post_type.



0

Per chiunque stia leggendo ciò che ha avuto problemi con i post dei bambini come me ho scoperto che il modo migliore era quello di aggiungere le tue regole di riscrittura.

Il problema principale che stavo riscontrando era che WordPress tratta il reindirizzamento da pagine a 2 livelli (post secondari) in modo leggermente diverso rispetto a 3 livelli profondi (post secondari).

Ciò significa che quando ho / post-type / post-name / post-child / posso usare / post-name / post-child e mi reindirizzerà a quello con post-type davanti ma se ho post-type / post-name / post-child / post-grandchild quindi non posso usare post-name / post-child / post-grandchild.

Dando un'occhiata alle regole di riscrittura sembra che corrisponda a cose diverse dal nome di pagina al primo e al secondo livello (penso che il secondo livello corrisponda all'allegato) e quindi faccia qualcosa lì per reindirizzarti al post corretto. A tre livelli di profondità non funziona.

La prima cosa che devi fare è rimuovere il link del tipo di post anche dai bambini. Questa logica dovrebbe accadere qui se guardi la risposta di Nate Allen sopra:

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

Io stesso ho usato un mix di diversi condizionali per verificare se la posta avesse figli e quant'altro per arrivare al giusto permalink. Questa parte non è troppo complicata e troverai esempi di persone che lo fanno altrove.

Il passo successivo però è dove le cose cambiano dalla risposta data. Invece di aggiungere elementi alla query principale (che ha funzionato per i post personalizzati e i loro figli, ma non per gli altri figli) ho aggiunto una riscrittura che è andata in fondo alle regole di WordPress in modo che se il nome di pagina non è stato estratto e stava per colpire un 404 farebbe un ultimo controllo per vedere se una pagina nel tipo di post personalizzato aveva lo stesso nome, altrimenti avrebbe eliminato il 404.

Ecco la regola di riscrittura che ho usato supponendo "evento" 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 sono riuscito a trovare nient'altro che avesse a che fare con i post dei figli dei bambini e rimuovere la lumaca da quelli.


Sembra che ci sia un refuso nella regex. Tra '(:' a '?' È necessario per usarlo come sottotatro non catturante => '(?:'. Il terzo? Sembra fuori posto in quanto consente un primo sottopattern vuoto. Probabilmente dovrebbe essere posizionato tra (e:. Senza questo errore di battitura, l'espressione sarà la stessa di quella che si può trovare per il tipo di post incorporato 'page'.
jot
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.