Estoy actualizando Font Awesome 4 a la versión 5 que introduce atributos de integridad y de origen cruzado en el <link rel="stylesheet">marcado.
Actualmente estoy usando:
wp_register_style('FontAwesome', 'https://example.com/font-awesome.min.css', array(), null, 'all' );
wp_enqueue_style('FontAwesome');
Que sale como:
<link rel="stylesheet" id="FontAwesome-css" href="https://example.com/font-awesome.min.css" type="text/css" media="all" />
Con Font Awesome 5 presenta dos nuevos atributos y valores ( integrityy crossorigin) por ejemplo:
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.5.0/css/all.css" integrity="sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU" crossorigin="anonymous">
Así que necesito descubrir cómo puedo agregar tanto la integridad como el origen cruzado a wp_register_style, lo he intentado pero mis intentos de uso wp_style_add_datahan fallado, parece que este método solo es compatible con conditional, rtly suffix, alty title.

Respuestas:
style_loader_tag
style_loader_tag es una API oficial de WordPress, consulte la documentación: https://developer.wordpress.org/reference/hooks/style_loader_tag/
Primero ponga en cola su hoja de estilo, consulte la documentación: https://developer.wordpress.org/reference/functions/wp_enqueue_style/
El
$handlees lo'font-awesome-5'que hago
nullpara que no haya número de versión. De esta manera se almacenará en caché.Str_replace
simple Un str_replace simple es suficiente para lograr lo que desea, vea el ejemplo a continuación
Agregar diferentes atributos
A continuación, un ejemplo para agregar diferentes atributos a (múltiples) hojas de estilo diferentes
Agregue atributos a todos los estilos
Debajo de un ejemplo para agregar los mismos atributos a más de una hoja de estilos
script_loader_tag
También me gustaría explicar el script_loader_tag, porque esto también es útil, pero esta API funciona en combinación con wp_enqueue_script .
La API script_loader_tag es casi la misma, solo algunas pequeñas diferencias, consulte la documentación: https://developer.wordpress.org/reference/hooks/script_loader_tag/
Debajo de un ejemplo para diferir un solo script
Debajo de un ejemplo para diferir más de un script
Así que he explicado las API
style_loader_tagyscript_loader_tag. Y di algunos ejemplos para ambas API. Espero que esto sea útil para mucha gente. Tengo experiencia con ambas API.ACTUALIZACIÓN
@CKMacLeod Gracias por su actualización, esto aclara las cosas. Principalmente estamos en la misma página. Como dije, soy un desarrollador de WordPress y si desea publicar un tema y / o complemento en https://wordpress.org , está esencialmente obligado a cumplir con los " Estándares de codificación de WordPress " o simplemente rechazarán su tema y / o complemento.
Es por eso que animo a los desarrolladores a usar "la forma de WordPress". Entiendo que a veces no hay diferencias, pero también es conveniente. Como usted mismo dijo, podría descargar Font Awesome e incluirlo en su tema y / o complemento, de esta manera solo necesitaría eliminar la función style_loader_tag y modificar su función wp_enqueue_style.
Y una última cosa, en el pasado (hace 5 años), algunos complementos de almacenamiento en caché, combinación y minificación no funcionaron y la mayoría de las veces descubrí por qué los desarrolladores que crearon el tema simplemente pusieron las cosas en la cabeza en el tema y / o los repitió. La mayoría de los complementos de almacenamiento en caché, que también (la mayoría de las veces) ofrecen opciones para combinar, minimizar y retrasar la ejecución de los scripts, se volvieron más inteligentes y mejores para detectar códigos incorrectos y solucionarlos. Pero esto no es preferido. Es por eso que animo a las personas a codificar con estándares / convenciones en mente.
Como desarrollador, siempre debe tener en cuenta lo que la gente podría hacer con su código y tener en cuenta la compatibilidad. Entonces, no tomar la solución fácil sino la mejor solución óptima. Espero haber aclarado mi punto de vista.
EDITAR
@CKMacLeod Gracias por el debate (técnico), espero que se den cuenta de lo importante que es esto (usando las API de WordPress en su propio desarrollo). Nuevamente, he estado buscando e incluso si miro las preguntas frecuentes de los complementos de minify más populares, generalmente veo esto de una forma u otra, por ejemplo:
Ver preguntas frecuentes: https://wordpress.org/plugins/fast-velocity-minify/
fuente
La revisión de script_ y style_loader_tag por @Remzi Cavdar es interesante, pero, a riesgo de provocar cierta indignación, y con la esperanza de que alguien pueda recordarme cuál sería la ventaja de usar la cola WP en casos como este, yo ' Recomiendo tomar el camino fácil y cargar la hoja de estilo de Fontawesome a través del gancho.
Algunos incluso podrían argumentar que, si está usando FA solo para, por ejemplo, algunos íconos en el pie de página del tema o en las publicaciones, debe agregarlo más abajo, dentro del cuerpo de la página, ya que de esa manera no aparecerá como bloqueo de renderizado, pero confieso que nunca he hecho eso ... Y no iré tan lejos como para recomendar agregarlo directamente a un header.php u otro archivo de plantilla. Eso estaría mal. ;)
ACTUALIZAR
Remzi Cavdar tuvo la amabilidad de responder a mi solicitud de un recordatorio de por qué simplemente agregar un Fontawesome o una etiqueta similar a través del enlace wp_head () podría ser menos deseable que utilizar la cola de WordPress. En general, se refiere a la noción de mejores prácticas y, algo más específicamente, a la idea de que los complementos de almacenamiento en caché pueden necesitar acceder a la hoja de estilo a través de la cola.
Antes de entrar en detalles, diré eso, aunque en realidad no conozco ninguna justificación particular significativa aparte de que es una especie de "la forma de WordPress", me gusta el enfoque del camarada Cavdar, y puedo usarlo yo mismo en el futuro .
Sus otros reclamos por ello, sin embargo, no son persuasivos para mí. Tal vez él o alguien más pueda agregarles algo. Si es así, soy todo oídos. En pocas palabras, por lo que puedo decir, después de ejecutar más de 20 pruebas en Pingdom y GTMetrix comparando "agregar a través de la cola" versus "agregar a través de la cabeza" en un blog de prueba, no hay una diferencia significativa y consistente en términos de rendimiento calificado, número total de solicitudes de página o tiempos de carga (por ejemplo, "Primera pintura", "Primera pintura satisfactoria" y "OnLoad" en GTMetrix) entre los dos enfoques.
Con respecto al almacenamiento en caché específicamente, los complementos de almacenamiento en caché no pueden hacer mucho con archivos alojados externamente, ya sea que se agreguen o no a la cola de WP. Los archivos en sí no se verán afectados y su página seguirá generando una solicitud para cada uno.
En términos más generales, he visto una amplia gama de enfoques diferentes para cargar scripts y estilos. Algunos de ellos omitirán parcial o totalmente la cola de WP. Ciertamente es concebible que haya instancias, una función que utiliza una variedad de identificadores de estilo al tiempo que evita que se carguen en páginas particulares, por ejemplo, donde tener el Fontawesome u otra etiqueta de terceros en cola será marginalmente útil, y esa implementación inicial de dos Las funciones, poner en cola y filtrar, en realidad resultarán más parsimoniosas que simplemente cargar una.
En el caso de FA, la hoja de estilo ya está minimizada y se carga a través de la propia CDN de FA. Sin embargo, su impacto intrínseco en el rendimiento será mínimo, ya sea que se cargue a través de wp_head () o a través de la cola, seguirá registrando deméritos en múltiples puntos en los evaluadores de rendimiento, los mismos, como Google Page Speed Insights y los mencionados GTMetrix y Pingdom, eso le acoplará un punto de rendimiento para no guardar unos pocos bytes (ni siquiera kilobytes) y volver a optimizar uno u otro archivo de imagen.
La carga a través de wp_head en lugar de la cola puede disparar una comprobación de "orden correcto de scripts y estilos" (aunque alguien más lo calificará más alto para cargar el archivo alojado externamente después de los alojados localmente), pero, si realmente le preocupa cargar FA de la mejor manera posible para su sitio, entonces intentaría alojar localmente sus archivos y subarchivos, tanto su estilo como las fuentes que su hoja de estilo llama a través de @ font-face. En ese caso, puede poner en cola la hoja de estilo como cualquier otro archivo local, concatenarla y combinarla mediante un complemento de optimización o directamente "a mano". Incluso podría hacer sus propias modificaciones increíbles de Fontawesome e integrarlas con la hoja de estilo y la estructura de su tema. O (como se mencionó anteriormente brevemente) podría probar algunas tácticas de optimización del rendimiento más exóticas, como agregar el CSS en línea justo antes de que fuera necesario en la estructura de una página específica.
De todos modos, no necesitaría preocuparse por las nuevas etiquetas de "integridad" y "origen cruzado", y tampoco tendría que preocuparse si algún día Fontawesome olvida pagar su factura de CDN.
O puede estar trabajando en un sitio que ya es un desastre completo, con hojas de estilo y scripts cargados de todas maneras, y podría ser más fácil tener su última incorporación en la parte superior del archivo functions.php para que usted o el próximo desarrollador puede localizarlo de nuevo fácilmente ...
fuente