Wordpress: грамотное подключение скриптов и стилей для разных страниц?

Question

[thehighhomie]

Можно ли как-нибудь грамотнее подключать скрипты и стили для разных страниц а не в functions.php через if ( is_page ) ?

Comments

[zorca]

Какой смысл? Большие объемы CSS для инди-страниц? В вашем случае вполне правильный метод. Чем он не устраивает? Точно так же подгружаются скрипты и стили всех плагинов: проверяется наличие самого плагина на странице, после чего встраиваются его ассеты.

[thehighhomie]

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

[thehighhomie]

zorca,

Какой смысл? Большие объемы CSS для инди-страниц?

загрузка страинцы за 2 сек или за 10? есть смысл?

[thehighhomie]

zorca, все так же разбираю тему sage, там роутинг у них стоит для страниц в js, может туда копать... просто не разобрался пока

[zorca]

thehighhomie, роутинг то для сложного JS, чтобы не загружать все подряд на главной.

[zorca]

thehighhomie, это что-то не в порядке в датском королевстве, если стили грузятся по 10 секунд. Прогоните через сервисы типа webpagetest и найдете причину.

[thehighhomie]

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

[Алексей Николаев]

thehighhomie, if(is_page) - вменяемый вариант. Других нативных решений вордпресс вам не предложит. Определяете страницу и на основании этой информации подключаете.

[zorca]

thehighhomie, приведите мне пример настолько "большого" сайта, где стили занимаю объемы, которые могут подгружаться 10 секунд? Это извиняюсь счет на мегабайты должен идти. Стандартный стиль небольшого сайта весит до мегабайта. Сколько у вас? Большой сайт <> Убого оптимизированный. Оптимизируйте и все станет хорошо.

[thehighhomie]

zorca, 4, но это не важно, важно то что я еще не нашел решение.

[thehighhomie]

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

[zorca]

thehighhomie, сжатие стилей и critical css поможет отцу русской демократии.

[thehighhomie]

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

[zorca]

thehighhomie, на самом деле, если модулей много и они повторяются, то стили и скрипты можно внедрять инлайново/неинлайново в месте подключения модуля. Но все равно я плохо понимаю как у вас стили дорастают до 4 мегабайт. Это лендинг-многостраничник? Пришлите скрин вашего Франкенштейна.

[thehighhomie]

zorca, да зачем, это стартап, просто страниц пока 18, будут больше

Answer 1

[Игорь Воротнёв]

Привязка через is_page работает, но на крупных сайтах жизнь сильно усложнится, когда появится много custom post types, архивных страниц и тд, когда кроме подключения файлов js/css еще надо localize_script делать... В общем, таком код быстро превратится в макароны, которые сложно поддерживать.

Я бы делал другим путем. Что мешает добавить на редактирование страниц metabox, в котором можно дополнительно указать путь к произвольным assets, которые уникальны для этой страницы? Хранить их, соответственно, в meta или в options. Ну и дописать функцию которая будет проверять это значение и если оно не пустое - подгружать нужные файлы.

Профит:

- код пишется один раз и он универсален для данной задачи
- код совершенно не зависит от ID или слагов страниц
- при добавлении/удалении assets поддерживать/обновлять код не нужно, достаточно в админке изменить привязку

Comments

[zorca]

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

[thehighhomie]

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

в общем ничего универсального нет, я понимаю, но я надеюсь на лучшее)

[Игорь Воротнёв]

zorca,

Мы разбиваем functions.php на отдельные файлы с аатозагрузкой из нужной папки, чтобы не путаться.

У меня в functions.php только after_setup_theme, все остальное автолоад. Это как бы само собой разумеется. У тех, кто еще не добрался до namespaces и autoloading, но уже более-менее продвинулся, будут require_once модульных файлов из какой-нибудь папочки inc.

Метабокс избыточно

Чем избыточно?

можно проверять на наличие файла css со слагом страницы

То есть lookup file_exists? Имхо, взять из памяти готовые, уже загруженные метаданные - быстрее.

Но суть даже не в скорости. Слаг может поменяться. Если сайт клиентский он не просто может, он гарантированно поменяется. Через какое-то время страницу переименовывают - в угоду SEO или по другим причинам - не важно. Через год таких переименованных страниц - масса. И у вас каша. Вы ни сном ни духом, где такая загрузка по слагу сломана, а где нет - ваше решение даже не тестируемо. Любое изменение требует модификации кода, что не есть разумно с точки зрения поддержки.

[zorca]

Игорь Воротнёв скорость я думаю таки на стороне файлов, нежели базы, в нашем случае. Чтение тонны метаданных из замечательно спроектированной базы Wp ну никак не сможет обогнать одну проверку пыхи на наличие файла. Можно поспорить, если есть желание.

[thehighhomie]

Игорь Воротнёв, тоже аргумент) а на счет namespaces и autoloading в вордпресс можно подробней? пример с каким нибудь модулем или приложением? пожалуйста

[Игорь Воротнёв]

zorca,

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

Нет, потому что метаданные и так тянутся, по определению. Праймится post cache. Метаданные будут читаться в любом случае, дополнительных запросов нет. Одно дополнительное поле в результатах запроса, который и так будет выполнен, совершенно никак не скажется на скорости. Выборка идет по индексу post_id.

Чтение тонны метаданных из замечательно спроектированной базы Wp ну никак не сможет обогнать одну проверку пыхи на наличие файла. Можно поспорить, если есть желание.

А что тут спорить? Если бы нужно было делать отдельный запрос в БД - тогда да, можно бы какой-то benchmark запилить и проверить. Но отдельного запроса нет, мы просто подбрасываем еще одну строчку в результат уже существующего запроса. Overhead практически равен 0. При использовании object cache - реально 0.

thehighhomie,

и при удалении/редактировании страницы нужно удалять/редактировать ассеты.

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

а на счет namespaces и autoloading в вордпресс можно подробней? пример с каким нибудь модулем или приложением? пожалуйста

Гуглите wordpress + namespaces + autoloading. Там просто вариантов конфигурации больше чем один. Можно свой автозагрузчик, можно Composer на уровне плагина (или темы), можно Composer глобально на уровне сайта целиком (я предпочитаю такой метод).

[zorca]

thehighhomie, в Sage он вроде уже есть. Я про автолоадинг.

[thehighhomie]

Игорь Воротнёв, спасибо)

[Игорь Воротнёв]

zorca,

в Sage он вроде уже есть. Я про автолоадинг.

Кстати да. Он же ставится через Composer.

[zorca]

Игорь Воротнёв, ну не все так просто, речь идет об автолоаде без обновления Композера. Это можно сделать через класс Композера, тогда не изменения будут подхватываться из папки налету:

/*
 * Autoloading.
 */
$loader = new ClassLoader();
$classes = container('config.factory')->get($vars['config'].'_loading');
foreach ($classes as $prefix => $path) {
    $loader->addPsr4($prefix, $path);
}
$loader->register();

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

[Игорь Воротнёв]

zorca, я не совсем понял в чем смысл "без обновления Композера" и по поводу изменений на лету.

[thehighhomie]

Игорь Воротнёв, хотелось бы еще вам вопрос задать?) последний) так как вы много знаете хочу воспользоваться моментом)

как грамотнее будет подключать модудули к jquery ready? то есть:
я импортирую много модулей через import и хочу их в $(document).ready(function() { // Init... });

как бы я могу сделать список импортов в переменные и потом эти переменные еще и сюда писать : $(document).ready(function() { // vars }); что и напрягает, сначала импортировать а потом все переменные в функцию...

видел в теме sage для wordpress, есть класс роутер, так он там модули собирает и инициализируюет в $(document).ready(function() { // route... }); как-то так, но хотелось бы узнать ваше мнение

[Игорь Воротнёв]

thehighhomie, а вот это не ко мне, сорян :) Я с frontend завязал 2 года назад)) и ни разу не пожалел)) моя стихия - backend.

[zorca]

Игорь Воротнёв, я не люблю команду composer dump-autoload, без использования кешированного загрузчика, новый файл подключается мгновенно.

[thehighhomie]

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

[Игорь Воротнёв]

zorca, ну, это уже личные предпочтения. Я вот озабочен performance по самое немогу, поэтому без dump-autoload как бы не работаю по определению. В принципе я и не вижу в этом проблем - на локальной машине дампить автозагрузчик нет необходимости, пусть себе хватает все на лету, динамически. А при деплое на прод в пост-деплое дергайте дампинг и все. Локально - удобно работать. На проде - быстро. И все автоматизировано.

[zorca]

Игорь Воротнёв, ну в корне проекта Composer у меня собирает обычно сторонние компоненты. Собирать в нем зависимости своего кастома не слишком удобно. А если мест для автолоада много, то и совсем запарно становится. Такая забота о перформансе при работе с WP. :-) Во всех наших проектах самое слабое звено - ядро WP. Осталось только от него избавиться. Но имя кормит. Я думаю чутка еще Ларавель подтянется, обзаведется достойной админкой и позиции WP будут подорваны, как простого средства для получения сайта.

[Игорь Воротнёв]

zorca, хм.. если речь идет о сайте / проекте целиком, то у меня композер в корне, все зависимости - они на то и зависимости. Это и либы, и плагины/mu-плагины, и сама тема. Все это подключается из корня и управляется одним composer update. В чем разница между каким-то сторонним плагином / либой (типа CarbonFields например) и своим кастомным решением для CPT/CT? Ни в чем, и то и другое - код, без которого сайт не будет работать.

Ну, у меня как раз со скоростью ядра проблем нет) Работает вполне себе хорошо и даже быстро. Что могу сказать наверняка - не медленне, чем Laravel. А вот сторонний код чаще всего оставляет желать лучшего.

С ларой по сути та же проблема. Низкий порог входа и все легко и красиво. Как результат - медленно. Не вытеснит ларка вордпресс :) Не вытеснит.

[thehighhomie]

Игорь Воротнёв, я тут разобрался более меняя с компузером и его psr-4 autoloading. я хотел бы у вас узнать как у профессионала, стоит ли ставить компузер только для autoloading'а?

[Игорь Воротнёв]

thehighhomie, можно. Overhead есть, хоть и микроскопичный (да и с WP он далеко не стоит в разряде того, о чем стоит думать). Я бы ставил, ибо если один раз пойдешь по пути к современным стандартам PHP, то это уже навсегда. И поэтому со временем появятся для компоузера и другие задачи. Хотя если прям 100% только для автозагрузки, то можно свой загрузчик написать. Там фигня дела, у того же Tom McFarlin или Carl Alexander есть подробные тюторилы, все гуглится.

[thehighhomie]

Игорь Воротнёв, отлично) спасибо) я вот еще кроме автозагрузчика решил и шаблонизатор поставить. blade не получилось и я поставил timber. вроде он удобен но еще не могу некоторые моменты нагуглить. вроде без шаблонизатора надоело лапшу писать но и с шаблонизатором как я понял нужно нормальное mvc реаливозать а я хз как это сделать в wp) вы пользуетесь шаблонизатором?

[Игорь Воротнёв]

thehighhomie, можно и Blade прикрутить, но насколько я помню, все существующие решения отстают от последних версий Laravel, не очень активно обновляются. Возможно, просто не встречал такого package. Если доводится параллельно работать с Laravel, особенно более свежими версиями, то такой несинхрон дико раздражает. Можно и самостоятельно прикрутить, поддерживать актуальность – ничего суперсложного в этом нет. Тот же Sage использует Blade, и у них по-моему самая актуальная версия. И Themosis тоже использует Blade (он мне нравится больше чем Sage). У них же и хорошо реализован MVC, насколько это возможно с WP.

Еще есть Twig от Symfony, есть Timber как его реализация для WP (хотя можно и в чистом виде, некоторые хитрости взять из Timber). При желании можно вкрутить хоть Smarty.

Лично я не использую – как-то то ли руки не дошли, то ли не зашло, то ли своими силами справляюсь :) В общем, WordPress-way меня пока устраивает, есть определенные наработки для упрощения и оптимизации кода шаблонов, их пока хватает. У меня в команде сначала фронты делают статику, а бекендеры потом ее "натягивают", поэтому идет работа с чистым HTML, который вполне легко и удобно натягивать именно как WP-наблоны.

[thehighhomie]

Игорь Воротнёв, мне timber очень понравился, понятный и удобный, единственное меня сейчас загнали в тупик роуты, на которые ссылаются доки timber'а https://github.com/upstatement/routes
так вот, товерищь zorca в другом посте мне пояснил как я понял, что если используешь шаблонизатор то и mvc нужно реализовывать и как раз эти роуты помогают в этом.
только я не пойму, мне нужно что-ли самому писать классы контроллеров, которые обрабатвывают эти роуты? или эти роуты предназначены для специфических запросов, как например на страницу юзера? посмотрел несколько стартовых тем вордпресс + тимбер и там нет никаких роутов, все описано через обычные шаблоны archive, page, single и т.д. может и не нужно реализовывать на тимбере подобие того что и в Sage к примеру ( я имею ввиду mvc) можете пояснить пожалуйста?)

[thehighhomie]

Игорь Воротнёв, вы тоже пропали(((

[Игорь Воротнёв]

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

[thehighhomie]

Игорь Воротнёв, ладно) спасибо) сложно все охватить за короткий промежуток времени