Je mets à jour Font Awesome 4 vers la version 5 qui introduit à la fois des attributs d'intégrité et des origines croisées dans le <link rel="stylesheet">
balisage.
Actuellement, j'utilise:
wp_register_style('FontAwesome', 'https://example.com/font-awesome.min.css', array(), null, 'all' );
wp_enqueue_style('FontAwesome');
Qui sort comme:
<link rel="stylesheet" id="FontAwesome-css" href="https://example.com/font-awesome.min.css" type="text/css" media="all" />
Avec Font Awesome 5, il introduit deux nouveaux attributs et valeurs ( integrity
et crossorigin
) par exemple:
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.5.0/css/all.css" integrity="sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU" crossorigin="anonymous">
J'ai donc besoin de découvrir comment je peux ajouter à la fois l'intégrité et l'origine croisée à wp_register_style, j'ai essayé mais mes tentatives d'utilisation wp_style_add_data
ont échoué, il semblerait que cette méthode ne supporte que conditional
, rtl
et suffix
, alt
et title
.
Réponses:
style_loader_tag
style_loader_tag est une API WordPress officielle, voir la documentation: https://developer.wordpress.org/reference/hooks/style_loader_tag/
Mettez d'abord votre feuille de style en file d'attente, voir la documentation: https://developer.wordpress.org/reference/functions/wp_enqueue_style/
Le
$handle
est'font-awesome-5'
je fais
null
pour qu'il n'y ait pas de numéro de version. De cette façon, il sera mis en cache.Simple str_replace
Un simple str_replace suffit pour réaliser ce que vous voulez, voir l'exemple ci-dessous
Ajouter des attributs différents Ci-
dessous un exemple pour ajouter différents attributs à (plusieurs) feuilles de style différentes
Ajouter des attributs à tous les styles
Ci-dessous un exemple pour ajouter les mêmes attributs à plusieurs feuilles de style
script_loader_tag
Je voudrais également expliquer le script_loader_tag, car c'est aussi pratique, mais cette API fonctionne en combinaison avec wp_enqueue_script .
L'API script_loader_tag est presque la même, seulement quelques petites différences, voir la documentation: https://developer.wordpress.org/reference/hooks/script_loader_tag/
Ci-dessous un exemple pour reporter un seul script
Ci-dessous un exemple pour différer plusieurs scripts
J'ai donc expliqué à la fois les API
style_loader_tag
etscript_loader_tag
. Et j'ai donné quelques exemples pour les deux API, j'espère que cela sera utile pour beaucoup de gens. J'ai de l'expérience avec les deux API.UPDATE
@CKMacLeod Merci pour votre mise à jour, cela clarifie les choses. Nous sommes principalement sur la même page. Comme je l'ai dit, je suis un développeur WordPress et si vous souhaitez publier un thème et / ou un plugin sur https://wordpress.org, vous êtes essentiellement obligé de respecter les " normes de codage WordPress " ou ils rejetteront simplement votre thème et / ou plugin.
C'est pourquoi j'encourage les développeurs à utiliser "la manière WordPress". Je comprends que parfois il n'y a aucune différence, mais c'est aussi une question de commodité. Comme vous l'avez dit vous-même, vous pouvez télécharger Font Awesome et l'inclure dans votre thème et / ou plugin, de cette façon, vous n'auriez qu'à supprimer la fonction style_loader_tag et modifier votre fonction wp_enqueue_style.
Et une dernière chose, dans le passé (il y a 5 ans), la mise en cache, la combinaison et la réduction des plugins ne fonctionnaient pas et la plupart du temps, je découvrirais pourquoi les développeurs qui ont créé le thème ont simplement mis les choses en tête dans le thème et / ou leur fait écho. La plupart des plugins de mise en cache, qui fournissent également (la plupart du temps) des options pour combiner, réduire et retarder l'exécution des scripts, sont devenus plus intelligents et meilleurs pour détecter le mauvais code et les contourner. Mais ce n'est pas préféré. C'est pourquoi j'encourage les gens à coder avec des normes / conventions à l'esprit.
En tant que développeur, vous devez toujours prendre en considération ce que les gens pourraient faire avec votre code et en tenant compte de la compatibilité. Donc, ne prenez pas la solution facile mais la meilleure solution optimale. J'espère avoir clarifié mon point de vue.
EDIT
@CKMacLeod Merci pour le débat (technique), j'espère que vous réalisez à quel point c'est important (en utilisant les API WordPress dans votre propre développement). Encore une fois, j'ai regardé autour de moi et même maintenant, si je regarde la FAQ des plugins minify les plus populaires, je vois généralement ça dans un sens ou dans l'autre, par exemple:
Voir FAQ: https://wordpress.org/plugins/fast-velocity-minify/
la source
L'examen de script_ et style_loader_tag par @Remzi Cavdar est intéressant, mais, au risque de provoquer une certaine indignation, et dans l'espoir que quelqu'un puisse me rappeler quel serait l'avantage d'utiliser la file d'attente WP dans des cas comme celui-ci, je '' Je vous recommande de prendre la sortie facile et de charger la feuille de style de Fontawesome via le crochet.
Certains pourraient même affirmer que, si vous utilisez FA uniquement pour, disons, certaines icônes dans le pied de page du thème ou dans les publications, vous devez l'ajouter plus bas, dans le corps de la page, car de cette façon, il n'apparaîtra pas comme blocage de rendu, mais j'avoue que je n'ai jamais fait ça ... Et je n'irai pas jusqu'à recommander de l'ajouter directement à un fichier header.php ou à un autre fichier de modèle. Ce serait faux. ;)
MISE À JOUR
Remzi Cavdar a eu la gentillesse de répondre à ma demande de rappel pour expliquer pourquoi l'ajout d'un tag Fontawesome ou similaire via le crochet wp_head () pourrait être moins souhaitable que l'utilisation de la file d'attente WordPress. Il se réfère généralement à la notion de meilleures pratiques et un peu plus spécifiquement à l'idée que les plugins de mise en cache pourraient avoir besoin d'accéder à la feuille de style via la file d'attente.
Avant d'entrer dans les détails, je dirai que, bien que je ne sache pas de justification particulière significative autre que le fait qu'il s'agit d'une sorte de "méthode WordPress", j'aime l'approche du camarade Cavdar et je pourrai l'utiliser moi-même à l'avenir .
Cependant, ses autres prétentions à ce sujet ne sont pas convaincantes pour moi. Peut-être que lui ou quelqu'un d'autre peut y ajouter quelque chose. Si oui, je suis tout ouïe. En résumé, pour autant que je sache, après avoir exécuté plus de 20 tests sur Pingdom et GTMetrix en comparant "ajouter via la file d'attente" et "ajouter via la tête" sur un blog de test, il n'y a pas de différence significative et cohérente en termes de performances notées, nombre total de demandes de page, ou temps de chargement (par exemple, "First Paint", "First Contentful Paint" et "OnLoad" sur GTMetrix) entre les deux approches.
En ce qui concerne la mise en cache en particulier, les plug-ins de mise en cache ne peuvent pas faire grand-chose avec les fichiers hébergés en externe, qu'ils soient ajoutés ou non à la file d'attente WP. Les fichiers eux-mêmes ne seront pas affectés et votre page générera toujours une demande pour chacun.
Plus généralement, j'ai vu un large éventail d'approches différentes pour charger des scripts et des styles. Certains d'entre eux contourneront partiellement ou entièrement la file d'attente WP. Il est certainement concevable qu'il y aura des instances - une fonction qui utilise un tableau de poignées de style tout en les empêchant d'être chargées sur des pages particulières, par exemple - où avoir le Fontawesome ou un autre tag tiers mis en file d'attente sera marginalement utile, et que le déploiement initial de deux les fonctions - mise en file d'attente et filtrage - s'avéreront en fait plus parcimonieuses que de simplement en charger une.
Dans le cas de FA, la feuille de style est déjà réduite et est chargée via le propre CDN de FA. Son impact intrinsèque sur les performances sera minime, cependant, qu'il soit chargé via wp_head () ou via la file d'attente, il enregistrera toujours les démérites à plusieurs endroits sur les classeurs de performances - les mêmes, comme Google Page Speed Insights et les GTMetrix et Pingdom susmentionnés, cela vous amènera un point de performance pour ne pas enregistrer quelques octets (pas même des kilo-octets) réoptimisant l'un ou l'autre fichier image.
Le chargement via wp_head plutôt que la file d'attente peut déclencher un "ordre correct des scripts et des styles" (même si quelqu'un d'autre vous classera plus haut pour le chargement du fichier hébergé en externe après ceux hébergés localement), mais, si vous êtes vraiment préoccupé par le chargement FA de la meilleure façon possible pour votre site, puis vous essayez d' héberger localement ses fichiers et sous-fichiers, à la fois son style et les polices que sa feuille de style appelle via @ font-face. Dans ce cas, vous pouvez mettre la feuille de style en file d'attente comme tout autre fichier local, la concaténer et la combiner via un plugin d'optimisation ou directement «à la main». Vous pouvez même faire vos propres modifications impressionnantes de Fontawesome et les intégrer à votre feuille de style et à votre structure de thème. Ou (comme mentionné brièvement précédemment), vous pouvez essayer des tactiques d'optimisation des performances plus exotiques, comme l'ajout de la CSS en ligne juste avant qu'elle ne soit nécessaire dans la structure d'une page spécifique.
Quoi qu'il en soit, vous n'aurez pas à vous soucier des nouvelles balises "intégrité" et "origine croisée", et vous n'aurez pas non plus à vous inquiéter si Fontawesome oublie un jour de payer sa facture CDN.
Ou vous travaillez peut-être sur un site qui est déjà un gâchis complet sous le capot, avec des feuilles de style et des scripts chargés de toutes les manières, et il pourrait être plus facile d'avoir votre dernier ajout en haut du fichier functions.php pour que vous ou le prochain développeur pourra le retrouver facilement ...
la source