Dove, quando e come eseguire correttamente il flush delle regole di riscrittura all'interno di un plugin

Il posto migliore per eseguire il flush delle regole di riscrittura è durante l'attivazione/disattivazione del plugin.

function myplugin_activate() {
    // registra qui le tassonomie/tipi di post
    flush_rewrite_rules();
}

register_activation_hook( __FILE__, 'myplugin_activate' );

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

Vedi l'articolo sul codex

Mi scuso in anticipo, non ho letto completamente la tua domanda, quindi questa è una risposta un po' generica.

Difficile capire cosa non va senza vedere il tuo codice. Ma dopo aver salvato alcune impostazioni, è buona pratica agganciarsi a admin_init come mostrato di seguito per ripulire le regole di riscrittura.

Codice:

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

Devi impostare l'opzione da qualche parte nella tua pagina delle impostazioni o, per essere precisi, nel processo di salvataggio delle impostazioni. Farlo senza l'opzione non è consigliabile, perché non vorrai ripulire le regole ogni volta.

Nota: non testato

Avevo un file di classe per i tipi di post che era responsabile di leggere le impostazioni delle opzioni del plugin e creare i necessari tipi di post personalizzati in base alle impostazioni specificate dall'utente.

Questo file di classe per i tipi di post veniva caricato sull'hook init.

Pensavo che tutto ciò che avrei dovuto fare fosse aggiornare le impostazioni del plugin e poi svuotare le regole di riscrittura. Poiché la classe dei tipi di post era già caricata in base alle impostazioni del plugin. Ma con le pagine di amministrazione, queste vengono caricate DOPO l'hook init.

I tipi di post non sono mai stati effettivamente registrati, perché le impostazioni non erano ancora state impostate. La classe di registrazione dei tipi di post terminava prematuramente senza che nessun tipo di post fosse registrato.

La soluzione era:

1. Aggiornare le impostazioni del plugin.
2. Caricare il file della classe dei tipi di post SOLO una volta qui in modo che le nuove regole di riscrittura vengano create.
3. Svuotare le regole di riscrittura.

(In precedenza... il passaggio 2 mancava -- Come accennato sopra...)

D'ora in poi, i tipi di post verranno caricati sull'hook init e avranno già le impostazioni specificate, consentendo la creazione dei tipi di post e l'abbinamento con le appropriate regole di riscrittura.

Per qualche motivo, ho dovuto aggiungere una chiamata JavaScript per reindirizzare alla pagina corrente, dopo aver eseguito i tre passaggi sopra.

Ho anche dovuto aggiungere una chiamata a flush_rewrite_rules(); nella pagina delle impostazioni di amministrazione del plugin.

Quindi, per garantire che tutto venga svuotato...

Passaggio 1) Navigare verso la pagina delle impostazioni di amministrazione del plugin. -- Svuotamento iniziale.

Passaggio 2) Aggiornare le impostazioni del plugin. -- Secondo svuotamento.

Passaggio 3) La pagina si reindirizza alla pagina delle impostazioni del plugin. Causando il... Terzo e ultimo svuotamento (lo stesso dello svuotamento iniziale -- Eseguito automaticamente quando si visita la pagina delle impostazioni del plugin)

Non sto dicendo che questa sia una soluzione pratica, ma ha funzionato per me. Problema molto strano e molto probabilmente ha a che fare con la mia infrastruttura di codifica.

Avevo esattamente lo stesso problema. Nel mio plugin, ho dei post type che vengono creati dinamicamente. Di conseguenza, non possono essere registrati tramite register_post_type() in un metodo statico durante l'activation_hook e quindi non sono ancora attivi quando flush_rewrite_rules() viene eseguito durante questo hook (che è normalmente il metodo consigliato per svuotare le regole di riscrittura).

La soluzione più pulita che ho trovato alla fine è stata quella di svuotare le regole di riscrittura dopo la registrazione dei post type, ma ovviamente solo se tale operazione fosse effettivamente necessaria (perché l'operazione è lenta). Nel mio caso, ho diversi post type personalizzati che ereditano da una singola classe base, quindi era desiderabile implementare il codice che esegue lo svuotamento lì.

Se lo svuotamento è necessario può essere deciso esaminando l'output di get_option( 'rewrite_rules' ):

class MyPostTypeClass {

public final function register_as_custom_post_type() {
    ...   //esegui tutta la configurazione del tuo post type qui     
    $args = array(
                  ... //popola gli altri argomenti come ritieni opportuno
                  'rewrite' => array('slug' => 'slug-del-tuo-post-type')
                 );
    register_post_type('nome-del-tuo-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);
}
}

Svantaggi:

• Dipende in qualche misura dalle esatte regole di riscrittura che WordPress genera durante register_post_type().
• Verificare se lo svuotamento è necessario durante ogni caricamento di pagina crea anche un certo overhead.

Vantaggi:

• Completamente incapsulato nella classe che rappresenta il post type.
• Svuota le regole di riscrittura solo se realmente necessario.

Usa questo metodo solo se non puoi registrare il tuo post type in una funzione statica che può essere chiamata sia durante init che l'activation_hook!

La dipendenza da come appaiono le regole di riscrittura generate durante register_post_type() può essere mitigata sostituendo il test if(strpos($key, $args['rewrite']['slug'] ) === 0) con qualcosa di più elaborato, ad esempio un'espressione regolare.

@tazo-todua anche per me ha funzionato quando uso il multisite.

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

Se vuoi eseguire flush_rewrite_rules quando QUALSIASI plugin viene attivato o disattivato

add_action('init', function(){

    // Ottieni il percorso di tutti i plugin installati
    $pluginsInstalledPaths = glob(WP_PLUGIN_DIR . '/*', GLOB_ONLYDIR);

    foreach ($pluginsInstalledPaths as $pluginPath) {
        // Ottieni tutti i file PHP disponibili nella directory principale del plugin
        $files = glob($pluginPath . '/*.php');
        foreach ($files as $file) {
            $contents = file_get_contents($file);
            // Se il file contiene "Plugin Name" è il file principale del plugin
            if (preg_match('/\/\*\*[^\/]*?Plugin Name:/', $contents)) {
                add_action('activate_' . plugin_basename($file), function(){
                    flush_rewrite_rules();
                });
                add_action('deactivate_' . plugin_basename($file), function(){
                    flush_rewrite_rules();
                });
            }
        }
    }
});

LA MIA SOLUZIONE TROVATA È STATA:

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

Aggiungi questo codice ogni volta che vuoi svuotare le regole di riscrittura, ad esempio durante l'attivazione del tuo plugin o in qualsiasi evento desideri.

add_action('init','flush_rewrite_rules');