Как подключать шрифты в Wordpress?

Посмотрите документацию, где нужно вызывать wp_register_style.

Не нашел такой информации.

В шаблонах используются ТОЛЬКО функции вывода, а не объявления.
https://codex.wordpress.org/Function_Reference/wp_...

в function.php

add_action( 'wp_enqueue_scripts', 'register_plugin_styles' );

function register_plugin_styles() {
	wp_register_style( 'my-plugin', plugins_url( 'my-plugin/css/plugin.css' ) );
	wp_enqueue_style( 'my-plugin' );
}

Не вижу проблем в моем способе, да и мне так удобнее.

Dimox: а вы их и не увидите, потому что для этого компетенция нужна. Даже о документации не знаете, а советуете.

В вашем случае удобнее вообще это вставлять без php

<link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet">

в header.php вставлять нельзя.
вернее, можно (кто ж вам запретит-то?), но только если вы с WordPress работать не умеете

Дмитрий: умеющие работать в wordpress должны понимать что подключать шрифт черех хук нужно только для избежания конфликтов с плагинами. Зачем лишний раз дергать php если не планируется ставить плагины которые могут подгружать шрифты? Я не представляют таких плагинов, разве что прям - шрифтовых. В этом случае как раз неумеющим работать в wp нужно подключать как вы советуете.

Александр Борисович:
>подключать шрифт черех хук нужно только для избежания конфликтов с плагинами
да ладно? это какой индус такое сказал?

Дмитрий: документация.

Александр Борисович: документация и следование тому, что написано в документации, нужно для того, чтоб через год вернутся к этому коду, и не вспоминать, как оно было сделано и почему.

если что-то положено грузить через хуки, то именно так и надо делать.
"лишний раз дергать php" - этот код и так выполняется, ничего лишнего дергаться не будет.

Дмитрий:
В документации написано что так нужно подключать скрипты и стили так из за того что пресс дожен быть гибок для сторонних плагинов и сделать это без менеджера зависимостей невозможно. Так и следует делать абсолютно всем кто делает темы в свет, а так же делает плагины, а так же для тех кто использует множество плагинов в слепую.

Но подключить шрифт в личный проект, даже не стиль, зависимости которого (зависимости шрифтов, очень смешно звучит. Операция невероятно редакая) проще контролировать это самому, а не сваливая на ядро пресса которое как то должно помогать что-то вспоминать - дело выбора между тем как в документации и тем как нафига лишний раз дергать пых если можно ту же строчку кинуть в зону head и никакой пых дергать не нужно лишним wp_enqueue_style(). Ну не будет никаких конфликтов со шрифтами. Не бывает их если понимаешь что и зачем делаешь. Я выбираю меньше пыха.

Александр Борисович: ок, умник.
представь ситуацию:
одну страницу нужно стилизовать совсем по другому. Ну или не одну, а несколько по какой-то логике. Для таких страниц будут подключаться совсем другие файлы стилей, но верстка останется полностью такой же.
Используя твой подход нужно будет в хедере дублировать код с логикой подключения стиля для шрифтов. Используя правильный, когда все стили/скрипты подключаются через хук, эта логика будет в одном месте.

Затем следующая проблема - локализация шрифтов, сайт на нескольких языках и работа с RTL.
Используя твой подход, все те же проблемы, получаем как минимум дублирование кода с логикой подключения.

Вообще, если подключать что-то напрямую, не так, как написано в документации, WordPress про это знать не будет. И, если позже нужно будет как-то программно изменить вывод, то все, что подключено напрямую, менять нужно будет самостоятельно.

Примеры выше я привел с вполне простых, типовых сайтов.

Ну и, по поводу "более удобного" способа. Если речь шла о шрифтах гугла, то куда ж еще удобнее?
https://gist.github.com/jennimckinnon/a65d307e9a3f...

представь ситуацию:

Ну конечно же это самая типичная ситуация, когда мы меняем гарнитуру шрифта на разных страницах. Не нашлось ничего более популярного? Вот и я про то же.

Используя твой подход нужно будет в хедере

Конечно, в этом случае нужно ставить условия вывода.

Затем следующая проблема - локализация шрифтов, сайт на нескольких языках и работа с RTL.

Мультиязычность не коробочный функционал Wordpress'а

если подключать что-то напрямую, не так, как написано в документации, WordPress про это знать не будет.

Конечно. Как он не знает какой шрифт вы используете и не прибегая к нестандартным, Arial, например, ему это не нужно знать пока это не нужно вам.

Примеры выше я привел с вполне простых, типовых сайтов.

мультиязычность, RTL (), разные шрифты на разных страницах лично я за типовые не признаю.

Ну и, по поводу "более удобного" способа.

Более удобный это 1 строчка в хидер не мучая php когда вам это не нужно.

Александр Борисович:

Более удобный это 1 строчка в хидер не мучая php когда вам это не нужно.

ты же понимаешь, что этот экшн все равно срабатывает каждый раз при открытии страницы? и от того, прикрепил ты к нему что-то или нет, ничего не поменяется?
и на производительности замена <?php echo на то текстовую строку ощутимо никак не скажется.

мультиязычность, RTL (), разные шрифты на разных страницах лично я за типовые не признаю.

а лично у меня прошлый год только такие сайты и были. были заказчики с Израиля - вполне типовая ситуация, сделать сайт на двух языках или сделать отдельно страницу только на английском. если ты с чем-то не сталкивался, не стоит думать, что такого нет. еще и по этому стоит следовать стандартам, а не тыкать все куда попало.

Конечно. Как он не знает какой шрифт вы используете и не прибегая к нестандартным, Arial, например, ему это не нужно знать пока это не нужно вам.

если засунуть что-то напрямую в хедер, то движок про это знать не будет.
если подключить так, как в документации, то движок будет знать, что этот скрипт/стиль будет выводиться на страницу.
так понятнее?

ты же понимаешь, что этот экшн все равно срабатывает каждый раз при открытии страницы?

хук то срабатывает всегда, но не wp_register_style(). хоть он и копеешный.

если ты с чем-то не сталкивался,

то это не значит что ваш опыт является определяющим в определении типового сайта.

если засунуть что-то напрямую в хедер, то движок про это знать не будет.

Конечно не будет. А нафига ему знать? Когда мне нужно чтобы он знал, я ему скажу и пропишу хоть Arial.

так понятнее?

Я прекрасно понимаю зачем нужно подключать или не подключать.

Александр Борисович:

то это не значит что ваш опыт является определяющим в определении типового сайта.

А я и не считаю, что я знаю все. Именно по этому слушаю советы более умных - читаю документацию и делаю строго так как там написано.

А нафига ему знать?

Да по тому, что после того, как ты этот сайт сделаешь, им будет пользоваться кто-то другой. Кто не в курсе твоих новаторских чудо идей. Или сам ты им будешь пользоваться и вернешься к этому коду через год-два и будешь вспоминать, что начудил. И чем ближе написанный код будет к тому, что в доках, тем меньше будет проблем.

Как пример,
есть плагины, которые умеют минифицировать/сливать файлы. Но работают они корректно только с теми стилями/скриптами, которые подключены по стандартам WordPress. Захочешь поставить на шаблон, который делали такие же как ты "специалисты" - не сработает, нужно будет править руками.
Или есть плагины для переноса скриптов/стилей на CDN. Захочешь поставить такое, опять тебе нужно будет страдать.
И тп.

Кучу примеров тебе привел, почему так нельзя. Считаешь их "не типовыми" - ну а я с такой хренью регулярно сталкиваюсь. Как раз, благодаря таким как ты, которые документацию считают полной ерундой, без заказов не остаюсь.

Хочешь делать - делай. Сам себе проблемы на ровном месте ищешь.

читаю документацию и делаю строго так как там написано.

К слову про шрифты там ни слова, потому что это не требует такой важности как стили или скрипты.

Да по тому, что после того, как ты этот сайт сделаешь, им будет пользоваться кто-то другой.

Ну и что?) Нужно ему будет управлять шрифтом, добавит куда надо.

Кучу примеров тебе привел, почему так нельзя.

Вы не привели ни одного примера, когда нельзя, а привели примеры когда без этого невозможно.
Я разве запрещаю шрифт подключать? Если им нужно управлять или есть какой то смысл в информаировании ядра пресса - подключаем. Почему вы не уведомляете вордпрес что Arial используете? ПОтому что им не нужно управлять? А кастомные шрифты обязаны вести себя как то по другому?

Как пример,
есть плагины, которые умеют минифицировать/сливать файлы.

Про необходимость подключения стилей и скриптов через хуки написано в документации и описано мной к вашему комментарию сверху в начале. Подключение ради подключения я не делаю.

без заказов не остаюсь.

искренне рад.

Александр Борисович:

К слову про шрифты там ни слова, потому что это не требует такой важности как стили или скрипты.

Мой маленький друг, кажется, я понял, в чем проблема!
Забей на шрифты. Забудь про то, что у тебя в том файле. Если сразу две мысли не помещаются, давай упростим?

Ты подключаешь css файл. Что у тебя внутри этого файла, описание какого-то блока, либо набор font-face правил, это не важно. Это просто еще один css файл.

Его положено подключать как написал выше.

Файл с шрифтами - это просто еще один css файл.
Посмотри содержимое ответа
https://fonts.googleapis.com/css?family=Open+Sans:...
Это css.

Как его подключать, написано в документации.

Его положено подключать как написал выше.

Его положено подключать для избежания конфликтов или в вашей ситуации набора условий. Боитесь конфликтов, типа каких то плагинов которые таскают за собой неведомые шрифты, подключайте ради бога. Боитесь что какой то горе мастер натворит дел что вы шрифт не зарегистрировали, правильно делаете, такой мастер точно и без шрифта дел наделает.

Мне пых дергать каждый раз за некую теоретическую вероятность нет никакой надобности. Ее не будет и после сдачи проекта. Считайте за религиозную веру. Приравнивать css файлы от популярных библиотек с css файлом загрузки шрифтов - не запрещаю. По мне этот неведомых страх вероятных конфликтов как раз из-за не понимания этих самых вероятностей в ущерб оптимизации.

Раз положено, подключайте.

Александр Борисович:
ок, давай еще упростим.

Приравнивать css файлы от популярных библиотек с css файлом загрузки шрифтов

А в чем , интересно, разница у, скажем, вот этого css файла
https://fonts.googleapis.com/css?family=Open+Sans:...
и у вот этого?
https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/cs...

Хороший пример как бесполезно ссылаться на документацию без понимания задачи менеджера зависимостей. Бутстрап загрузит урезанный Glyphicons Halflings шрифт независимо от того зарегистрирован ли он вами ранее или кем то позже. Это к тому что этот механизм в данном случае бесполезен.
Шрифты гугла кстати от юзерагента разные подсовываются.Это динамический css. В прочем не так важно, если нужно что-то точно - то всегда ручками проверять.

Александр Борисович: так понимаю, и этот пример для тебя слишком сложный оказался(
ну ок, чтоб у тебя ничего не путалось, сравни вот это
cdn.muicss.com/mui-0.9.13/css/mui.min.css
и css от гугла
https://fonts.googleapis.com/css?family=Open+Sans:...

Вообще, лучше забудь, что это файл стилей с описанием шрифтов гугла. Это просто абстрактный css файл. Как он генерируются на стороннем сервере, с привязкой к параметрам пользователя или без, что там внутри, разницы никакой не имеет.
Повторюсь - это обычный css файл, может даже пустой. Как его подключать, написано в документации.

То, что тебе, на твой взгляд, кажется удобнее и быстрее прописывать ссылку на этот css файл напрямую в хедере, это неправильно.
Попробую аналогию привести, если отсылки к документации и здравому смыслу не помогают:
в туалете ты ж, надеюсь, туалетную бумагу используешь? хотя, на первый взгляд, просто рукой было бы и быстрее, и удобнее, и не нужно б было лишний раз рулон с бумагой дергать.

Кстати, еще хотел уточнить, что ты имеешь в виду под "лишний раз php дергать"?

Александр Борисович: не веришь мне, загугли "wordpress google font right way"
там тысячи ссылок, где объясняют, почему нужно делать именно так, как я написал.

Дмитрий:

без, что там внутри, разницы никакой не имеет.

Вы подключили бутстрап и его же иконочный шрифт. Все еще не имеет разницы что там внутри?
Для меня имеет. Я никогда на менеджер зависимостей не расчитываю. У меня соц кнопки от яндекса подгружали файл метрики еще раз только потому что метрика была позже кнопок. Откуда я знал это поведение?
Мне нужно все это записать с условием зависимостей ядру пресса чтобы никогда не столкнуться с этими скриптами ни в плагинах ни где то еще? Нафига это нужно? Ради бога подобия по документации? Смысл прежде бумажек.

Кстати, еще хотел уточнить, что ты имеешь в виду под "лишний раз php дергать"?

wp_enqueue_style() это функция. Я писал выше.

не веришь мне, загугли "wordpress google font right way"

Погуглил. Увидел что никто ничего не понимает и регистрирует шрифт как ему хочется, кто-то тупо 'webfont' пишет, кто-то webfont-open-sans. В вашем примере google_fonts'
а разбивать ГОТОВУЮ строку ссылки только для того чтобы ее снова вставить для получения той же строки но через парсер аргументов это сильно!

$query_args = array(
'family' => 'Open+Sans:400,700|Oswald:700'
'subset' => 'latin,latin-ext',
);
wp_register_style( 'google_fonts', add_query_arg( $query_args, "//fonts.googleapis.com/css" ), array(), null );

А вдруг плагин зарегистрировали не так?
'family' => 'Open+Sans:400,700|Oswald:700'
А так:
'family' => 'Open+Sans:100,500'
Он подгрузит оба шрифта? какое будет поведение? А может мне перерегистрировать шрифт чтобы он не грузился второй раз? Только так. И каков шанс что вы сразу угадаете с точным именем шрифта? Да никакой.

Не..ребята, я в эти игры играть не буду. Нравится делать ради бога документации, без смысла, пожалуйста. Никаких зависимостей это не решает, а подключить для управления такие статьи не нужны, документация есть.

где объясняют, почему нужно делать именно так, как я написал.

Они ничего не обьясняют, они как и вы пишите что так правильно. А почему - не говорят. По подобию - значит правильно? Ну сделал я плагин зарегистрировав шрифт как google_fonts, а он у вас есть как google_font_open_sans потому что нагуглили другую статью. Вордпресс знает два шрифта, но он по факту один. Зато по документации.

Нихрена это не по документации). Нет четких правил регистрации css для шрифтов - нет регистрации шрифтов. Вызывались бы они через api пресса, где шаг влево шаг враво - не заработает, как с вызывом из ядра пресса скриптов - другое дело. А так это имитация какая-то.

Александр Борисович:

Вы подключили бутстрап и его же иконочный шрифт

Я же написал, забудь, что там внутри шрифты. Это просто css файл.
Что у него внутри не смотри. Просто css файл на стороннем сервере.
WordPress не работает с шрифтами, для него это просто еще один css файл. Что внутри у этого файла ему пофиг. Так понятнее?

wp_enqueue_style() это функция. Я писал выше.

И что? Что с того, что это функция? Вызывать ее нельзя? Она сильно грузит сервер?
С чего ты взял, что добавить текстовую строку в хедер будет более производительно, чем добавить этот же файл стилей через wp_enqueue_style?

Погуглил. Увидел что никто ничего не понимает

Мой маленький и недоверчивый друг, твои знания WordPress и, более того, твоя упоротость в собственной правоте, удручают и поражают.
Может, если все вокруг пользуются бумагой, стоит задуматься, вдруг на то есть какие-то пока непонятные тебе причины?

и регистрирует шрифт как ему хочется, кто-то тупо 'webfont' пишет, кто-то webfont-open-sans

а потому, что разницы, какой ID дать этому файлу стилей, нет. Я могу точно так же подгрузить бутстраповский css и назвать его 'wwwww' или любым другим набором букв.

А почему - не говорят.

Да по тому, что так в документации написано.
Считаешь, что документация врет, посмотри код этой функции, разберись, что она делает. Почитай, как работает подключение стилей/скриптов. Складывается впечатление, что ты действительно не понимаешь, как это работает.

Не, ребята, разбирайтесь сами зачем и для чего вы это делаете

Эта конструкция позволяет легко и удобно контролировать загрузку нужных стилей для шрифтов. Все те проблемы, что я выше приводил, оно помогает решать.
Тот пример, что по ссылке, на мой взгляд, не самый оптимальный. Зато он простой.
Я подключаю примерно так же, но мой код для подключения больше сложнее, топик стартеру он не нужен.
Впрочем, не хочешь разбивать строку, ничего не мешает тебе вставить ее сразу вот так:

wp_register_style( 'google_fonts', 'https://fonts.googleapis.com/css?family=Open+Sans:300,400,700', array(), null );

Нихрена это не по документации). Нет четких правил регистрации css для шрифтов - нет регистрации шрифтов

Забудь про шрифты. Это просто css файл. Не шрифты.

Вызывались бы они через api пресса, где шаг влево шаг враво - не заработает, как с вызывом из ядра пресса скриптов - другое дело. А так это имитация какая-то.

WordPress очень гибкий движок. Можно сделать вообще все не по документации, но внешне оно будет работать и даже очень неплохо смотреться.
Не хочешь использовать бумагу/делать правильно, не делай. Но, перед тем, как начинать советовать всем остальным поступать так же, попробуй хоть немного разобраться.

Я же написал, забудь, что там внутри шрифты. Это просто css файл.
Что у него внутри не смотри. Просто css файл на стороннем сервере.

Пишите сразу, хватит думать. Сказано так значит так, не думайте.

И что? Что с того, что это функция? Вызывать ее нельзя? Она сильно грузит сервер?

Нафига бесполезные вызовы на каждый чих?

С чего ты взял, что добавить текстовую строку в хедер будет более производительно, чем добавить этот же файл стилей через wp_enqueue_style?

Потому что для вывода этой строчки не задействуется php.

Может, если все вокруг пользуются бумагой, стоит задуматься, вдруг на то есть какие-то пока непонятные тебе причины?

А вы точно уверены что у вас бумага, или так в блогах написано?

а потому, что разницы, какой ID дать этому файлу стилей, нет.

Действительно, пусть все дублируется и грузится дважды - не жалко. Главное - по документации.

Эта конструкция позволяет легко и удобно контролировать загрузку нужных стилей для шрифтов. Все те проблемы, что я выше приводил, оно помогает решать.

Кто спорит? Я же писал об этом. Но когда не нужно их решать, зачем это делать? Для кого?

попробуй хоть немного разобраться.

Для написания плагина разбор данного раздела документации был изучен.

Александр Борисович:

Потому что для вывода этой строчки не задействуется php.

Ну и на сколько секунд удалось ускорить рендер страницы отказавшись от этой функции? Сколько мегабайт памяти получилось освободить?
Особенно интересны результаты этой оптимизации совместно с использованием плагина кэширования.

Действительно, пусть все дублируется и грузится дважды - не жалко. Главное - по документации.

С чего это оно должно дублироваться?
Разберись, как работает эта функция и что она делает, и ничего у тебя дублироваться не будет. Если, конечно, руки не кривые.

Кто спорит? Я же писал об этом. Но когда не нужно их решать, зачем это делать? Для кого?

А зачем вообще следовать документации?

Вот ты советуешь человеку прописывать напрямую в хедере путь до файла css исходя из своих каких-то понятий. А откуда ты знаешь, что у него там за сайт? Может у него как раз и есть что-то из того, что я выше писал?
Из-за вот таких советчиков потом и рассказывают про дырявость и глюкавость WordPress.

Ну и на сколько секунд удалось ускорить рендер страницы отказавшись от этой функции?

проблема в целесообразности. Бесполезные вещи раздувают код.

А зачем вообще следовать документации?

Для решения задач. Если задач управления шрифтом не стоит, зачем вообще php трогать?

С чего это оно должно дублироваться?

Как же, незарегистрировали css, наставили плагинов, а они все подгружают одно и тоже 5 раз.

исходя из своих каких-то понятий.

Исхода из отсуствия аргументов с вашей стороны на вопрос если не надо то зачем. Если не нужно управлять шрифтом, зачем трогать php? Потом чтобы вдруг? А там и метрику и все что угодно подключать ради подключения?

А откуда ты знаешь, что у него там за сайт?

По вопросу ясно какая великая сложная проблема у человека.

Из-за вот таких советчиков потом и рассказывают про дырявость и глюкавость WordPress.

Вот ниже человек подсказывает.))) Он в хидере шрифт регистрирует и вызывает. Его просвещяйте)