Eliminar slug de las URL de publicación de tipo de publicación personalizada

48

Parece que todos los recursos web se basan en el tema de eliminar un mensaje personalizado tipo slug

yourdomain.com/CPT-SLUG/post-name 

ahora son soluciones muy desactualizadas que a menudo hacen referencia a instalaciones anteriores a WP versión 3.5. Una común es:

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

dentro de su función register_post_type. Esto ya no funciona y es engañoso. Así que le pido a la comunidad en el tercer trimestre de 2018 al borde de WordPress 5 ...

¿Cuáles son las formas modernas y eficientes de eliminar el mensaje Tipo de publicación de la URL de una publicación de tipo de publicación personalizada desde el argumento de reescritura o en cualquier otro lugar?

ACTUALIZACIÓN: Parece que hay varias formas de obligar a que esto funcione con expresiones regulares. Específicamente, la respuesta de Jan Beck debe estar constantemente dispuesto a monitorear la creación de contenido para garantizar que no se creen nombres de página / publicación en conflicto ... Sin embargo, estoy convencido de que esta es una debilidad importante en el núcleo de WP donde debería ser manejada por nosotros. . Tanto como opción / enlace al crear un CPT o un conjunto avanzado de opciones para enlaces permanentes. Por favor apoye el boleto de la pista.

Nota al pie: Por favor, apoye este ticket de trac mirándolo / promocionándolo: https://core.trac.wordpress.org/ticket/34136#ticket

Ben Racicot
fuente
Supongo que me estoy rascando la cabeza por qué querrías hacer eso. Confuso.
Michael Ecklund
3
@MichaelEcklund porque cualquier CPT que se utiliza para crear páginas web públicas tiene un nombre de slug forzado en la URL. En realidad, hay muchos desarrolladores de wp que buscan eliminar la babosa de forma segura.
Ben Racicot

Respuestas:

60

El siguiente código funcionará, pero solo debes tener en cuenta que los conflictos pueden suceder fácilmente si la babosa para tu tipo de publicación personalizada es la misma que una página o la babosa de la publicación ...

Primero, eliminaremos la babosa del enlace permanente:

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

Solo quitar la bala no es suficiente. En este momento, obtendrás una página 404 porque WordPress solo espera que las publicaciones y páginas se comporten de esta manera. También deberá agregar lo siguiente:

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

Simplemente cambie los "eventos" a su tipo de publicación personalizada y listo. Es posible que deba actualizar sus enlaces permanentes.

Nate Allen
fuente
Gracias. ¿Crees que esto es mejor que crear las reescrituras manualmente? ¿He visto esa solución y puede mantener a raya los conflictos que mencionas?
Ben Racicot
1
Falla con nginx debido a la condición 2 != count( $query->query ). Con nginx, puede tener $ query-> query as array('page' => '', 'name' => '...', 'q' => '...'). Entonces @NateAllen, ¿cuál es el significado de esa condición?
Fabio Montefuscolo
3
Necesitamos algo mejor que esto. Soporte para eliminar el slug integrado para que no podamos crear URL en conflicto más adelante. La forma en que las publicaciones y páginas regulares crean sus URL.
Ben Racicot
3
¿Soy solo yo o esto rompe algunas etiquetas condicionales de wordpress como is_single () y is_singular ()?
rob-gordon
1
Desafortunadamente, esta solución causó algunos enlaces rotos y mi blog dejó de mostrar publicaciones y era solo una página normal. Vea una mejor solución a continuación por Matt Keys.
Radley Sustaire
20

Escriba el siguiente código en el registro de taxonomía.

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

Lo más importante que debe hacer después de cambiar el código

Una vez que haya modificado su documento de taxonomía de tipo de publicación personalizado, intente ir a Configuración> Enlaces permanentes y volver a guardar su configuración , de lo contrario obtendrá una página 404 no encontrada.

Marque aquí para la mejor solución: http://www.krazzycodes.com/how-to-remove-custom-post-type-taxonomy-base-from-url-in-wordpress/

Mayank Dudakiya
fuente
Esto realmente funciona, no sé cómo nadie se dio cuenta de esto antes. Por supuesto, esto puede interferir con otras páginas si tienen el mismo enlace permanente, pero si no es una excelente solución.
Aleksandar Đorđević
44
Probé esto. Da el resultado deseado para mis enlaces de tipo de publicación personalizada. Sin embargo, 'captura' todos los slugs de tipo de publicación POST o PAGE e intenta resolverlos como una URL para mi tipo de publicación personalizada, luego 404s. (Sí, he guardado enlaces permanentes).
Matt Keys
44
Esto no funciona Da 404 incluso cuando has actualizado enlaces permanentes.
Christine Cooper
3
Una vez más, incluso después de volver a guardar la configuración del enlace permanente, las publicaciones y las páginas ya no funcionan (404)
amklose
1
Esta solución funciona para eliminar la babosa de la URL. Pero las páginas del archivo ya no funcionan.
Annapurna
13

Traté de resolver esto no hace mucho y la respuesta breve de lo que sé es que no . No desde dentro del argumento de reescritura al menos.

La larga explicación se hace evidente si nos fijamos en el código real de register_post_typeen wp-includes / línea post.php 1454 :

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

Puede ver los prefijos $args->rewrite['slug']de la %$post_type%etiqueta de reescritura. Uno podría pensar "simplemente configuremos la babosa para nullentonces" hasta que observe algunas líneas:

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

Puede ver que la función siempre espera un valor de slug que no esté vacío y de lo contrario utiliza el tipo de publicación.

Jan Beck
fuente
Gracias @ JanBeck. ¿Hay alguna razón importante para que esto exista? ¿Por qué no piratear este archivo principal con la condición de omitir ciertos tipos de publicación de esta regla?
Ben Racicot
99
Deberías otorgarle la respuesta a Jan Beck. WordPress necesita el slug post_type para enrutar las solicitudes correctamente. Esta regla evita conflictos de nomenclatura entre páginas WP nativas (que se procesan sin el slug) y cualquier tipo de publicación definida personalizada. Si piratea la babosa, WordPress no sabrá la diferencia entre una página llamada "picnic" y un evento (tipo de publicación personalizada) llamado "picnic".
dswebsme
3
@dswebsme De acuerdo, pero hay situaciones en las que absolutamente debe cambiar la URL. Entonces, aparte de por qué no puedes y no deberías hacerlo de forma nativa, ¿cómo lo haces de manera eficiente?
Ben Racicot
7

En respuesta a mi respuesta anterior : por supuesto, podría establecer el rewriteparámetro falseal registrar un nuevo tipo de publicación y manejar las reglas de reescritura usted mismo de esta manera

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

Puede ver que la add_permastructllamada ahora ya no incluye la babosa. Probé dos escenarios:

  1. Cuando creé una página con el "calendario" de babosa, esa página se sobrescribe con el archivo de tipo de publicación que también usa la babosa "calendario".

ingrese la descripción de la imagen aquí

  1. Cuando creé una página con el slug "my-event" y un evento (CPT) con el slug "my-event", se muestra el tipo de publicación personalizada.

ingrese la descripción de la imagen aquí

  1. Cualquier otra página tampoco funciona. Si observa la imagen de arriba, queda claro por qué: la regla de tipo de publicación personalizada siempre coincidirá con una babosa de página. Debido a que WordPress no tiene forma de identificar si es una página o un tipo de publicación personalizada que no existe, devolverá 404. Es por eso que necesita una babosa para identificar la página o el CPT. Una posible solución sería interceptar el error y buscar una página que pueda existir de manera similar a esta respuesta .
Jan Beck
fuente
Entonces, si el objetivo es eliminar el slug para CPT, ¿no podríamos nombrar al CPT como algo único que no colisionaría, ya que de todos modos nunca se verá en la URL? ¿O es el nombre de la publicación el posible conflicto si se nombra igual que una página?
Ben Racicot
He actualizado mi respuesta para mostrar que esto realmente rompe todas las páginas. Sin una babosa, WP buscará un CPT en lugar de una página y, si no lo encuentra, devolverá un error. Entonces, en realidad no está relacionado con el nombre de la publicación.
Jan Beck
1
Veo. Debería haber reglas de reescritura que agreguen '-1' a futuras URL en conflicto como publicaciones nativas de WP vs páginas. He creado un ticket de trac. Core.trac.wordpress.org/ticket/34136#ticket amaría tus pensamientos.
Ben Racicot
7

Mirando las respuestas aquí, creo que hay espacio para una mejor solución que combine algunas cosas que aprendí anteriormente y agregue la detección automática y la prevención de duplicados de postrastos.

NOTA: Asegúrese de cambiar 'custom_post_type' para su propio nombre CPT en mi ejemplo a continuación. Hay muchos sucesos, y un 'buscar / reemplazar' es una manera fácil de atraparlos a todos. Todo este código puede ir en su functions.php o en un complemento.

Paso 1: deshabilite las reescrituras en su tipo de publicación personalizada configurando las reescrituras en 'falso' cuando registre la publicación:

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

Paso 2: agregue manualmente nuestras reescrituras personalizadas en la parte inferior de las reescrituras de WordPress para nuestro 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: Dependiendo de sus necesidades, es posible que desee modificar las reescrituras anteriores (¿deshabilitar trackbacks? Feeds ?, etc.). Estos representan los tipos 'predeterminados' de reescrituras que se habrían generado si no hubiera deshabilitado las reescrituras en el paso 1

Paso 3: vuelva a hacer que los enlaces permanentes a su tipo de publicación personalizada sean 'bonitos'

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: Puede detenerse aquí si no le preocupa que sus usuarios creen una publicación conflictiva (duplicada) en otro tipo de publicación que creará una situación en la que solo uno de ellos puede cargarse cuando se solicita la página.

Paso 4: evitar duplicar las publicaciones de babosas

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: Esto agregará la cadena '-duplicate' al final de cualquier slugs duplicado. Este código no puede evitar las babosas duplicadas si ya existen antes de implementar esta solución. Asegúrese de verificar primero los duplicados.

Me encantaría saber de alguien más que pruebe esto para ver si también les funcionó bien.

Matt Keys
fuente
Solo lo probé y parece que está funcionando hasta ahora.
Christine Cooper
Tenía esperanzas para este enfoque, pero me da un 404 en mis publicaciones de CPT, incluso después de volver a guardar los enlaces permanentes.
Garconis
Lo siento, no te funcionó Garconis. Había estado hablando con alguien más sobre esto hace un tiempo y también estaban teniendo problemas en su sitio. Me parece recordar que importaba si los enlaces permanentes de las publicaciones de tu blog tenían un prefijo. En el sitio que desarrollé esto para las publicaciones de blog están usando la estructura de enlace permanente: / blog /% postname% /. Si no tiene un prefijo en sus publicaciones de blog, y es aceptable que lo haga, ¡pruébelo y dígame cómo funciona!
Matt Keys el
2
Esto funcionó para mí. A diferencia de otras soluciones en la página, no rompió las páginas normales o el diseño del blog, y no causó redireccionamientos infinitos. Incluso muestra la URL correcta en el área "Enlace permanente" al editar esas páginas cpt. Una solución bastante buena aquí, la única advertencia es que la página de archivo no funciona. RECUERDA intercambiar "custom_post_type" y actualizar tus enlaces permanentes después .
Radley Sustaire
@MattKeys, la configuración predeterminada de enlace permanente tiene una estructura personalizada de /%category%/%postname%/. Al agregar su código, los slugs de CPT se ven bien (aunque les falta la barra inclinada) ... y el verificador de conflictos también funciona. Pero la publicación real resulta en un 404.
Garconis
1

No necesita tanto código duro. Simplemente use un complemento ligero:

Tiene opciones personalizables.

T.Todua
fuente
Ahora sé por qué te votaron negativamente, evita que se resuelvan los enlaces normales de la página. No lo vi porque estaba obteniendo copias en caché de las páginas existentes a pesar de la actualización.
Walf
@Walf ¿Puedes contarme el problema en detalle?
T.Todua
Los siguientes enlaces a páginas (que no eran del tipo de publicación personalizada) desde el menú principal dieron 404 errores, como si la página no existiera; Eso es.
Walf
@Walf, ¿puedes darme alguna URL de ejemplo de tu ocasión? (puede cubrir el nombre de dominio si lo desea, solo necesito un ejemplo) gracias, lo actualizaré
T.Todua
1

Tuve los mismos problemas aquí y allá parece que no hay movimiento en el sitio de WordPress. En mi situación particular donde para publicaciones de blog individuales se necesitaba la estructura / blog /% postname% / esta solución

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

terminó en un montón de 404

Pero junto con este maravilloso enfoque, que no está utilizando la estructura de enlace permanente del backend para el blog, finalmente funciona como un encanto. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Gracias un montón.

Friedrich Siever
fuente
0

y podemos hacer algunos cambios en la función mencionada anteriormente:

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

a:

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

para establecer el valor post_type correcto.

Max Kondrachuk
fuente
0

Esto funcionó para mí: 'rewrite' => array('slug' => '/')

Malki Mohamed
fuente
1
Esto no funciona Da 404 incluso cuando has actualizado enlaces permanentes.
Christine Cooper
0

Para cualquiera que haya leído esto y haya tenido problemas con las publicaciones secundarias como yo, encontré que la mejor manera era agregar sus propias reglas de reescritura.

El principal problema que tuve fue que WordPress trata la redirección desde páginas que tienen 2 niveles (publicaciones secundarias) de profundidad de forma un poco diferente de lo que trata las 3 niveles (publicaciones secundarias).

Eso significa que cuando tengo / post-type / post-name / post-child / puedo usar / post-name / post-child y me redirigirá al que tiene post-type al frente, pero si tengo post-type / post-name / post-child / post-grandchild, entonces no puedo usar post-name / post-child / post-grandchild.

Echando un vistazo a las reglas de reescritura, parece que coincide con otras cosas que no sean el nombre de página en el primer y segundo nivel (creo que el segundo nivel coincide con el archivo adjunto) y luego hace algo allí para redirigirlo a la publicación correcta. A tres niveles de profundidad no funciona.

Lo primero que debe hacer es eliminar el enlace de tipo de publicación de los niños también. Esta lógica debería ocurrir aquí si nos fijamos en la respuesta de Nate Allen arriba:

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

Yo mismo usé una combinación de diferentes condicionales para verificar si la publicación tenía hijos y otras cosas para llegar al enlace permanente correcto. Esta parte no es demasiado complicada y encontrarás ejemplos de personas que lo hacen en otros lugares.

Sin embargo, el siguiente paso es donde las cosas cambian de la respuesta dada. En lugar de agregar cosas a la consulta principal (que funcionó para publicaciones personalizadas y sus hijos, pero no para los hijos secundarios), agregué una reescritura que fue al final de las reglas de WordPress para que si el nombre de página no se verificara y estuviera a punto de Si pulsa un 404, haría una última comprobación para ver si una página dentro del tipo de publicación personalizada tenía el mismo nombre; de ​​lo contrario, arrojaría el 404.

Aquí está la regla de reescritura que utilicé suponiendo que 'evento' es el nombre de su 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);

Espero que esto ayude a alguien más, no pude encontrar nada más que tuviera que ver con las publicaciones secundarias y eliminar la babosa de esas.

Moe Loubani
fuente
Parece que hay un error tipográfico en la expresión regular. Se necesita entre '(:' a '?' Para usarlo como subpatrón no capturador => '(?:'. El tercer? Parece fuera de lugar ya que permite un primer subpatrón vacío. Probablemente debería colocarse entre (y:. Sin este error tipográfico, la expresión será la misma que se puede encontrar para el tipo de página
incorporada