web-dev-qa-db-ja.com

プラグインの範囲内で、いつ、どこで、そしてどこのようにして書き換えルールを適切にフラッシュするか？

書き換えルールが正しくフラッシュされないというちょっと変わった問題があります。

私はflush_rewrite_rules();とflush_rewrite_rules(true);を使ってみました。

私はまた$wp_rewrite->flush_rules();と$wp_rewrite->flush_rules(true);を使って$wp_rewriteをグローバル化することを試みました

どちらも書き換え規則を正しくフラッシュしていないようです。これらの呼び出しは、呼び出されると実際に書き換え規則をフラッシュしています。これをどうやって知るのですか？ デバッグリライトルールフラッシュのための解決策の使用 。

現在、プラグインのアクティブ化とプラグインの非アクティブ化に関する書き換えルールをフラッシュしています。問題ありません。

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

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

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

カスタム投稿の種類は正しく正しく登録されています。私は確かにそれが問題ではないことを知っています。

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

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

何らかの理由で、書き換え規則が正しくフラッシュされていません。前述したように、カスタム投稿タイプの単数形またはアーカイブ形式のセクションにアクセスすると404エラーが返されるためです。

奇妙なことに、管理用パーマリンク設定ページにアクセスし、フロントエンドに戻ってカスタム投稿タイプの単数形またはアーカイブ形式のセクションを表示するだけでは、予想通りに魔法のように機能します。

管理パーマリンクの設定ページで、書き換え規則が適切にフラッシュされないようにしていないのはどういうことですか。

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

WordPressに書き換えルールをフラッシュしてもすべてのルールがフラッシュされなくなるという特定のポイントはありますか？

admin_menu - WordPress管理にプラグイン設定ページが追加されました。

add_options_page() - 設定メニューの下にプラグイン設定ページが追加されました。

設定ページはadd_options_page()のコールバックに表示されます。これは、$_POSTがプラグイン設定の更新と書き換え規則のフラッシュのために処理される場所でもあります。

これはすでに長い質問であるため、有効な答えを生み出すのを支援するために、オフサイトのリンクでコードブロックを提供しても構わないでしょう。

custom-post-typesplugin-developmentpermalinksrewrite-rulessettings
10
Michael Ecklund

書き換えルールをフラッシュするのに最適な場所は、プラグインの有効化/無効化です。

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

コーデックスの記事を参照してください

事前にお詫び申し上げます、私はあなたの質問を通してそれをずっと終わらせなかった、それでこれはクッキーカッター応答のビットです。

4
helgatheviking

あなたのコードを見ずに、何が悪いのかを見分けるのは困難です。しかし、いくつかの設定を保存した後は、以下に示すように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);
    }
}


設定ページのどこかにオプションを設定するか、正確には設定を保存する過程のどこかにオプションを設定する必要があります。毎回ルールをフラッシュしたくないので、オプションなしでそれをするのは悪いです。


注： 未テスト

4
Nicolai

私は、プラグインのオプション設定を読み、ユーザーが指定した設定に基づいて必要なカスタム投稿タイプを作成する責任がある投稿タイプクラスファイルを持っていました。

この投稿タイプのクラスファイルはフックinitにロードされました。

私がしなければならないことは、プラグイン設定を更新し、それから書き換え規則をフラッシュすることだけだったと考えました。 post typesクラスはすでにプラグイン設定に基づいてロードされているので。しかし管理ページでは、それらはinitフックの後にロードされます。

設定はまだ実際には設定されていないため、投稿の種類は実際には登録されませんでした。投稿タイプ登録クラスは、投稿タイプが登録されていないため、途中で終了しました。

解決策は以下のとおりです。

  1. プラグイン設定を更新してください。
  2. 新しい書き換え規則が作成されるように、投稿タイプクラスファイルをここで1回だけロードします。
  3. 書き換えルールをフラッシュします。

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

今後、投稿タイプはinitフックにロードされ、すでに設定が指定されているので、投稿タイプを作成して適切な書き換え規則と組み合わせることができます。

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

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

それで、すべてが確実にフラッシュされるようにするために...

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

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

ステップ3）ページはプラグインの設定ページにリダイレクトします。原因：... 3回目以降のフラッシュ（初期フラッシュと同じ - プラグインの設定ページにアクセスしたときに自動的に行われる）

私はこれが実用的な解決策であるとは言っていません、しかしそれは私のために働きました。非常に奇妙な問題で、ほとんどの場合、私のコーディングインフラストラクチャに関係しています。

3
Michael Ecklund

@ 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();
}
1
stillatmylinux

私はSOLUTION WASを見つけました：

global $wp_rewrite; $wp_rewrite->flush_rules(); $wp_rewrite->init();
0
T.Todua

私は全く同じ問題を抱えていました。私のプラグインには、動的に作成される投稿タイプがあります。したがって、それらはactivation_hookの間にregister_post_type()を介して静的メソッドに登録することはできず、したがってこのフックの間に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);
}
}

欠点：

  • register_post_type()の間にWPが生成する正確な書き換え規則にある程度依存します。
  • 各ページの読み込み中にフラッシュが必要かどうかを確認すると、オーバーヘッドが発生します。

利点：

  • 投稿タイプを表すクラスに完全にカプセル化されています。
  • 本当に必要な場合にのみ書き換え規則をフラッシュします。

initとactivation_hookの両方の間に呼び出すことができる静的関数にあなたの投稿タイプを登録できない場合にのみこれを使用してください。

register_post_type()中に生成された書き換え規則がどのように見えるかへの依存は、テストif(strpos($key, $args['rewrite']['slug'] ) === 0)をもっと複雑なもの、すなわち正規表現に置き換えることで軽減できます。

0
cgogolin