Come aggiungere crossorigin e integrità a wp_register_style? (Font Awesome 5)

Sto aggiornando Font Awesome 4 alla versione 5 che introduce nel <link rel="stylesheet">markup attributi sia di integrità che di origine originale .

Attualmente sto usando:

wp_register_style('FontAwesome', 'https://example.com/font-awesome.min.css', array(), null, 'all' );
wp_enqueue_style('FontAwesome');

Che produce come:

<link rel="stylesheet" id="FontAwesome-css" href="https://example.com/font-awesome.min.css" type="text/css" media="all" />

Con Font Awesome 5 introduce due nuovi attributi e valori ( integritye crossorigin) ad esempio:

<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.5.0/css/all.css" integrity="sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU" crossorigin="anonymous">

Quindi ho bisogno di scoprire come posso aggiungere sia l'integrità che il crossorigin a wp_register_style, ho provato ma i miei tentativi di utilizzo wp_style_add_datasono falliti, sembra che questo metodo supporti solo conditional, rtle suffix, alte title.

style_loader_tag
style_loader_tag è un'API ufficiale di WordPress, consultare la documentazione: https://developer.wordpress.org/reference/hooks/style_loader_tag/

apply_filters( 'style_loader_tag', $html, $handle, $href, $media )
Filtra il tag di collegamento HTML di uno stile accodato.

Prima accodare il foglio di stile, consultare la documentazione: https://developer.wordpress.org/reference/functions/wp_enqueue_style/

wp_enqueue_style( 'font-awesome-5', 'https://use.fontawesome.com/releases/v5.5.0/css/all.css', array(), null );

Il $handleè 'font-awesome-5'
lo faccio nullin modo che non v'è alcun numero di versione. In questo modo verrà memorizzato nella cache.

Str_replace
semplice È sufficiente un semplice str_replace per ottenere ciò che si desidera, vedere l'esempio di seguito

function add_font_awesome_5_cdn_attributes( $html, $handle ) {
    if ( 'font-awesome-5' === $handle ) {
        return str_replace( "media='all'", "media='all' integrity='sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU' crossorigin='anonymous'", $html );
    }
    return $html;
}
add_filter( 'style_loader_tag', 'add_font_awesome_5_cdn_attributes', 10, 2 );

Aggiungi attributi diversi
Sotto un esempio per aggiungere attributi diversi a (più) fogli di stile diversi

function add_style_attributes( $html, $handle ) {

    if ( 'font-awesome-5' === $handle ) {
        return str_replace( "media='all'", "media='all' integrity='sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU' crossorigin='anonymous'", $html );
    }

    if ( 'another-style' === $handle ) {
        return str_replace( "media='all'", "media='all' integrity='blajbsf' example", $html );
    }

    if ( 'bootstrap-css' === $handle ) {
        return str_replace( "media='all'", "media='all' integrity='something-different' crossorigin='anonymous'", $html );
    }

    return $html;
}
add_filter( 'style_loader_tag', 'add_style_attributes', 10, 2 );

Aggiungi attributi a tutti gli stili
Di seguito un esempio per aggiungere gli stessi attributi a più di un foglio di stile

function add_attributes_to_all_styles( $html, $handle ) {

        // add style handles to the array below
        $styles = array(
            'font-awesome-5',
            'another-style',
            'bootstrap-css'
        );

        foreach ( $styles as $style ) {
            if ( $style === $handle ) {
                return str_replace( "media='all'", "media='all' integrity='sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU' crossorigin='anonymous'", $html );
            }
        }

        return $html;
}
add_filter( 'style_loader_tag', 'add_attributes_to_all_styles', 10, 2 );

script_loader_tag
Vorrei anche spiegare script_loader_tag, perché anche questo è utile, ma questa API funziona in combinazione con wp_enqueue_script .

L'API script_loader_tag è quasi la stessa, solo alcune piccole differenze, consultare la documentazione: https://developer.wordpress.org/reference/hooks/script_loader_tag/

apply_filters( 'script_loader_tag', $tag, $handle, $src )
Filtra il tag di script HTML di uno script accodato.

Di seguito un esempio per rinviare un singolo script

function add_defer_jquery( $tag, $handle ) {
    if ( 'jquery' === $handle ) {
        return str_replace( "src", "defer src", $tag );
    }
    return $tag;
}
add_filter( 'script_loader_tag', 'add_defer_jquery', 10, 2 );

Di seguito un esempio per rinviare più di uno script

function add_defer_attribute( $tag, $handle ) {

    // add script handles to the array below
    $scripts_to_defer = array(
        'jquery',
        'jquery-migrate',
        'bootstrap-bundle-js'
    );

    foreach ( $scripts_to_defer as $defer_script ) {
        if ( $defer_script === $handle ) {
            return str_replace( "src", "defer src", $tag );
        }
    }

    return $tag;
}
add_filter( 'script_loader_tag', 'add_defer_attribute', 10, 2 );

Quindi ho spiegato sia API style_loader_tagche script_loader_tag. E ho dato alcuni esempi per entrambe le API, spero che questo sia utile per molte persone là fuori. Ho esperienza con entrambe le API.

AGGIORNAMENTO
@CKMacLeod Grazie per l'aggiornamento, questo chiarisce le cose. Siamo principalmente sulla stessa pagina. Come ho detto, sono uno sviluppatore di WordPress e se vuoi pubblicare un tema e / o un plugin su https://wordpress.org sei essenzialmente costretto a rispettare gli " Standard di codifica di WordPress " o semplicemente rifiuteranno il tuo tema e / o plugin.

Ecco perché incoraggio gli sviluppatori là fuori a usare "il modo WordPress". Capisco che a volte non ci sono differenze di sorta, ma è anche convenienza. Come hai detto tu stesso, puoi scaricare Font Awesome e includerlo nel tuo tema e / o plugin, in questo modo dovrai solo rimuovere la funzione style_loader_tag e modificare la tua funzione wp_enqueue_style.

E un'ultima cosa, in passato (5 anni fa) la memorizzazione nella cache, la combinazione e la minimizzazione dei plug-in non funzionava e la maggior parte delle volte avrei scoperto perché quegli sviluppatori che hanno creato il tema hanno semplicemente messo le cose in testa nel tema e / o li fece eco. La maggior parte dei plug-in di cache, che forniscono anche (la maggior parte delle volte) opzioni per combinare, minimizzare e ritardare l'esecuzione degli script, sono diventati più intelligenti e migliori nel rilevare codici errati e aggirarli. Ma questo non è preferito. Ecco perché incoraggio le persone a programmare con gli standard / le convenzioni in mente.

Come sviluppatore, devi sempre prendere in considerazione ciò che le persone potrebbero fare con il tuo codice e tenendo presente la compatibilità. Quindi non prendere la soluzione facile ma la migliore soluzione ottimale. Spero di aver chiarito il mio punto di vista.

EDIT
@CKMacLeod Grazie per il dibattito (tecnico), spero che tu capisca quanto sia importante (usando le API di WordPress nel tuo sviluppo). Ancora una volta, mi sono guardato intorno e anche ora se guardo le FAQ dei plugin minify più popolari di solito vedo questo in un modo o nell'altro, ad esempio:

Domanda: Perché alcuni dei file CSS e JS non vengono uniti?
Risposta: il plug-in elabora solo i file JS e CSS accodati utilizzando il metodo API WordPress ufficiale - https://developer.wordpress.org/themes/basics/including-css-javascript/ -come anche i file dello stesso dominio (se non specificato sulle impostazioni).

Vedi le FAQ: https://wordpress.org/plugins/fast-velocity-minify/

La recensione di script_ e style_loader_tag di @Remzi Cavdar è interessante, ma, a rischio di provocare un po 'di indignazione, e nella speranza che qualcuno possa ricordarmi quale sarebbe il vantaggio di utilizzare la coda WP in casi come questo, io' Ti consiglierò di uscire facilmente e di caricare il foglio di stile di Fontawesome tramite hook.

/* ADD FONTAWESOME 5.5.0 via action hook */
add_action( 'wp_head', 'sewpd_add_fontawesome' );

function sewpd_add_fontawesome() {

echo '
<!--FONTAWESOME 5.5.0 added via functions.php -->
<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.5.0/css/all.css" integrity="sha384-B4dIYHKNBt8Bc12p+WXckhzcICo0wtJAoU8YZTY5qE0Id1GSseTk6S+L3BlXeVIU" crossorigin="anonymous">
<!--END FONTAWESOME -->
'; 

}

Alcuni potrebbero persino sostenere che, se si utilizza FA solo per, ad esempio, alcune icone nel piè di pagina del tema o all'interno dei post, è necessario aggiungerlo più in basso, nel corpo della pagina, poiché in questo modo non verrà visualizzato come render-blocking, ma confesso di non averlo mai fatto ... E non andrò fino a raccomandare di aggiungerlo direttamente a un header.php o ad un altro file modello. Sarebbe sbagliato. ;)

AGGIORNARE

Remzi Cavdar è stato così gentile da rispondere alla mia richiesta di promemoria sul perché aggiungere semplicemente un tag Fontawesome o simile tramite l'hook wp_head () potrebbe essere meno desiderabile dell'utilizzo della coda di WordPress. Si riferisce in generale alla nozione di best practice e in qualche modo più specificamente all'idea che i plug-in di cache potrebbero dover essere in grado di accedere al foglio di stile tramite la coda.

Prima di entrare nei dettagli, dirò che, anche se in realtà non conosco alcuna giustificazione particolare significativa se non quella che è una specie di "modo WordPress", mi piace l'approccio del compagno Cavdar, e potrei usarlo da solo in futuro .

Le sue altre affermazioni per questo, tuttavia, non sono convincenti per me. Forse lui o qualcun altro può aggiungere a loro. Se è così, sono tutto orecchie. In conclusione, per quanto ne so, dopo aver eseguito oltre 20 test su Pingdom e GTMetrix confrontando "aggiungi via coda" vs "aggiungi via capo" su un blog di test, non vi è alcuna differenza significativa e coerente in termini di prestazioni graduate, numero totale di richieste di pagine o tempi di caricamento (ad es. "First Paint", "First Contentful Paint" e "OnLoad" su GTMetrix) tra i due approcci.

Per quanto riguarda specificamente la memorizzazione nella cache, i plug-in di memorizzazione nella cache non possono fare molto con i file ospitati esternamente, indipendentemente dal fatto che vengano aggiunti o meno alla coda WP. I file stessi rimarranno inalterati e la tua pagina genererà comunque una richiesta per ognuno.

Più in generale, ho visto una vasta gamma di approcci diversi per il caricamento di script e stili. Alcuni di essi bypasseranno parzialmente o interamente la coda WP. È certamente ipotizzabile che ci siano istanze - una funzione che utilizza una serie di handle di stile, impedendo al contempo di essere caricati su determinate pagine, per esempio - dove avere il Fontawesome o altri tag di terze parti accodati sarà marginalmente utile, e quella distribuzione iniziale due le funzioni - accodamento e filtraggio - diventeranno effettivamente più parsimoniose del semplice caricamento di una.

Nel caso di FA, il foglio di stile è già minimizzato e viene caricato tramite la propria CDN di FA. Il suo impatto intrinseco sulle prestazioni sarà minimo, sebbene, sia caricato tramite wp_head () o tramite la coda, registrerà comunque i demeriti in più punti sui classificatori delle prestazioni - gli stessi, come Google Page Speed ​​Insights e le citate GTMetrix e Pingdom, che ti ancorerà un punto prestazionale per non salvare alcuni byte (nemmeno i kilobyte) riottimizzando l'uno o l'altro file immagine.

Il caricamento tramite wp_head anziché la coda può far scattare un controllo "ordine corretto di script e stili" (anche se qualcun altro ti classificherà più in alto per caricare il file ospitato esternamente dopo quelli ospitati localmente), ma, se sei davvero preoccupato per il caricamento FA nel miglior modo possibile per il tuo sito, quindi proveresti a ospitare localmente i suoi file e sotto-file, sia il suo stile che i caratteri che il suo foglio di stile chiama tramite @ font-face. In tal caso è possibile accodare il foglio di stile come qualsiasi altro file locale, concatenarlo e combinarlo tramite un plug-in di ottimizzazione o direttamente "a mano". Puoi persino apportare le tue fantastiche modifiche a Fontawesome e integrarle con il foglio di stile e la struttura del tema. Oppure (come accennato brevemente in precedenza) potresti provare alcune tattiche più esotiche di ottimizzazione delle prestazioni come l'aggiunta del CSS inline proprio prima che fosse necessario nella struttura di una pagina specifica.

Ad ogni modo, non dovresti preoccuparti dei nuovi tag "integrità" e "di origine incrociata" e non dovresti nemmeno preoccuparti se un giorno Fontawesome dimentica di pagare il conto CDN.

Oppure potresti lavorare su un sito che è già un disastro completo, con fogli di stile e script caricati in ogni modo, e potrebbe essere più semplice avere l'ultima aggiunta nella parte superiore del file Functions.php in modo che tu o lo sviluppatore successivo può individuarlo di nuovo facilmente ...