リライトルールが正しくフラッシュされないという奇妙な問題が発生しています。

私が使って試してみましたflush_rewrite_rules();とflush_rewrite_rules(true);。

私もグローバル化しようとした$wp_rewrite使用$wp_rewrite->flush_rules();と$wp_rewrite->flush_rules(true);

どちらも書き換えルールを正しくフラッシュしていないようです。これらの呼び出しは、呼び出されたときに実際に書き換えルールをフラッシュしています。どうすればわかりますか？書き換えルールのフラッシュをデバッグするためのソリューションの使用。

現在、プラグインのアクティブ化と非アクティブ化でフラッシュされた書き換えルールがあります。そこに問題はありません。

ユーザーがプラグインを設定するためのプラグイン管理設定ページがあります。一部の設定はパーマリンク構造を調整するため、プラグイン管理設定ページの[設定を保存]で書き換えルールをフラッシュする必要があります。（標準を使用update_option();）設定を保存します。

指定した設定に応じて、ユーザーが指定した設定と一致するカスタム投稿タイプが作成されることに注意したいと思います。したがって、設定が保存された直後に書き換えルールをフラッシュする必要があります。これは、物事が適切に機能していない場所です。

によって提供された書き換えルールをデバッグするための上記のリンクソリューションは、@toscho大量の書き換えルールをフラッシュしていることを示しています。ただし、カスタム投稿タイプの単一アイテム、さらにはカスタム投稿タイプのアーカイブにアクセスすると、それぞれが404エラーとして返されます。

カスタム投稿タイプが正しく適切に登録されている。それが問題ではないことは確かです。

プラグイン管理ページの設定を保存するとすぐに続きます。カスタム投稿タイプが作成され、パーマリンク構造が調整され、すべての書き換えルールがフラッシュされます。

その後、カスタム投稿タイプは常に読み込まれinit、通常どおりに読み込まれます。

なんらかの理由で、前述のように、カスタム投稿タイプの単一セクションまたはアーカイブセクションにアクセスすると404エラーが返されるため、書き換えルールが適切にフラッシュされません。

奇妙な部分ですが、管理パーマリンク設定ページにアクセスし、フロントエンドに戻ってカスタム投稿タイプの単一セクションまたはアーカイブセクションを表示するだけの場合は、期待どおりに魔法のように機能します。

その管理パーマリンク設定ページは、私が実行していないことで、書き換えルールが適切にフラッシュされ、私のものはそうでないことを可能にしますか？

つまり、一時的な解決策として、プラグインの管理設定ページを保存した後、ユーザーを管理パーマリンク設定ページにリダイレクトしていますが、これは理想的な解決策ではありません。私は、プラグインのコード内で適切にフラッシュする書き換えルールを好みます。

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. 書き換えルールをフラッシュします。

（以前は... step2がありませんでした-上記のように...）

これ以降、ポストタイプはinitフックにロードされ、設定がすでに指定されているため、ポストタイプを作成して適切な書き換えルールとペアにすることができます。

理由は何であれ、上記の3つのステップを実行した後、現在のページにリダイレクトするJavaScript呼び出しを追加する必要がありました。

またflush_rewrite_rules();、プラグインの管理設定ページにへの呼び出しを追加する必要がありました。

すべてを確実にフラッシュするために...

ステップ1）プラグインの管理設定ページに移動します。-初期フラッシュ。

ステップ2）プラグイン設定を更新します。-2番目のフラッシュ。

ステップ3）ページはプラグインの設定ページにリダイレクトします。発生させる... 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)をより精巧なもの、つまり正規表現に置き換えることで、見た目中に生成される書き換えルールへの依存を軽減できます。