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

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

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

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

zorca,

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

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

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

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

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

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

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

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

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

zorca,

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

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

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

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

thehighhomie,

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

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

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

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

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

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

zorca,

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

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

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

/*
 * 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, я не совсем понял в чем смысл "без обновления Композера" и по поводу изменений на лету.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Игорь Воротнёв, отлично) спасибо) я вот еще кроме автозагрузчика решил и шаблонизатор поставить. 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-наблоны.

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

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

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

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