Як додати crossorigin та цілісність до wp_register_style? (Шрифт Awesome 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" />

Шрифт Awesome 5 вводить два нові атрибути та значення ( integrityі crossorigin), наприклад:

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

Тому мені потрібно , щоб дізнатися, як я можу додати як цілісність і crossorigin до wp_register_style, я намагався , але мої спроби використовувати wp_style_add_dataне вдалося, здавалося б , що цей метод тільки підтримує conditional, rtlі suffix, altі title.

style_loader_tag
style_loader_tag є офіційним API WordPress, дивіться документацію: 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 .

API script_loader_tag майже однаковий, лише деякі невеликі відмінності, див. Документацію: 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 шлях". Я розумію, що іноді немає різниці, але це також зручність. Як ви самі сказали, що можете завантажити шрифт Awesome і включити його у свою тему та / або плагін, таким чином вам потрібно буде лише видалити функцію style_loader_tag та змінити функцію wp_enqueue_style.

І останнє, що раніше (5 років тому) деякі кешування, комбінування та мінімізація плагінів не працювали, і більшість випадків я дізнався, чому ті розробники, які створили тему, просто поклали речі в голову в тему і / або відлунювали їх. Більшість плагінів кешування, які також (більшість часу) надають варіанти комбінування, мінімізації та затримки виконання скриптів, стали розумнішими та кращими для виявлення поганого коду та роботи над ними. Але це не є кращим. Ось чому я закликаю людей придумувати норми / конвенції.

Як розробник, вам завжди потрібно враховувати, що люди можуть зробити з вашим кодом, і враховуючи сумісність. Тож не прийняття простого рішення, а найкращого оптимального рішення. Я сподіваюся, що я уточнив свою точку зору.

EDIT
@CKMacLeod Дякую за (технічну) дискусію, сподіваюся, ви зрозумієте, наскільки це важливо (використовуючи API WordPress у власній розробці). Знову ж таки, я оглядався, і навіть зараз, якщо я дивлюся на найпопулярніші плагіни міні-запитань, я зазвичай бачу це так чи інакше, наприклад:

Запитання: Чому деякі файли CSS та JS не об'єднуються?
Відповідь: Плагін обробляє лише файли JS та CSS, запускаються за допомогою офіційного методу API WordPress - https://developer.wordpress.org/themes/basics/including-css-javascript/ - як і файли з одного домену (якщо не вказано на налаштуваннях).

Див. FAQ: https://wordpress.org/plugins/fast-velocity-minify/

Огляд сценарію_ та style_loader_tag від @Remzi Cavdar цікавий, але, ризикуючи спровокувати деяке обурення, і сподіваючись, що хтось може мені нагадати, яка перевага використання черги 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 -->
'; 

}

Деякі можуть навіть стверджувати, що якщо ви використовуєте ФА лише для, скажімо, деяких піктограм у нижньому колонтитулі теми або в публікаціях, вам слід додати його нижче, на тілі сторінки, оскільки таким чином він не з'явиться як блокування візуалізації, але, зізнаюся, я ніколи цього не робив ... І я не піду до того, щоб рекомендувати додавати його безпосередньо до header.php або іншого файлу шаблону. Це було б неправильно. ;)

ОНОВЛЕННЯ

Ремзі Кавдар був досить люб'язним, щоб відповісти на мій запит на нагадування про те, чому просто додати тег Fontawesome або подібний тег через гак wp_head () може бути менш бажаним, ніж використання черги WordPress. Він загалом посилається на поняття найкращих практик і дещо конкретніше на ідею, що для кешування плагінів може знадобитися доступ до таблиці стилів через чергу.

Перш ніж розібратися в деталях, я скажу, що, хоча я насправді не знаю жодного істотного виправдання, окрім того, що це свого роду "шлях WordPress", мені подобається підхід товариша Кавдара, і я можу сам його використовувати в майбутньому .

Однак його інші претензії до цього мене не переконують. Можливо, він або хтось інший може до них додати. Якщо так, я все вухо. Підсумок, наскільки я можу сказати, після запуску понад 20 тестів на Pingdom та GTMetrix, порівнюючи "додати через чергу" та "додати через голову" на тестовому блозі, немає суттєвої та послідовної різниці в оцінці продуктивності, загальна кількість запитів на сторінку або час завантаження (наприклад, "Перша фарба", "Перша змістовна фарба" та "OnLoad" на GTMetrix) між двома підходами.

Що стосується конкретного кешування, плагіни кешування не можуть робити дуже багато з файлами, розміщеними зовні, незалежно від того, додані вони до WP-черги чи ні. Самі файли залишатимуться без змін, і на вашій сторінці все одно буде створено запит для кожного.

Загалом, я бачив широкий спектр різних підходів до завантаження скриптів та стилів. Деякі з них частково або повністю обійдуть чергу WP. Звичайно, можливо, що існуватимуть екземпляри - функція, що використовує масив ручок стилів, не дозволяючи завантажувати їх на певних сторінках, скажімо, - там, де запускається тег Fontawesome або інший сторонній тег буде надзвичайно корисним, і що початкове розгортання двох Функції - замикання та фільтрування - виявляться насправді парсимонічнішими, ніж просто завантаження.

У випадку ФА таблиця стилів вже вдосконалена і завантажується через власний CDN FA. Його внутрішній вплив на продуктивність буде мінімальним, однак, завантажений через wp_head () або через чергу, він все одно буде реєструвати недоліки в декількох місцях на грейдерах продуктивності - такі самі, як Google Page Speed ​​Insights і згадані GTMetrix та Pingdom, це дозволить вам встановити точку продуктивності за те, що не буде збережено кілька байтів (навіть не кілобайт) для повторної оптимізації того чи іншого файлу зображення.

Завантаження через wp_head, а не з черги може відключити перевірку на "правильний порядок сценаріїв та стилів" (навіть якщо хтось інший оцінить вас вище за завантаження зовнішнього розміщеного файлу після локально розміщених файлів), але, якщо ви дійсно стурбовані завантаженням FA найкращим чином для вашого сайту, тоді ви спробуйте локально розмістити його файли та під-файли, як його стиль, так і шрифти, які викликує таблицю стилів через @ font-face. У такому випадку ви можете привласнити таблицю стилів, як і будь-який інший локальний файл, об'єднати і комбінувати його за допомогою оптимізуючого плагіна або безпосередньо «від руки». Ви навіть можете зробити свої власні дивовижні модифікації Fontawesome та інтегрувати їх у свій стиль стилю та структуру тем. Або (як раніше було сказано коротко) ви можете спробувати ще кілька екзотичних тактик оптимізації продуктивності, як-от додавання CSS вбудованого прямо перед тим, як це було потрібно в структурі певної сторінки.

У будь-якому разі, вам не потрібно буде турбуватися про нові теги "цілісність" та "перехресне походження", і вам також не доведеться хвилюватися, якщо коли-небудь Fontawesome забуде сплатити свій рахунок CDN.

Або ви можете працювати на веб-сайті, який вже є повним безладом під кришкою, із таблицями стилів та сценаріями, завантаженими будь-яким способом, і, можливо, буде простіше просто мати останнє додаток у верхній частині файла function.php, щоб ви або наступний розробник може легко знайти його знову ...