web-dev-qa-db-fra.com

Où, quand et comment effacer correctement les règles de réécriture dans le champ d'application d'un plugin?

J'ai un problème étrange avec le fait que les règles de réécriture ne fonctionnent pas correctement.

J'ai essayé d'utiliser flush_rewrite_rules(); et flush_rewrite_rules(true);.

J'ai aussi essayé de globaliser $wp_rewrite en utilisant $wp_rewrite->flush_rules(); et $wp_rewrite->flush_rules(true);

Ni l'un ni l'autre ne semble vider correctement les règles de réécriture. Ces appels effacent effectivement les règles de réécriture lorsqu'ils sont appelés. Comment je sais ça? Utilisation de la solution pour vidage de la règle de réécriture du débogage .

Actuellement, j'ai des règles de réécriture vidées lors de l'activation et de la désactivation d'un plugin. Aucun problème là-bas.

J'ai une page de paramètres d'administration du plugin pour que les utilisateurs puissent configurer le plugin. Certains paramètres ajustent la structure du lien permanent, de sorte que les règles de réécriture doivent être purgées sur la page des paramètres d'administration du plug-in "Enregistrer les paramètres". (Utilise la update_option(); standard) pour enregistrer les paramètres.

J'aimerais noter que, selon les paramètres spécifiés, des types de publication personnalisés sont créés pour correspondre aux paramètres spécifiés par l'utilisateur. Les règles de réécriture doivent donc être vidées immédiatement après la sauvegarde des paramètres. C'est là que les choses ne fonctionnent pas correctement.

La solution de lien ci-dessus pour le débogage des règles de réécriture fournies par @toscho indique que des tonnes de règles de réécriture sont supprimées. Toutefois, lorsqu’il visite un élément singulier de type publication personnalisé, ou même une archive de type publication personnalisée à cet égard, renvoie 404 erreurs.

Le type de publication personnalisé est enregistré correctement et de manière appropriée. Je sais avec certitude que ce n'est pas le problème.

Immédiatement après, enregistrez avec les paramètres de la page d’administration du plug-in. Les types de publication personnalisés sont créés, la structure de permalien est ajustée et toutes les règles de réécriture sont tentées.

Les types de publication personnalisés sont ensuite toujours chargés, et chargés dans init comme d'habitude.

Pour une raison quelconque, les règles de réécriture ne fonctionnent pas correctement, car, comme je l’ai déjà dit, la consultation de sections singulières ou d’archives du type de message personnalisé renvoie 404 erreurs.

La partie bizarre, si tout ce que je fais est simplement de visiter la page des paramètres d’administration permaliens, puis de revenir au début pour afficher les sections singulières ou archivées du type de publication personnalisé, fonctionne magiquement comme prévu.

Qu'est-ce que la page des paramètres de permaliens de l'administration ne fait pas que je ne fais pas pour permettre aux règles de réécriture de se vider correctement et non aux miennes?

Je veux dire, en tant que solution temporaire, je redirige l'utilisateur vers la page des paramètres d'administration des permaliens de l'administration après avoir enregistré la page des paramètres d'administration du plug-in, mais ce n'est pas une solution idéale. Je préférerais que les règles de réécriture soient correctement intégrées au code de mon plugin.

Existe-t-il un point dans WordPress où vider les règles de réécriture ne supprime plus TOUTES les règles?

admin_menu - La page des paramètres du plug-in est ajoutée à l'administration WordPress.

add_options_page() - La page de paramètres du plug-in est ajoutée dans le menu Paramètres.

La page de paramètres est rendue dans le rappel pour add_options_page(). C'est également à cet endroit que $_POST est traité pour la mise à jour des paramètres du plug-in et le vidage des règles de réécriture.

Comme la question est déjà longue, je serais prêt à fournir des blocs de code (si cela peut vous aider) dans un lien hors site qui aide à produire une réponse valide.

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

Le meilleur endroit pour vider les règles de réécriture est l’activation/désactivation du plugin.

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

Voir l'article du codex

Toutes mes excuses par avance, je n’ai pas bien répondu à votre question. C’est donc un peu une réponse très simple.

4
helgatheviking

Difficile de dire ce qui ne va pas, sans voir votre code. Mais après avoir sauvegardé certains paramètres, il est pratique d’attacher admin_init comme indiqué ci-dessous pour effacer vos règles de réécriture.

Code: 

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


Vous devez définir l’option quelque part sur la page des paramètres ou pour être exacte dans le processus d’enregistrement des paramètres. Le faire sans l'option est mauvais, parce que vous ne voulez pas vider les règles à chaque fois.


Remarque: non testé

4
Nicolai

J'avais un fichier de classe post types qui était responsable de la lecture des paramètres d'options du plug-in et de la création des types de post personnalisés nécessaires en fonction des paramètres spécifiés par l'utilisateur.

Ce fichier de classe de types de publication a été chargé sur le hook init.

Je pensais que tout ce dont j'avais besoin alors était de mettre à jour les paramètres du plug-in, puis de vider les règles de réécriture. Étant donné que la classe des types de publication était déjà chargée sur la base des paramètres du plug-in. Mais avec les pages d’administration, elles sont chargées APRÈS le hook init.

Les types de publication n'ont jamais été enregistrés, car les paramètres n'étaient pas encore définis. La classe d’enregistrement de types de publication a fini par se terminer prématurément sans enregistrement de types de publication.

La solution était:

  1. Mettez à jour les paramètres du plugin.
  2. Chargez le fichier de classe post types SEULEMENT une fois ici pour que les nouvelles règles de réécriture soient créées.
  3. Videz les règles de réécriture.

(Auparavant ... il manquait l'étape 2 - comme mentionné ci-dessus ...)

À partir de maintenant, les types de publication seront chargés sur le hook init et auront déjà des paramètres spécifiés, ce qui permettra de créer des types de publication et de les associer aux règles de réécriture appropriées.

Pour une raison quelconque, j'ai dû ajouter un appel JavaScript pour rediriger vers la page en cours, après avoir effectué les trois étapes ci-dessus.

J'ai également dû ajouter un appel à flush_rewrite_rules(); sur la page des paramètres d'administration du plug-in.

Donc, pour que tout soit purgé ...

Étape 1) Accédez à la page des paramètres d’administration du plug-in. - Premier flush.

Étape 2) Mettez à jour les paramètres du plugin. - Deuxième flush.

Étape 3) Redirection de page vers la page de paramètres du plug-in. Causing the ... Troisième et dernier rinçage (identique au rinçage initial - Fait automatiquement lorsque la page des paramètres du plug-in est visitée)

Je ne dis pas que c'est une solution pratique, mais cela a fonctionné pour moi. Problème très étrange et probablement lié à mon infrastructure de codage.

3
Michael Ecklund

@ tazo-todua cela a fonctionné pour moi aussi en utilisant 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();
}
1
stillatmylinux

Ma solution trouvée était:

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

J'avais exactement le même problème. Dans mon plugin, j'ai des types de post qui sont créés dynamiquement. Ils ne peuvent donc pas être enregistrés via register_post_type() dans une méthode statique pendant le activation_hook et ne sont donc pas encore actifs lorsque flush_rewrite_rules() est exécuté pendant ce hook (qui est normalement le méthode recommandée de vidage des règles de réécriture).

La solution la plus propre que je pouvais trouver à la fin était de vider les règles de réécriture après l'enregistrement des types de poste, mais bien sûr uniquement si un tel vidage était réellement nécessaire (car l'opération est lente). Dans mon cas, plusieurs types de publication personnalisés héritent d'une même classe de base. Il était donc souhaitable d'implémenter le code qui effectue le vidage.

Vous pouvez décider si un rinçage est nécessaire en examinant le résultat de 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);
}
}

Désavantages:

  • S'appuie dans une certaine mesure sur les règles de réécriture exactes WP générées pendant register_post_type().
  • Le fait de vérifier si un vidage est nécessaire lors du chargement de chaque page crée également une surcharge.

Avantages:

  • Entièrement encapsulé dans la classe représentant le type de publication.
  • Ne supprime les règles de réécriture que si cela est vraiment nécessaire.

Utilisez-le uniquement si vous ne pouvez pas enregistrer votre type de message dans une fonction statique pouvant appeler à la fois init et le activation_hook!

La dépendance vis-à-vis des règles de réécriture générées lors de register_post_type() peut être atténuée en remplaçant le test if(strpos($key, $args['rewrite']['slug'] ) === 0) par quelque chose de plus élaboré, à savoir une expression régulière.

0
cgogolin