Najlepszy sposób na flush_rewrite_rules dla niestandardowego typu postu we wtyczce mu-plugins?

Piszę wtyczkę, która tworzy instancję niestandardowego typu posta (między innymi). Jest to wielostanowiskowa wtyczka i żyje w katalogu wtyczek mu .

Jaka jest najlepsza praktyka obsługi flush_rewrite_rules () w tej sytuacji? W przypadku „normalnej” wtyczki zrobiłbyś to w haku aktywacyjnym - co nie będzie możliwe w przypadku wtyczki, której należy użyć, ponieważ te haki nie są dostępne.

Ponieważ ma to być zdarzenie „jednorazowe” po zarejestrowaniu niestandardowego typu postu, czy warto zrobić coś takiego w mojej klasie, która zarejestruje CPT:

private function check_flush_my_CPT() {
    global $wp_rewrite;
    if ( !get_option('my_plugin_firstrun') ) {
        $wp_rewrite->init();
        $wp_rewrite->flush_rules(true);
        update_option('my_plugin_firstrun', 'yes');
    }
}

public function register_my_CPT() {
   // do all the CPT setup steps for the $args array...  

   register_post_type('my_CPT', $args);
   $this->check_flush_my_CPT();
}

add_action( 'init', array(&$this, 'register_my_CPT' ) );

Tak więc rejestracja CPT odbywa się przy każdej akcji „inicjowania” - ale jeśli mam to prawo, przepisywanie reguł jest powtarzane tylko raz. Ever .

Czy jestem na dobrej drodze?

(edycja): Właśnie próbowałem; mój CPT daje błąd 404 nie znaleziono, więc reguły przepisywania nie działają :-(

(edycja # 2): Wypróbowałem rozwiązanie umożliwiające dostęp do zmiennej globalnej, jak pokazano w tym pytaniu: Jak niezawodnie opróżnić reguły przepisywania na wielu stronach? - Zaktualizuję mój przykład kodu powyżej, aby to pokazać. Niestety nadal pojawia się błąd 404 podczas próby załadowania CPT. Widzę, że reguły przepisywania są przechowywane w bazie danych, wygląda na to, że nie są używane. Zgubiłem się.

Ta flush_rewrite_rulesfunkcja jest niezawodna w niektórych kontekstach, takich jak motyw lub wtyczka oparta na hakach, ale nie jestem pewien, czy to działamu-plugin

Moje oświadczenie opiera się na fakcie, że WordPress jest inicjowany w następujący sposób:

• wywołaj wp-settings.phpplik
• zadzwoń do do_action( 'muplugins_loaded' );haka, tutaj twoja wtyczka została zainicjowana
• wywołaj $GLOBALS['wp_rewrite'] = new WP_Rewrite();tutaj metoda flush_rulesjest inicjowana i dostępna od teraz
• do_action( 'setup_theme' );nazywa się i stawiam wszystkie moje pieniądze, że na tym haczyku flush_rewrite_ruleszadziała

Rozwiązanie?

Osobiście uważam za wiarygodne usunięcie opcji rewrite_rules.

delete_option('rewrite_rules');

lub

update_option('rewrite_rules', '' );

Ilekroć WordPressowi zabraknie rewrite_rules, będzie je odbudowywał, tak też robi ta flush_rulesmetoda.

W przepływie wykonywania WordPress są punkty, w których takie funkcje nie są dostępne. nawet w rdzeniu WordPress znalazłem to oświadczenie

// Rewrite rules can't be flushed during switch to blog.
delete_option( 'rewrite_rules' );

Jedynym problemem byłaby wydajność, nie rób tego przy każdym żądaniu, ponieważ jest to trudny proces ich odbudowania. Jak widzę, chcesz spłukać je tylko przy pierwszym połączeniu i jest to dobra rzecz.

PS: Nie jestem fanem autopromocji, ale napisałem też artykuł o tym dawno temu i myślę, że nadal to wytrzymuje

Jeśli Twoja wtyczka mu ma opcje, po aktualizacji zaktualizowałbym kolor:

update_option( 'my_options', $values );
// Flush rules after install
flush_rewrite_rules();