다음 코드는 작동하지만 사용자 지정 게시물 유형의 슬러그가 페이지 또는 게시물의 슬러그와 동일하면 충돌이 쉽게 발생할 수 있음을 명심해야합니다 ...

먼저,퍼머 링크에서 슬러그를 제거합니다.

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

슬러그를 제거하는 것만으로는 충분하지 않습니다. WordPress는 게시물과 페이지 만 이러한 방식으로 작동 할 것으로 예상하기 때문에 지금 당장 404 페이지가 표시됩니다. 또한 다음을 추가해야합니다.

 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.

얼마 전에 이것을 알아 내려고했는데 제가 아는 짧은 대답은 아니요 입니다.적어도 다시 쓰기 인수 내에서가 아닙니다.

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;
 

함수는 항상 이 비어 있지 않은 슬러그 값을 예상하고 그렇지 않으면 포스트 유형을 사용함을 알 수 있습니다.

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. 슬러그 "캘린더"가 포함 된 페이지를 만들었을 때 해당 페이지는 "캘린더"슬러그도 사용하는 게시물 유형 아카이브로 덮어 쓰여집니다.

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
  • 제가 시도한 무료 플러그인 중 최고입니다.
  • 모든 페이지/게시물/CPT 완전한 영구 링크 구조를 완전히 제어하고 동일하게 할 수 있습니다. GUI는 가장 풍부한 기능입니다.
  • 게시물별로 전체 재정의를 허용하고 원본/기본값이 무엇인지 확인하고 필요한 경우 기본값으로 재설정 할 수 있습니다.
  • 다중 사이트를 지원합니다.
  • 게시물 유형 간의 중복 여부를 확인하지 않습니다 . 안타깝습니다. 페이지와 CPT의 URL이 동일한 경우 페이지가로드되고 CPT에 액세스 할 수 없습니다. 경고 나 오류가 없으며 중복 여부를 직접 확인하기 만하면됩니다.
  • 모든 분류 기능은 PRO 버전에 있습니다. 업그레이드 잔소리가 꽤 무겁습니다.
• 맞춤 영구 링크
  • 무료 버전은 많은 일을합니다. 분류 영구 링크 및 프리미엄 지원은 프로 버전에서 보류되는 유일한 것 같습니다.
  • 개별 페이지/게시물/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.

이것은 저에게 효과적이었습니다. <코드> '재 작성'=>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-handchild 그러면post-name/post-child/post-handchild를 사용할 수 없습니다.

재 작성 규칙을 살펴보면 첫 번째 및 두 번째 수준에서 페이지 이름 이외의 항목과 일치하는 것처럼 보이며 (두 번째 수준이 첨부 파일과 일치한다고 생각합니다) 적절한 게시물로 리디렉션하기 위해 작업을 수행합니다. 3 단계 깊이에서는 작동하지 않습니다.

첫 번째로해야 할 일은 어린이의 게시물 유형 링크도 제거하는 것입니다. 위의 Nate Allen의 답변을 보면이 논리가 발생해야합니다.

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

자신은 올바른 퍼머 링크로 이동하기 위해 게시물에 하위 항목이 있는지 확인하기 위해 여러 조건문을 혼합하여 사용했습니다. 이 부분은 너무 까다 롭지 않으며 다른 곳에서 수행하는 사람들의 예를 찾을 수 있습니다.

다음 단계는 주어진 답변에서 상황이 바뀌는 것입니다. 기본 쿼리에 항목을 추가하는 대신 (사용자 지정 게시물과 해당 자식에 대해서는 작동하지만 추가 자식에는 적용되지 않음) WordPress 규칙의 맨 아래에있는 재 작성을 추가하여 페이지 이름이 체크 아웃되지 않고 곧 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.

여기에도 같은 문제가 있었고 워드 프레스 사이트에는 움직임이없는 것 같습니다.단일 블로그 게시물의 경우/blog/%postname %/구조가이 솔루션이 필요한 특정 상황에서

https://kellenmace.com/remove-custom-영구 링크의 포스트 유형 슬러그/

404 초로 끝남

하지만 블로그 게시물에 백엔드 영구 링크 구조를 사용하지 않는이 멋진 접근 방식과 함께 마침내 charme처럼 작동합니다. 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.