wp_register_styleにcrossoriginと整合性を追加する方法は？（フォントオーサム5）

Font Awesome 4をバージョン5にアップグレードします<link rel="stylesheet">。これにより、整合性とクロスオリジン属性の両方がマークアップに導入されます。

現在、私は使用しています：

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

次のように出力されます：

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

Font Awesome 5では、次の2つの新しい属性と値（integrityおよびcrossorigin）が導入されています。

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

私はwp_register_styleに整合性とcrossoriginの両方を追加することができます方法を見つける必要があるので、私が試してみましたが、使用に私の試みがwp_style_add_data失敗している、それが思われる、この方法しかサポートしていることconditional、rtlおよびsuffix、altとtitle。

style_loader_tag
style_loader_tagは公式のWordPress APIです。ドキュメントを参照してください：https ://developer.wordpress.org/reference/hooks/style_loader_tag/

apply_filters( 'style_loader_tag', $html, $handle, $href, $media )
エンキューされたスタイルのHTMLリンクタグをフィルタリングします。

最初にスタイルシートをエンキューします。ドキュメントを参照してください：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 );

$handleである'font-awesome-5'
私はnullバージョン番号がありませんように。この方法でキャッシュされます。

単純なstr_replace
単純なstr_replaceは、必要なことを達成するのに十分です。以下の例を参照してください

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 );

異なる属性
を追加する例の下に、（複数の）異なるスタイルシートに異なる属性を追加します。

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 );

すべてのスタイルに属性を追加する
以下の例では、同じ属性を複数のスタイルシートに追加しています。

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
これも便利なので、script_loader_tagについても説明しますが、このAPIはwp_enqueue_scriptと組み合わせて機能します。

script_loader_tag APIはほとんど同じですが、わずかな違いがあります。ドキュメントを参照してください：https ://developer.wordpress.org/reference/hooks/script_loader_tag/

apply_filters( 'script_loader_tag', $tag, $handle, $src )
エンキューされたスクリプトのHTMLスクリプトタグをフィルタリングします。

単一のスクリプトを延期する例の下

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 );

複数のスクリプトを延期する例の下

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 );

したがって、APIとの両方について説明style_loader_tagしましたscript_loader_tag。両方のAPIの例をいくつか示しましたが、これが多くの人々に役立つことを願っています。私は両方のAPIの経験があります。

更新
@CKMacLeod 更新していただきありがとうございます。これにより状況が明確になります。私たちはほとんど同じページにいます。私が言ったように、私はWordPress開発者であり、テーマやプラグインをhttps://wordpress.orgで公開したい場合は、基本的に「WordPressコーディング標準」に従う必要があります。テーマおよび/またはプラグイン。

だからこそ、私は「WordPressの方法」を使うよう開発者に勧めています。違いがないこともありますが、それも便利です。Font Awesomeをダウンロードしてテーマやプラグインに含めることができるとおっしゃっていたように、この方法では、style_loader_tag関数を削除してwp_enqueue_style関数を変更するだけで済みます。

最後に、過去（5年前）に、プラグインのキャッシュ、結合、および縮小化が機能しなかったため、ほとんどの場合、テーマを作成した開発者が単純にテーマの頭に物を入れ、 /またはそれらをエコーし​​ました。（ほとんどの場合）スクリプトの実行を結合、最小化、遅延するオプションも提供するほとんどのキャッシュプラグインは、不正なコードの検出とその回避において、より賢く、より優れたものになりました。しかし、これは好ましくありません。だからこそ、私は標準/規約を念頭に置いてコーディングすることを人々に奨励しています。

開発者として、あなたは常に人々があなたのコードで何ができるかを考慮し、互換性を考慮に入れる必要があります。したがって、簡単な解決策ではなく、最適な最適な解決策を取ります。私の視点を明確にしたと思います。

@CKMacLeodの編集（技術的な）議論に感謝します。これがどれほど重要であるかを理解していただければ幸いです（独自の開発でWordPress APIを使用）。繰り返しますが、私は周りを見回しており、今でも、最も人気のあるminifyプラグインのFAQを見ると、通常これはどちらか一方の方法で見られます。たとえば、

質問：一部のCSSファイルとJSファイルがマージされないのはなぜですか？
回答：プラグインは、公式のWordPress APIメソッド（https://developer.wordpress.org/themes/basics/include-css-javascript/）を使用してエンキューされたJSファイルとCSSファイル、および 同じドメインのファイルのみを処理し ます（指定されている場合を除く）設定で）。

FAQを参照してください：https : //wordpress.org/plugins/fast-velocity-minify/

@Remzi Cavdarによるscript_とstyle_loader_tagのレビューは興味深いですが、怒りを誘発する危険性があり、誰かがこのような場合にWPキューを使用する利点が何であるかを思い出させることを期待して、私は簡単な方法で、Fontawesomeのスタイルシートをフック経由で読み込むことをお勧めします。

/* 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 -->
'; 

}

たとえば、テーマフッターや投稿内の一部のアイコンにのみFAを使用している場合は、ページの本文の下に追加する必要があると主張する人もいるかもしれません。レンダーブロッキングですが、これは一度も行ったことがないことを告白しています...そして、それをheader.phpまたは他のテンプレートファイルに直接追加することはお勧めしません。それは間違っているでしょう。;）

更新

Remzi Cavdarは、wp_head（）フックを介してFontawesomeまたは同様のタグを追加するだけではWordPressキューを利用するよりも望ましくない理由について、私のリマインダーの要求に応えてくれました。彼は一般にベストプラクティスの概念を参照し、キャッシュプラグインがキューを介してスタイルシートにアクセスできるようにする必要があるかもしれないという考え方をより具体的に言及しています。

詳細に入る前に、私はそれが「ワードプレスの方法」のようなものであるということ以外に特定の重要な正当化を実際には知らないけれども、私は同志カヴダルのアプローチが好きで、将来それを自分で使うかもしれないと言います。

しかし、それに対する彼の他の主張は私には説得力がありません。多分彼または他の誰かがそれらに追加できます。もしそうなら、私はすべて耳です。結論を言えば、PingdomとGTMetrixで20を超えるテストを実行し、テストブログで「キュー経由で追加」と「ヘッド経由で追加」を比較した結果、段階的なパフォーマンスに関して有意で一貫性のある違いはありません。 2つのアプローチの間のページリクエストの合計数、または読み込み時間（GTMetrixでの「First Paint」、「First Contentful Paint」、「OnLoad」など）。

特にキャッシングに関して、キャッシングプラグインは、それらがWPキューに追加されているかどうかに関係なく、外部でホストされているファイルをあまり処理できません。ファイル自体は影響を受けないままであり、ページは引き続き各ファイルに対するリクエストを生成します。

より一般的には、スクリプトとスタイルをロードするためのさまざまな異なるアプローチを見てきました。それらの一部は、WPキューを部分的または完全にバイパスします。インスタンスが存在することは確かに考えられます-たとえば、スタイルハンドルの配列を使用して、特定のページに読み込まれないようにする機能-Fontawesomeまたは他のサードパーティタグをキューに入れることはわずかに有用であり、関数-キューへの登録とフィルタリング-は、実際にロードするだけではなく、実際には非常に簡潔です。

FAの場合、スタイルシートはすでに縮小されていますおり、FA独自のCDNを介してロードされます。パフォーマンスに対する本質的な影響は最小限ですが、wp_head（）またはキューのどちらを介してロードされても、パフォーマンスグレーダーの複数のスポット（Google Page Speed Insightsや前述のGTMetrixやPingdomなど）にデメリットが引き続き登録されます。これは、1つまたは別のイメージファイルを再最適化して数バイト（キロバイトではない）を保存しないためのパフォーマンスポイントをドッキングします。

キューではなくwp_headを介してロードすると、「スクリプトとスタイルの正しい順序」チェックがトリップする可能性があります（ローカルでホストされたファイルの後に、外部でホストされたファイルをロードするために他の誰かがあなたをより高く評価します）。ただし、ロードが本当に心配な場合サイトに最適な方法でFAを実行してから、そのファイルとサブファイルをローカルでホストして、そのスタイルと、スタイルシートが@ font-faceを介して呼び出すフォントの両方。その場合、他のローカルファイルと同じようにスタイルシートをエンキューし、最適化プラグインを介して、または直接「手動」で連結して結合することができます。Fontawesomeに独自の素晴らしい変更を加え、それらをテーマのスタイルシートや構造と統合することもできます。または、（前に簡単に説明したように）特定のページの構造で必要になる直前にCSSをインラインで追加するなど、よりエキゾチックなパフォーマンス最適化戦術を試すことができます。

とにかく、新しい "整合性"タグと "クロスオリジン"タグについて心配する必要はありません。また、いつかFontawesomeがCDN請求書を支払うのを忘れても心配する必要はありません。

または、スタイルシートとスクリプトがすべての方法で読み込まれているため、フードの下ですでに完全に混乱しているサイトで作業している場合があります。functions.phpファイルの先頭に最新の追加を追加すると、次の開発者は再び簡単に見つけることができます...