다시 쓰기 규칙이 올바르게 플러시되지 않는 이상한 문제가 있습니다.

나는 flush_rewrite_rules();and을 사용해 보았습니다 flush_rewrite_rules(true);.

나는 또한 세계화 시도 $wp_rewrite사용 $wp_rewrite->flush_rules();하고$wp_rewrite->flush_rules(true);

둘 중 어느 것도 다시 쓰기 규칙을 올바르게 플러시하지 않는 것 같습니다. 이러한 호출은 실제로 호출 될 때 다시 쓰기 규칙을 삭제합니다. 이것을 어떻게 알 수 있습니까? 대한 솔루션을 사용하여 재 작성 규칙 세척 디버깅을 .

현재 플러그인 활성화 및 플러그인 비활성화에 대해 다시 쓰기 규칙이 있습니다. 문제가 없습니다.

사용자가 플러그인을 구성 할 수있는 플러그인 관리 설정 페이지가 있습니다. 일부 설정은 퍼머 링크 구조를 조정하므로 플러그인 관리 설정 페이지 "설정 저장"에서 다시 쓰기 규칙을 삭제해야합니다. update_option();설정을 저장하기 위해 (표준 사용 ).

지정된 설정에 따라 사용자 지정 게시물 유형이 사용자 지정 설정과 일치하도록 생성됩니다. 따라서 설정을 저장 한 후 다시 쓰기 규칙을 플러시해야합니다. 이것은 제대로 작동하지 않는 곳입니다.

제공되는 다시 쓰기 규칙을 디버깅하기위한 위의 링크 솔루션은 @toscho수많은 다시 쓰기 규칙을 플러시하고 있음을 표시합니다. 그러나 사용자 정의 게시물 유형 단수 항목 또는 해당 문제에 대한 사용자 정의 게시물 유형 아카이브를 방문하면 각각 404 오류로 반환됩니다.

맞춤 게시물 유형이 올 바르고 적절하게 등록되었습니다. 나는 그것이 문제가 아니라는 것을 알고 있습니다.

플러그인 관리 페이지 설정에 따라 즉시 저장합니다. 사용자 지정 게시물 유형이 생성되고 퍼머 링크 구조가 조정되며 모든 다시 쓰기 규칙을 비 웁니다.

그런 다음 맞춤 게시물 유형은 항상로드되고 init일반과 같이 로드됩니다 .

어떤 이유로 든, 다시 쓰기 규칙이 올바르게 플러시되지 않습니다. 이전에 말했듯이 사용자 정의 게시물 유형의 단일 또는 아카이브 섹션을 방문하면 404 오류가 발생하기 때문입니다.

이제 이상한 부분은 단순히 관리 permalinks 설정 페이지를 방문한 다음 프런트 엔드로 돌아가서 사용자 정의 게시물 유형의 단일 또는 아카이브 섹션을 보려면 마술처럼 예상대로 작동합니다.

재 작성 규칙을 적절하게 플러시하고 그렇지 않은 관리 퍼머 링크 설정 페이지에서 수행하지 않은 작업은 무엇입니까?

즉, 임시 솔루션으로 플러그인 관리 설정 페이지를 저장 한 후 사용자를 관리 퍼머 링크 설정 페이지로 리디렉션하고 있지만 이상적인 솔루션은 아닙니다. 플러그인 코드 내에서 다시 쓰기 규칙을 올바르게 플러시하는 것이 좋습니다.

다시 쓰기 규칙을 플러시해도 더 이상 모든 규칙을 플러시하지 않는 특정 지점이 WordPress에 있습니까?

admin_menu -플러그인 설정 페이지가 WordPress 관리에 추가되었습니다.

add_options_page() -플러그인 설정 페이지가 설정 메뉴에 추가되었습니다.

에 대한 콜백에서 설정 페이지가 렌더링됩니다 add_options_page(). 또한 $_POST플러그인 설정 업데이트 및 재 작성 규칙 플러시를 위해 처리됩니다.

이것은 이미 긴 질문이므로 유효한 답변을 생성하는 데 도움이되는 오프 사이트 링크에 ​​코드 블록을 제공하려고합니다.

다시 쓰기 규칙을 플러시하는 가장 좋은 장소는 플러그인 활성화 / 비활성화입니다.

function myplugin_activate() {
    // register taxonomies/post types here
    flush_rewrite_rules();
}

register_activation_hook( __FILE__, 'myplugin_activate' );

function myplugin_deactivate() {
    flush_rewrite_rules();
}
register_deactivation_hook( __FILE__, 'myplugin_deactivate' );

코덱스 기사를 참조하십시오

미리 사과 드리지만, 귀하의 질문을 완전히 끝내지 않았으므로 이것은 약간의 쿠키 커터 응답입니다.

코드를 보지 않고 무엇이 잘못되었는지 말하기가 어렵습니다. 그러나 일부 설정을 저장 한 후 admin_init아래 그림과 같이 다시 쓰기 규칙을 플러시하는 것이 좋습니다.

암호:

add_action('admin_init', 'wpse_123401_plugin_settings_flush_rewrite');
function wpse_123401_plugin_settings_flush_rewrite() {
    if ( get_option('plugin_settings_have_changed') == true ) {
        flush_rewrite_rules();
        update_option('plugin_settings_have_changed', false);
    }
}

설정 페이지에서 설정을 저장하거나 설정을 저장하는 위치에서 옵션을 설정해야합니다. 매번 규칙을 플러시하고 싶지 않기 때문에 옵션없이 수행하는 것은 좋지 않습니다.

참고 : 테스트되지 않은

플러그인의 옵션 설정을 읽고 사용자가 지정한 설정을 기반으로 필요한 사용자 정의 게시물 유형을 생성하는 게시물 유형 클래스 파일이 있습니다.

이 게시물 유형 클래스 파일이 후크에로드되었습니다 init.

플러그인 설정을 업데이트 한 다음 다시 쓰기 규칙을 플러시하는 것만으로도 충분하다고 생각했습니다. 플러그인 유형에 따라 게시물 유형 클래스가 이미로드되었으므로 그러나 관리 페이지에서는 init후크 후에로드 됩니다.

설정이 실제로 설정되지 않았기 때문에 게시물 유형이 실제로 등록되지 않았습니다. 게시물 유형 등록 클래스는 등록 된 게시물 유형없이 조기에 종료되었습니다.

해결책은 다음과 같습니다.

1. 플러그인 설정을 업데이트하십시오.
2. 새 재 작성 규칙이 작성되도록 여기에서 게시물 유형 클래스 파일을 한 번만로드하십시오.
3. 다시 쓰기 규칙을 비 웁니다.

(이전 ... 2 단계가 누락되었습니다. 위에서 언급 한대로 ...)

이제부터 게시물 유형이 init후크에 로드되고 이미 지정된 설정이 적용되어 게시물 유형을 작성하고 적절한 다시 쓰기 규칙과 쌍을 이룰 수 있습니다.

어떤 이유로 든 위의 세 단계를 수행 한 후 현재 페이지로 리디렉션하려면 JavaScript 호출을 추가해야했습니다.

또한 flush_rewrite_rules();플러그인의 관리 설정 페이지 에서 호출을 추가해야했습니다 .

모든 것을 플러시하기 위해 ...

1 단계) 플러그인 관리 설정 페이지로 이동합니다. -초기 세척.

2 단계) 플러그인 설정을 업데이트합니다. -두 번째 플러시.

3 단계) 페이지가 플러그인 설정 페이지로 리디렉션됩니다. ... 세 번째 및 최종 플러시 발생 (초기 플러시와 동일-플러그인 설정 페이지를 방문하면 자동으로 완료)

나는 이것이 실용적인 해결책이라고 말하지는 않지만 그것은 나를 위해 일했다. 매우 이상한 문제이며 대부분 코딩 인프라와 관련이 있습니다.

@ tazo-todua 다중 사이트를 사용할 때도 효과가있었습니다.

add_action( 'wpmu_new_blog', 'set_my_permalink_structure', 11, 2 );

function set_my_permalink_structure( $blog_id ) {

    switch_to_blog( $blog_id );

    global $wp_rewrite;
    $wp_rewrite->set_permalink_structure( '/%postname%/' );
    $wp_rewrite->flush_rules();
    $wp_rewrite->init();

    restore_current_blog();
}

내가 찾은 해결책은 다음과 같습니다.

global $wp_rewrite; $wp_rewrite->flush_rules(); $wp_rewrite->init();

나는 정확히 같은 문제가 있었다. 플러그인에는 동적으로 생성되는 게시물 유형이 있습니다. 따라서이 register_post_type()메소드는 정적 메소드 를 통해 등록 할 수 없으므로이 후크 중에 실행될 activation_hook때 아직 활성화되지 않습니다 flush_rewrite_rules()(일반적으로 권장 되는 다시 쓰기 규칙).

결국에 얻을 수있는 가장 깨끗한 해결책은 게시물 유형을 등록한 후 다시 쓰기 규칙을 플러시하는 것이었지만 실제로 플러시가 실제로 필요한 경우에만 (작업이 느리기 때문에) 가능합니다. 필자의 경우 실제로 단일 기본 클래스에서 상속되는 몇 가지 사용자 정의 게시물 유형이 있으므로 플러싱을 수행하는 코드를 구현하는 것이 바람직했습니다.

플러싱이 필요한지 여부는 get_option( 'rewrite_rules' )다음 의 출력을 확인하여 결정할 수 있습니다 .

class MyPostTypeClass {

public final function register_as_custom_post_type() {
    ...   //do all the setup of your post type here     
    $args = array(
                  ... //populate the other arguments as you see fit
                  'rewrite' => array('slug' => 'slug-of-your-post-type')
                 );
    register_post_type('post-type-name-of-your-post-type', $args );

    $rewrite_rules_must_be_fluhed = true;
    foreach( get_option( 'rewrite_rules' ) as $key => $rule)
        if(strpos($key, $args['rewrite']['slug'] ) === 0)
        {
            $rewrite_rules_must_be_fluhed = false;
            break;
        }
    if($rewrite_rules_must_be_fluhed)
        flush_rewrite_rules(true);
}
}

단점 :

• WP가 생성하는 동안 정확한 다시 쓰기 규칙이 어느 정도까지 적용되는지에 따라 다릅니다 register_post_type().
• 각 페이지를로드 할 때 플러시가 필요한지 확인하면 약간의 오버 헤드가 발생합니다.

장점 :

• 게시물 유형을 나타내는 클래스에 완전히 캡슐화되었습니다.
• 실제로 필요한 경우에만 다시 쓰기 규칙을 플러시하십시오.

게시 유형을 ! init및activation_hook

register_post_type()모양 을 만드는 동안 생성 된 다시 쓰기 규칙에 대한 의존성 은 테스트 if(strpos($key, $args['rewrite']['slug'] ) === 0)를 좀 더 정교한 것, 즉 정규식 으로 대체하여 완화 할 수 있습니다 .