J'ai un petit problème étrange avec les règles de réécriture qui ne sont pas correctement vidées.
J'ai essayé d'utiliser flush_rewrite_rules();
et flush_rewrite_rules(true);
.
J'ai aussi essayé de mondialiser en $wp_rewrite
utilisant $wp_rewrite->flush_rules();
et$wp_rewrite->flush_rules(true);
Aucun des deux ne semble vider correctement les règles de réécriture. Ces appels vident en effet les règles de réécriture lorsqu'ils sont appelés. Comment le sais-je? Utilisation de la solution de débogage du rinçage des règles de réécriture .
Actuellement, j'ai des règles de réécriture vidées sur l'activation et la désactivation du 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 permalien, de sorte que les règles de réécriture doivent être effacées sur la page des paramètres d'administration du plugin "Enregistrer les paramètres". (Utilise la norme update_option();
) pour enregistrer les paramètres.
Je voudrais noter qu'en fonction des 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 l'enregistrement 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 fournie par @toscho
affiche qu'elle vide des tonnes de règles de réécriture. Cependant, lors de la visite de l'élément singulier de type de publication personnalisé, ou même de l'archive de type de publication personnalisée, chacun renvoie des erreurs 404.
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 l'enregistrement des paramètres de la page d'administration du plugin. Les types de publication personnalisés sont créés, la structure du lien permanent est ajustée et toutes les règles de réécriture sont tentées d'être vidées.
Les types de publication personnalisés sont ensuite toujours chargés et chargés init
comme d'habitude.
Pour une raison quelconque, les règles de réécriture ne sont pas vidées correctement, car comme je l'ai déjà dit, la visite des sections singulières ou d'archivage du type de message personnalisé renvoie des erreurs 404.
Maintenant, la partie étrange, si tout ce que je fais, c'est simplement visiter la page des paramètres de permaliens d'administration, puis revenir à la partie frontale pour afficher les sections singulières ou d'archivage du type de publication personnalisé, elles fonctionnent comme par magie.
Que fait cette page de paramètres de permaliens d'administration que je ne fais pas pour permettre aux règles de réécriture de vider correctement et la mienne non?
Je veux dire, en tant que solution temporaire, je redirige l'utilisateur vers la page des paramètres d'administration des permaliens après avoir enregistré la page des paramètres d'administration du plugin, mais ce n'est pas une solution idéale. Je préférerais que les règles de réécriture soient juste correctement vidées dans le code de mon plugin.
Y a-t-il un certain point dans WordPress où le rinçage des règles de réécriture ne vide tout simplement plus TOUTES les règles?
admin_menu
- La page des paramètres du plugin est ajoutée à l'administration WordPress.
add_options_page()
- La page des paramètres du plugin est ajoutée dans le menu Paramètres.
La page des paramètres est rendue dans le rappel de add_options_page()
. C'est également là où $_POST
est traité la mise à jour des paramètres du plugin et le vidage des règles de réécriture.
Puisque c'est déjà une longue question, je serais prêt à fournir des blocs de code (si cela aide) dans un lien hors site pour aider à produire une réponse valide.
la source
flush_rewrite_rules
, ce qui supprime simplement l'rewrite_rules
option et la régénère, vous pouvez ouvrir le fichierwp-admin/options-permalinks.php
et voir où cela se produit. puisque cette opération supprime simplement l'option entière, il n'est pas possible de vider partiellement les règles.init
laquelle s'inscrit les types de messages. Je me suis dit que les paramètres de la page étaient enregistrés et que la page se rechargeait ... puis tirait àinit
nouveau le crochet pour enregistrer les types de messages nécessaires. J'ai donc pensé que les types de messages seraient déjà chargés, et tout ce que je devais faire était de mettre à jour l'option, puis de vider les règles de réécriture de ma page de paramètres de plugin. Je posterai une réponse sur la façon dont j'ai trouvé une solution.Réponses:
Le meilleur endroit pour vider les règles de réécriture est l'activation / désactivation du plugin.
Voir l'article du codex
Toutes mes excuses à l'avance, je n'ai pas répondu à votre question, c'est donc un peu une réponse à l'emporte-pièce.
la source
Difficile de dire ce qui ne va pas, sans voir votre code. Mais après avoir enregistré certains paramètres, il est pratique de s'y connecter
admin_init
comme indiqué ci-dessous pour vider vos règles de réécriture.Code:
Vous devez définir l'option quelque part sur votre page de paramètres ou pour être exact quelque part dans le processus d'enregistrement des paramètres. Le faire sans l'option est mauvais, car vous ne voulez pas vider les règles à chaque fois.
Remarque: non testé
la source
*_option()
page des paramètres. @helgathevikingJ'avais un fichier de classe de types de publication qui était responsable de la lecture des paramètres d'options du plugin et de la création des types de publication 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 crochet
init
.J'ai pensé que tout ce que je devais faire était de mettre à jour les paramètres du plugin, puis de vider les règles de réécriture. Étant donné que la classe des types de publication était déjà chargée en fonction des paramètres du plugin. Mais avec les pages d'administration, elles sont chargées APRÈS le
init
crochet.Les types de publication n'ont jamais été réellement enregistrés, car les paramètres n'étaient pas encore définis. La classe d'enregistrement des types de publication s'est terminée prématurément sans aucun type de publication enregistré.
La solution était:
(Auparavant ... l'étape 2 manquait - Comme mentionné ci-dessus ...)
À partir de maintenant, les types de publication seront chargés sur le
init
crochet et auront déjà des paramètres spécifiés, permettant aux types de publication d'être créés et associés aux règles de réécriture appropriées.Pour une raison quelconque, j'ai dû ajouter un appel JavaScript pour rediriger vers la page actuelle, 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 plugin.Donc, pour s'assurer que tout est rincé ...
Étape 1) Accédez à la page des paramètres d'administration du plugin. - Rinçage initial.
Étape 2) Mettez à jour les paramètres du plugin. - Deuxième chasse.
Étape 3) La page redirige vers la page des paramètres du plugin. Causant le ... Troisième et dernier rinçage (identique au rinçage initial - Fait automatiquement lorsque la page des paramètres du plugin 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.
la source
@ tazo-todua, cela a également fonctionné pour moi lors de l'utilisation de plusieurs sites.
la source
MA SOLUTION trouvée était:
la source
J'avais exactement le même problème. Dans mon plugin, j'ai des types de messages qui sont créés dynamiquement. Ils ne peuvent donc pas être enregistrés via
register_post_type()
une méthode statique pendant leactivation_hook
et ne sont donc pas encore actifs lorsqu'ilsflush_rewrite_rules()
sont exécutés pendant ce hook (qui est normalement la méthode recommandée pour vider les règles de réécriture).La solution la plus propre que j'ai pu trouver à la fin était de vider les règles de réécriture après l'enregistrement des types de publication, mais bien sûr uniquement si une telle vidange était réellement nécessaire (car l'opération est lente). Dans mon cas, j'ai en fait plusieurs types de messages personnalisés qui héritent d'une seule classe de base et il était donc souhaitable d'implémenter le code qui effectue le vidage là-bas.
La nécessité d'un rinçage peut être décidée en examinant les résultats de
get_option( 'rewrite_rules' )
:Désavantages:
register_post_type()
.Avantages:
N'utilisez ceci que si vous ne pouvez pas enregistrer votre type de message dans une fonction statique qui peut appeler pendant les deux
init
et leactivation_hook
!La dépendance sur la façon dont les règles de réécriture générées pendant l'
register_post_type()
apparence peuvent être atténuées en remplaçant le testif(strpos($key, $args['rewrite']['slug'] ) === 0)
par quelque chose de plus élaboré, c'est-à-dire une expression régulière.la source