Mam trochę dziwny problem z nieprawidłowym opróżnianiem reguł przepisywania.

Próbowałem użyć flush_rewrite_rules();i flush_rewrite_rules(true);.

Próbowałem także globalizacji $wp_rewriteza pomocą $wp_rewrite->flush_rules();i$wp_rewrite->flush_rules(true);

Żaden z nich nie wydaje się poprawnie przepłukiwać reguł przepisywania. Te połączenia rzeczywiście opróżniają reguły przepisywania po wywołaniu. Skąd to wiem? Korzystanie z rozwiązania do debugowania przepłukiwania reguł przepisywania .

Obecnie mam przepisane przepisy dotyczące aktywacji i dezaktywacji wtyczek. Brak problemów.

Mam stronę ustawień administracji wtyczki, aby użytkownicy mogli skonfigurować wtyczkę. Niektóre ustawienia dostosowują strukturę permalink, więc reguły przepisywania muszą być opróżnione na stronie ustawień administracyjnych wtyczki „Zapisz ustawienia”. (Wykorzystuje standard update_option();) do zapisywania ustawień.

Chciałbym zauważyć, że w zależności od określonych ustawień tworzone są niestandardowe typy postów, aby pasowały do ​​ustawień określonych przez użytkownika. Dlatego reguły przepisywania muszą zostać usunięte natychmiast po zapisaniu ustawień. To tutaj rzeczy nie działają poprawnie.

Powyższe rozwiązanie link do debugowania reguł przepisywania dostarczone przez @toschopokazuje, że to spłukuje mnóstwo reguł przepisywania. Jednak podczas odwiedzania pojedynczego elementu niestandardowego typu posta, a nawet archiwum niestandardowego typu postu, każdy zwraca 404 błędów.

Niestandardowy typ postu jest zarejestrowany poprawnie i odpowiednio. Wiem na pewno, że nie o to chodzi.

Natychmiast następuje zapisanie ustawień strony administracyjnej wtyczki. Tworzone są niestandardowe typy postów, dostosowywana jest struktura permalink, a wszystkie reguły przepisywania są usuwane.

Niestandardowe typy postów są następnie ładowane zawsze i ładowane initnormalnie.

Z jakiegoś powodu reguły przepisywania nie są poprawnie opróżniane, ponieważ, jak powiedziałem wcześniej, odwiedzanie pojedynczych lub archiwalnych sekcji niestandardowego typu posta zwraca błędy 404.

Teraz dziwne jest to, że jeśli wszystko, co robię, to po prostu odwiedzam stronę ustawień permalinków administracyjnych, a następnie wracam do interfejsu, aby wyświetlić sekcje pojedyncze lub archiwalne niestandardowego typu postów, działają one magicznie zgodnie z oczekiwaniami.

Co robi ta strona ustawień administracyjnych Permalinks, czego nie robię, co pozwala na prawidłowe przepisywanie reguł przepisywania, a moje nie?

Mam na myśli, że jako rozwiązanie tymczasowe przekierowuję użytkownika na stronę ustawień bezpośrednich linków administracyjnych po zapisaniu strony ustawień administracyjnych wtyczek, ale nie jest to idealne rozwiązanie. Wolałbym, żeby reguły przepisywania były poprawnie umieszczone w kodzie mojej wtyczki.

Czy jest jakiś punkt w WordPress, w którym opróżnianie reguł przepisywania po prostu już nie opróżnia WSZYSTKICH reguł?

admin_menu - Strona ustawień wtyczek została dodana do administracji WordPress.

add_options_page() - Strona ustawień wtyczek została dodana w menu Ustawienia.

Strona ustawień jest renderowana w wywołaniu zwrotnym dla add_options_page(). Tutaj $_POSTprzetwarzane są także ustawienia aktualizacji wtyczek i reguły przepisywania przy przepłukiwaniu.

Ponieważ jest to już długie pytanie, chętnie przedstawię bloki kodu (jeśli to pomoże) w linku zewnętrznym, które pomogą w uzyskaniu prawidłowej odpowiedzi.

Najlepszym miejscem do opróżnienia reguł przepisywania jest aktywacja / dezaktywacja wtyczki.

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

Zobacz artykuł o kodeksie

Z góry przepraszam, nie przebrnąłem przez całe twoje pytanie, więc jest to trochę odpowiedź na fałszywe ciasteczka.

Trudno powiedzieć, co jest nie tak, nie widząc kodu. Ale po zapisaniu niektórych ustawień warto podłączyć się admin_inittak, jak pokazano poniżej, aby opróżnić reguły przepisywania.

Kod:

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

Musisz ustawić opcję gdzieś na stronie ustawień lub dokładnie gdzieś w trakcie zapisywania ustawień. Robienie tego bez opcji jest złe, ponieważ nie chcesz za każdym razem opróżniać reguł.

Uwaga: niesprawdzone

Miałem plik klasy typów postów, który był odpowiedzialny za czytanie ustawień opcji wtyczki i tworzenie niezbędnych niestandardowych typów postów na podstawie ustawień określonych przez użytkownika.

Ten plik klasy typów postów został załadowany na haku init.

Uznałem, że wszystko, co muszę zrobić, to zaktualizować ustawienia wtyczki, a następnie opróżnić reguły przepisywania. Ponieważ klasa typów postów została już załadowana na podstawie ustawień wtyczki. Ale strony administracyjne są ładowane PO inithaku.

Typy postów nigdy nie zostały zarejestrowane, ponieważ ustawienia nie zostały jeszcze ustawione. Klasa rejestracji typów postów zakończyła się przedwcześnie bez zarejestrowanych typów postów.

Rozwiązaniem było:

1. Zaktualizuj ustawienia wtyczki.
2. Załaduj plik klasy typów postów TYLKO jeden raz, aby zostały utworzone nowe reguły przepisywania.
3. Opróżnij reguły przepisywania.

(Wcześniej ... brakowało kroku 2 - jak wspomniano powyżej ...)

Od tej pory typy postów będą ładowane na inithaku i będą miały określone ustawienia, pozwalając na tworzenie i łączenie typów postów z odpowiednimi regułami przepisywania.

Z jakiegokolwiek powodu musiałem dodać wywołanie JavaScript, aby przekierować na bieżącą stronę, po wykonaniu powyższych trzech kroków.

Musiałem także dodać wywołanie flush_rewrite_rules();na stronie ustawień administracyjnych wtyczki.

Więc w celu zapewnienia, że ​​wszystko jest opróżnione ...

Krok 1) Przejdź do strony ustawień administracyjnych wtyczki. - Wstępne spłukiwanie.

Krok 2) Zaktualizuj ustawienia wtyczek. - Drugie spłukanie.

Krok 3) Strona przekierowuje na stronę ustawień wtyczki. Powodowanie ... Trzeciego i ostatniego spłukiwania (tak samo jak wstępne spłukiwanie - Wykonane automatycznie, gdy strona ustawień wtyczki zostanie odwiedzona)

Nie twierdzę, że to praktyczne rozwiązanie, ale zadziałało dla mnie. Bardzo dziwny problem i najprawdopodobniej dotyczy mojej infrastruktury kodowania.

@ tazo-todua to również działało dla mnie podczas korzystania z wielu witryn.

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

MOJE znalezione ROZWIĄZANIE BYŁO:

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

Miałem dokładnie ten sam problem. W mojej wtyczce mam typy postów tworzone dynamicznie. Dlatego nie można ich zarejestrować za register_post_type()pomocą metody statycznej podczas activation_hooki dlatego nie są jeszcze aktywne, gdy flush_rewrite_rules()są uruchamiane podczas tego przechwytywania (co jest zwykle zalecanym sposobem przepłukiwania reguł przepisywania).

Najczystszym rozwiązaniem, jakie udało mi się w końcu wymyślić, było opróżnienie reguł przepisywania po rejestracji typów postów, ale oczywiście tylko wtedy, gdy takie opróżnianie było faktycznie konieczne (ponieważ operacja jest powolna). W moim przypadku mam kilka niestandardowych typów postów, które dziedziczą po jednej klasie bazowej, dlatego pożądane było zaimplementowanie tam kodu, który tam opróżnia.

O tym, czy konieczne jest płukanie, można zdecydować, patrząc na wynik 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);
}
}

Wady:

• W pewnym stopniu opiera się na dokładnych regułach przepisywania generowanych przez WP register_post_type().
• Sprawdzanie, czy płukanie jest konieczne podczas każdego ładowania strony, również powoduje pewne obciążenie.

Zalety:

• Całkowicie zamknięty w klasie reprezentującej typ postu.
• Opróżnia reguły przepisywania tylko wtedy, gdy jest to naprawdę konieczne.

Używaj tego tylko, jeśli nie możesz zarejestrować swojego typu posta w funkcji statycznej, która może być wywoływana zarówno podczas, jak initi activation_hook!

Zależność od tego, jak reguły przepisywania generowane podczas register_post_type()wyglądania można złagodzić, zastępując test if(strpos($key, $args['rewrite']['slug'] ) === 0)bardziej rozbudowanym, np. Wyrażeniem regularnym.