Utilisation de WordPress pour le développement d'applications Web fonctionnalités disponibles, partie 6 réécriture d'URL (ou itinéraires)

L'un des avantages des frameworks de développement d'applications Web modernes est qu'ils fournissent un moyen de générer des itinéraires vraiment propres, ou des schémas d'URL, qui correspondent au modèle conceptuel de la structure de l'application..

Par exemple, étant donné un certain type de données, par exemple, un Individuel-vous pourrez peut-être effectuer les actions suivantes:

  • ajouter
  • mettre à jour
  • effacer

Etc.

En fonction de la nature de votre candidature, vous pourrez peut-être en faire plus (comme, par exemple, ajouter un conjoint), mais pour les besoins de cet article, les opérations de base du CRUD suffisent à démontrer le point..

Pour ceux d'entre vous qui ont suivi, nous avons examiné diverses fonctionnalités proposées par WordPress comme base du développement d'applications. En poursuivant cette discussion, il est important que nous examinions les API disponibles pour personnaliser les règles de réécriture de WordPress..

L'utilisateur moyen est probablement familiarisé avec la modification du schéma d'URL dans le tableau de bord WordPress - nous en discuterons brièvement pour nous assurer que nous sommes tous sur la même page - cependant, il existe davantage de fonctionnalités disponibles pour ceux qui comprennent la réécriture d'URL dans WordPress.

En fait, nous avons la possibilité de construire des règles de réécriture d'URL pour qu'elles correspondent et fonctionnent comme celles des frameworks modernes basés sur MVC..


Comprendre les règles de réécriture

Pour vous assurer que nous sommes tous sur la même page, les règles de réécriture peuvent être considérées comme la façon dont un modèle est comparé au serveur Web pour récupérer des données de la base de données..

Par exemple, dans l’installation standard de WordPress, la structure par défaut de permalien est la suivante:

http://domain.com/?p=123

Cette URL comprend un paramètre de chaîne de requête, à savoir la paire valeur / clé de p = 123 qui, dans le contexte de WordPress, dit "récupérer le message avec l'ID de 123".

Si vous examinez de plus près les options de la Paramètres Permalink l'écran, vous verrez également une variété d'options:

Un autre exemple des règles de réécriture que vous êtes susceptible de voir est ce que l'on appelle "jolies permaliens" ou, comme indiqué dans le tableau de bord WordPress, "Post Name"..

Dans ce format, l'URL ressemble à ceci:

http://domain.com/post-title/

À partir de là, l'URL demandée arrive sur le serveur Web, puis, en fonction d'un ensemble de règles, détermine l'ID de la publication portant ce titre et le renvoie au client demandeur (qui serait le navigateur)..

Entre ces deux exemples, il existe un principe de base qui montre exactement ce que sont les règles de réécriture..

En bref, les règles de réécriture définissent un ensemble de règles dans lesquelles l'URL entrante est traduite dans un format qui extrait les informations de la base de données pour le client..

Bien sûr, cela soulève deux questions:

  1. Comment les règles de réécriture sont-elles générées??
  2. Et, peut-être plus important encore, pourquoi sont-ils si compliqués??

L'affaire des règles de réécriture

Les règles de réécriture peuvent constituer un défi pour les développeurs car elles sont basées sur des expressions régulières. Et il y a une vieille citation sur les expressions régulières de Jamie Zawinski:

Certaines personnes, confrontées à un problème, pensent "Je sais, je vais utiliser des expressions régulières". Maintenant, ils ont deux problèmes.

Drôle mais vrai. Et c'est Pourquoi traiter avec des règles de réécriture personnalisées dans WordPress peut être un tel défi pour de nombreux développeurs.

Malheureusement, nous ne pouvons pas démontrer toutes les variantes ou tous les types de schémas d'URL pouvant être créés ou pris en charge par des règles de réécriture, mais nous pouvons jeter un coup d'œil à quelques exemples pratiques qui montrent comment démarrer et fournir une fondation ou un guide pour ce que nous aurions besoin de faire à l'avenir avec nos applications.

Rinçage des règles de réécriture

Une chose importante à noter est que lorsque vous définissez vos règles de réécriture, elles ne prendront pas effet immédiatement - elles seront vidées. Cela signifie que vous devez effacer l'ancien ensemble de règles, pour le remplacer par le nouvel ensemble de règles..

Vous pouvez procéder de deux manières:

  1. Vous pouvez cliquer sur Sauvegarder les modifications dans le Paramètres Permalinktableau de bord. Malgré le fait qu’une option sera sélectionnée, tout ce que vous avez défini dans votre application functions.php le fichier sera utilisé.
  2. Vous pouvez appeler $ wp_rewrite-> flush_rules (); et prendre en charge par programme le problème.

Indépendamment de l'itinéraire que vous choisissez, il est important de vous rappeler cette étape car chaque fois que vous définissez une nouvelle règle de réécriture, vous devez effacer les anciennes règles.

Comment fonctionne l'API Rewrite?

Quand il s'agit d'écrire nos propres règles de réécriture, il est important de comprendre le fonctionnement de l'API Rewrite..

Il peut être distillé en un processus en quatre étapes:

  1. Une URL est demandée du serveur Web.
  2. Si le contenu existe à l'URL demandée, le contenu sera renvoyé (cela peut être une image, une police ou autre)..
  3. Si le contenu n'existe pas, alors la demande sera dirigée vers index.php qui correspondra au modèle de l'URL.
  4. Le contenu sera ensuite renvoyé de WordPress au client demandeur..

Si vous souhaitez voir la définition des règles de réécriture basée sur la configuration que vous avez dans le Permalink tableau de bord, consultez le plugin Rewrite Rules Inspector.

Ce plugin affichera une liste de toutes les règles actuellement en place pour correspondre aux schémas d’URL spécifiés, ainsi que les expressions régulières et les variables correspondantes. index.php.

Avoir un sens? Si non, jetons un coup d'œil à quelques exemples simples et pratiques.

Un exemple de règles de réécriture

Étant donné que nous savons que les modèles seront appariés et transmis à index.php, nous pouvons profiter de la add_rewrite_rule fonction pour définir le fonctionnement de nos URL personnalisées.

Titre abrégé d'un identifiant de poste

Supposons que nous examinions le premier message du système, autrement dit que nous examinions le message avec l'identifiant 1.

Dans la plupart des installations WordPress à la vanille, c’est Bonjour le monde et l'URL est généralement http://domain.com/hello-world ou http://domain.com/?p=1 en fonction de vos paramètres de permalien (c'est-à-dire votre ensemble actuel de règles de réécriture).

Mais définissons une règle telle que http://domain.com/first chargera également le premier article dans la base de données:

 function exemple_add_rewrite_rules () add_rewrite_rule ('premier', 'index.php? p = 1', 'top'); flush_rewrite_rules ();  add_action ('init', 'example_add_rewrite_rules');

Ajoutons une autre règle qui suivra et nous permettra de charger le second article dans la base de données. À savoir, http://domain.com/?p=2.

function exemple_add_rewrite_rules () add_rewrite_rule ('premier', 'index.php? p = 1', 'top'); add_rewrite_rule ('second', 'index.php? p = 2', 'top'); flush_rewrite_rules ();  add_action ('init', 'example_add_rewrite_rules');

En supposant que vous ayez lu la documentation de règle add_rewrite, c'est assez facile à comprendre, à droite?

En bref, il faut trois arguments:

  • Le premier argument est une expression régulière à mettre en correspondance avec l'URL demandée. Dans notre cas, nous utilisons des mots simples.
  • Le deuxième argument est l'URL à récupérer. Encore une fois, dans notre cas, nous récupérons les premier et deuxième postes, respectivement.
  • Enfin, le dernier argument est la priorité, qui peut être "top" ou "bottom". Si défini comme "top", cette règle sera évaluée avant toutes les autres règles; cependant, si "bas", alors il sera évalué en dernier.

Maintenant, ces exemples sont basiques. Cela ne suffit pas pour nous montrer vraiment comment configurer des itinéraires personnalisés tels que ceux décrits plus haut dans cet article. Pour ce faire, nous devons examiner certaines expressions plus complexes..

Remarques sur l'importation de règles de réécriture de vidage

Mais avant de faire cela, il est important de noter que cet appel flush_rewrite_rules () comme nous le faisons ci-dessus est en fait un mauvaise pratique. Cela fonctionne dans l'exemple ci-dessus, mais peut effectivement ralentir le temps de chargement d'un site..

En fait, il suffit d'appeler ce nom chaque fois que les règles de réécriture changent. Cela peut se produire chaque fois qu'un plugin est activé, ou cela peut changer lorsqu'un thème est activé.

Quel que soit le cas, assurez-vous que vous raccordez correctement vos fonctions afin que les règles de réécriture ne soient pas vidées à chaque chargement de page, à chaque fois que les règles de réécriture ont changé..


Une approche plus compliquée de la réécriture des règles

Pour introduire un ensemble plus complexe de règles de réécriture, telles que celles que nous avons détaillées précédemment dans ce message à partir d'opérations CRUD, il est important de comprendre les deux fonctions suivantes:

  • add_rewrite_tag informera WordPress des variables de chaîne de requête personnalisées. Ceci est également utilisé en conjonction avec la fonction suivante.
  • add_rewrite_rule, comme mentionné, nous permettra d'ajouter des règles de réécriture supplémentaires à WordPress (ainsi que de définir leur priorité).

Maintenant, disons que nous avons un type de message personnalisé appelé Individuel qui représente une personne dans l'application. Ensuite, disons que le Individuel a également les méthodes suivantes et les URL correspondantes disponibles:

  • tout: http://domain.com/individuals/
  • mettre à jour: http://domain.com/individual/update/1 qui est utilisé pour mettre à jour la première personne
  • effacerhttp://domain.com/individual/delete/1 qui est utilisé pour supprimer la première personne

Le schéma est donc assez simple, mais comment s'y prendre pour le mettre en œuvre?

Premièrement, nous devons définir les règles de réécriture:

 function exemple_add_rewrite_rules () // Définit la balise pour l'ID individuel add_rewrite_tag ('% individual_id%', '([0-9] *)'); // Définit les règles pour chacun des individus add_rewrite_rule ('^ individual / update / ([0-9] *)' ',' index.php? Individual = update & individual_id = $ matches [1] ',' top '); add_rewrite_rule ('^ individual / delete / ([0-9] *)', 'index.php? individual = delete & individual_id = $ correspond [1]', 'top');  add_action ('init', 'example_add_rewrite_rules');

Ensuite, nous devons définir ces fonctions personnalisées pour chaque personne afin qu’elles mettent à jour l’enregistrement approprié dans la base de données lorsque celle-ci est appelée..

Dans ce cas, nous allons définir deux fonctions, l’une pour la mise à jour de la Individuel et un pour supprimer le Individuel. Le code suivant suppose également que des informations vont être contenues dans le formulaire soumis par le navigateur..

Plus précisément, cela suppose que l'ID individuel, le prénom, le nom de famille et d'autres informations seront envoyés afin de mettre à jour l'individu..

 function exemple_process_individuel ($ input) if (exemple_updating_user ()) exemple_update_individuel ($ input);  else if ('true' == $ input ['delete_individual']) example_delete_individual ($ input ['individual_id']);  if (! is_admin ()) add_action ('init', 'example_process_individual'); function exemple_update_individual ($ input) / * La collection entrante $ input à partir d'un formulaire supposé * qui sera utilisé pour mettre à jour l'utilisateur. * * Il peut inclure des informations telles que l'ID, le prénom, * le nom de famille, etc. * * En cas de succès, utilisez wp_redirect pour revenir à la page d'accueil, ou rechargez * la page pour afficher une erreur. * / function example_delete_individual ($ individual_id) / * Utilisez l'ID entrant pour localiser l'enregistrement individuel et le supprimer * de la base de données. * * En cas de succès, utilisez wp_redirect pour revenir à la page d'accueil, ou rechargez * la page pour afficher une erreur. * / function example_updating_user () return 0 == strpos ($ _SERVER ['REQUEST_URI'], '/ individual / update');  function example_deleting_user () return 0 == strpos ($ _SERVER ['REQUEST_URI'], '/ individual / delete'); 

Notez ci-dessus que la première fonction est accrochée au init l'action et est seulement déclenché si l'utilisateur n'est pas connecté en tant qu'administrateur. Cela pourrait être amélioré en outre en le conditionnant à charger uniquement s'il provient d'une certaine page; cependant, pour cet exemple, il remplit sa fonction.

Ensuite, lisez les commentaires de code pour le Mettre à jour et le Effacer fonctions pour voir comment elles devraient fonctionner.

Enfin, notez que les deux dernières fonctions sont de simples assistants destinés à nous permettre d’écrire du code plus propre dans la fonction accrochée initiale..

Un peu incomplet

Je sais que ceci est un exemple un peu incomplet, mais pour un long article et un sujet complexe, je me suis efforcé de faire de mon mieux pour présenter l'API WordPress Rewrite, discuter des avantages de son utilisation et en parler comment l'utiliser pour créer des itinéraires d'URL plus propres.

La vérité est qu’il s’agit toujours d’un sujet difficile et qu’il est mieux compris lors de la mise en œuvre. Néanmoins, ceci est un autre composant de l’application WordPress qui lui permet de servir de base au développement d’applications Web..


Suivant

Cela dit, il est temps de passer au concept de mise en cache.

Bien sûr, de nombreux plug-ins de mise en cache sont disponibles pour WordPress, mais si vous êtes un développeur, vous souhaitez intégrer un niveau de mise en cache natif et exploiter les API WordPress pour le faire. Si tel est le cas, il est important de vous familiariser avec ce qui est disponible et comment le faire..

Cela dit, nous allons maintenant porter notre attention sur le API transitoires afin que nous puissions gérer nous-mêmes un peu la mise en cache native et examiner comment cela peut aider les mécanismes de mise en cache tiers à rendre nos applications encore plus rapides.