以下代码将起作用,但是您只需要记住,如果您自定义帖子类型的信息与页面或帖子的信息相同,则冲突很容易发生...

首先,我们将从永久链接中删除该子弹:

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

仅仅去除弹头是不够的.现在,您将获得404页面,因为WordPress只希望帖子和页面具有这种行为.您还需要添加以下内容:

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

只需将"事件"更改为自定义帖子类型,就可以了.您可能需要刷新永久链接.

The following code will work, but you just have to keep in mind that conflicts can happen easily if the slug for your custom post type is the same as a page or post's slug...

First, we will remove the slug from the 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 );

Just removing the slug isn't enough. Right now, you'll get a 404 page because WordPress only expects posts and pages to behave this way. You'll also need to add the following:

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

Just change "events" to your custom post type and you're good to go. You may need to refresh your permalinks.

将以下代码写入分类法注册.

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

代码更改后必须要做的最重要的事情

更改自定义帖子类型分类法文档后,请尝试转到设置>固定链接并重新保存设置,否则您将获得404页面找到.

Write following code into the taxonomy registration.

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

Most important thing that you have to do after code changing

After you’ve altered your custom post type taxonomy document, try to go to Settings > Permalinks and re-save your settings, else you will get 404 page not found.

不久前我试图弄清楚这一点,据我所知,简短的回答是否.至少不是在rewrite参数内部.

如果您查看register_post_type的实际代码,那么详细的解释就会很明显.wp-includes/post.php#L1454"> wp-includes/post.php第1454行:

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

您可以看到它在$args->rewrite['slug']重写标签的前面加上%$post_type%.可能会想到"然后将子弹设置为null",直到您看到几行:

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

您可以看到函数始终期望的值不是空值,否则将使用post类型.

I tried to figure this out not long ago and the short answer from what I know is no. Not from within the rewrite argument at least.

The long explanation becomes apparent if you look at the actual code of register_post_type in wp-includes/post.php line 1454:

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

You can see it prefixes $args->rewrite['slug'] to the %$post_type% rewrite tag. One could think "let's just set the slug to null then" until you look a few lines up:

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

You can see that the function always expects a slug value that is not empty and otherwise uses the post type.

针对我之前的回答: 您当然可以在注册新帖子类型时将rewrite参数设置为false并自己处理重写规则

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

您可以看到add_permastruct调用现在不再包含该段. 我测试了两种情况:

1. 当我使用" calendar"标签创建页面时,该帖子类型存档也会覆盖该页面,该帖子也使用" calendar"模块.

2. 当我创建一个带有"my-event"标签的页面和一个带有"my-event"标签的事件(CPT)时,将显示自定义帖子类型.

3. 其他任何页面也不起作用.如果您看一下上面的图片,就会清楚为什么:自定义帖子类型规则将始终与页面提示匹配.由于WordPress无法识别是页面还是不存在的自定义帖子类型,因此它将返回404.这就是为什么您需要一个小人物来识别页面或CPT的原因. 一种可能的解决方案是拦截错误并查找可能与该答案类似的页面. li>

In response to my previous answer: you could of course set the rewrite parameter to false when registering a new post type and handle the rewrite rules yourself like so

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

You can see the add_permastruct call now doesn't include the slug anymore. I tested two scenarios:

1. When I created a page with the slug "calendar" that page is overwritten by the post type archive which also uses the "calendar" slug.

2. When I created a page with the slug "my-event" and an event (CPT) with the slug "my-event", the custom post type is displayed.

3. Any other pages do not work either. If you look at the picture above it becomes clear why: the custom post type rule will always match against a page slug. Because WordPress has no way of identifying if it's a page or a custom post type that does not exist, it will return 404. That's why you need a slug to identify either the page or CPT. A possible solution would be to intercept the error and look for a page that might exist similar to this answer.

插件综述

快到2020年了,其中许多答案都行不通.这是我自己对当前选项的总结:

• Matt Keys答案 似乎是唯一正确的选择您需要自定义代码解决方案.我发现所有插件都无法执行此处列出的所有功能,尤其是重复检查.如果有人想采用这种方法,那么对于插件来说,这似乎是一个非常好的机会.
• Permalink Manager Lite
  • 我尝试过的最好的免费插件.
  • 完全控制所有Page/Post/CPT完整的永久链接结构,并使它们相同. GUI是迄今为止功能最丰富的.
  • 还允许对每个帖子进行完全覆盖,并让您查看原始/默认设置,并在需要时重置为默认设置.
  • 支持多站点.
  • 不不检查帖子类型之间是否重复,这很可悲.如果页面和CPT具有相同的URL,则页面将加载且CPT无法访问.没有警告或错误,您只需要手动检查重复项即可.
  • 所有分类功能均在PRO版本中.升级na很重.
• 自定义永久链接
  • 免费版本有很多作用.专业版永久不支持分类学永久链接和高级支持.
  • 允许您更改任何单个页面/帖子/CPT的完整永久链接.
  • 支持多站点.
  • 不允许允许您更改默认结构,因此您的"自定义帖子类型"仍为example.com/cpt-slug/post-title,但您可以单独更改它们.
  • 不不检查帖子类型之间是否重复,这很可悲.
• 自定义帖子类型的永久链接
  • 允许非开发人员用户使用register_post_type
  更改易于更改的内容
  • 不允许允许您更改CPT基本部分-仅更改其后的部分-对于开发人员和此问题中的问题几乎没有用.
• 删除基础段... -已经死了好几年了...请不要使用.

Plugin Roundup

It's almost 2020 and a lot of these answers don't work. Here's my own roundup of the current options:

• Matt Keys answer seems to be the only one on the right track if you want a custom code solution. None of the plugins I found can do everything listed here, especially the duplicate checking. This approach seems like a really good opportunity for a plugin if anyone wanted to take that on.
• Permalink Manager Lite
  • Best of the free plugins I tried.
  • Gives full control over all Page/Post/CPT complete permalink structure and allows them to be the same. The GUI is by far the most feature-rich.
  • Allows full override per-post as well and lets you see what the original/default would be and reset to the default if needed.
  • Supports multi-site.
  • Does not check for duplicates between post types, which is sad. If a page and a CPT have the same URL, the page loads and the CPT is inaccessible. No warnings or errors, you just have to do your own manual checking for duplicates.
  • All taxonomy features are in the PRO version. The upgrade nags are pretty heavy.
• Custom Permalinks
  • The free version does a lot. Taxonomy permalinks and premium support seem to be the only things withheld from the pro version.
  • Allows you to change the full permalink for any individual page/post/CPT.
  • Supports multi-site.
  • Does not allow you to change the default structure so you your Custom Post Types will still be example.com/cpt-slug/post-title but you can change them individually.
  • Does not check for duplicates between post types, which is sad.
• Custom Post Type Permalinks
  • Allows non-developer users to change the things that are easy to change already with register_post_type
  • Does not allow you to change the CPT base slug - only the part that comes after that - so pretty much useless for developers and the issue in this question.
• remove base slug... - dead for several years now... do not use.

您不需要那么多硬代码.只需使用轻量级插件:

• "> 从定制中删除基础子弹发布

它具有可自定义的选项.

You dont need so much hard-code. Just use lightweight plugin:

• Remove Base Slug From Custom Post

It has customizable options.

我们可以对上述功能进行一些更改:

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

至:

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

以设置正确的post_type值.

and we can make some changes to above-mentioned function:

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

to:

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

in order to set right post_type value.

这对我有用: 'rewrite' => array('slug' => '/')

This worked for me: 'rewrite' => array('slug' => '/')

对于像我这样阅读子帖子时遇到麻烦的任何人,我发现最好的方法是添加自己的重写规则.

我遇到的主要问题是WordPress处理深度为2级(子帖子)的页面的重定向与处理深度为3级(子帖子的孩子)的方式有所不同.

这意味着当我拥有/post-type/post-name/post-child/时,我可以使用/post-name/post-child,它将把我重定向到前面有post-type的那个,但是如果我有post-type/post-name/post-child/post-孙子,那么我不能使用post-name/post-child/post-孙子.

看一看重写规则,它看起来像是在第一层和第二层上与页面名称以外的其他东西匹配(我认为第二层与附件匹配),然后在那里进行一些操作以将您重定向到正确的帖子.在三个层次上,它是行不通的.

您需要做的第一件事就是也从子级中删除帖子类型链接.如果您查看上面的内特·艾伦的答案,那么这种逻辑应该在这里发生:

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

我本人使用各种不同的条件来检查帖子是否有孩子以及诸如此类,以便获得正确的永久链接.这部分并不是很棘手,您会在其他地方找到有人这样做的示例.

尽管如此,下一步是从给定的答案发生变化.与其向主要查询中添加内容(该方法适用于自定义帖子及其子级,而不能用于其他子级),我添加了一个重写,该重写进入了WordPress规则的底部,因此如果pagename不检出并且将要命中404,它会做最后一次检查,以查看自定义帖子类型中的页面是否具有相同的名称,否则它将抛出404.

这是我假设'event'是您的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);
 

希望这对其他人有帮助,我找不到与子职位相关的其他东西,并且无法删除其中的子弹.

For anyone reading this that had trouble with child posts like I did I found the best way was to add your own rewrite rules.

The main issue I was having was that WordPress treats the redirect from pages that are 2 levels (child posts) deep a little differently than it treats 3 levels deep (child of child posts).

That means when I have /post-type/post-name/post-child/ I can use /post-name/post-child and it will redirect me to the one with post-type in front but if I have post-type/post-name/post-child/post-grandchild then I can't use post-name/post-child/post-grandchild.

Taking a look into the rewrite rules it looks like it matches for things other than pagename at the first and second levels (I think the second level matches attachment) and then does something there to redirect you to the proper post. At three levels deep it doesn't work.

First thing you need to do is to remove the post type link from children as well. This logic should happen here if you look at Nate Allen's answer above:

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

Myself I used a mix of different conditionals to check if the post had children and whatnot in order to get to the right permalink. This part isn't too tricky and you'll find examples of people doing it elsewhere.

The next step though is where things change from the given answer. Instead of adding things to the main query (which worked for custom posts and their children but not the further children) I added a rewrite that went to the bottom of the WordPress rules so that if pagename didn't check out and it was about to hit a 404 it would do one last check to see if a page within the custom post type had the same name otherwise it would throw out the 404.

Here is the rewrite rule I used assuming 'event' is the name of your 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);

Hope this helps someone else, I couldn't find anything else that had to do with child of child posts and removing the slug from those.

这里也遇到了同样的问题,WordPress网站上似乎没有动静.在我的特定情况下,对于单个博客文章,需要/blog/％postname％/结构来解决此问题

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

以一堆404s结尾

但是,再加上这种绝妙的方法,即没有在博客文章中使用后端永久链接结构,它最终就像魅惑一样工作. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

谢谢.

Had the same problems here and there seems to be no movement on wordpress site. In my particular situation where for single blogposts the structure /blog/%postname%/ was needed this solution

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

ended in a bunch of 404s

But together with this wonderful approach, which is not using the backend permalink strukture for the blogpost it finally works like charme. https://www.bobz.co/add-blog-prefix-permalink-structure-blog-posts/

Thanks a bunch.