Спрашиваем и отвечаем по Wordpress-11

Если вы что-то не используете, то это не значит, что это ненужно.

Я ранее уже подробно описывал почему в WordPress вложения сделаны в виде отдельного типа записи и почему это решение наиболее правильное.

Опишу ситуацию и с wp_head() и wp_footer(). Так сложилось, что во многих современных CMS и фреймворках вроде Yii2 есть такая штука как asset management (управление подключаемыми файлами). Этот функционал реализует две основные задачи: управление зависимостями и дальнейшая их оптимизация.

Рассмотрим зачем же нужно вообще управление зависимостями. Вот представьте, что на какой-то странице требуется подключить контактную форму с AJAX-валидацией. Для ее нормальной работы требуется библиотека jQuery. Для начинающего разработчика решение очевидное: в шаблоне страницы подключаем через тег <script> сам jQuery и строчим JS код для обработки формы. Все просто и понятно.

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

Еще большие проблемы начнутся, когда эту форму нужно подключить и на некоторых других страницах. Если тупо копировать и вставлять ее код, то это сильно усложнит его поддержку. Каждый раз при изменении формы нужно будет искать где же она используется и править там скрипты. Данная проблема решается вынесением формы в отдельный JS файл. В итоге нужно просто не забывать подключать вместе с формой и саму библиотеку jQuery. Также придется где-то указывать переменные для обозначения адреса для AJAX-запросов и локализации, например.

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

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

И вот для таких случаев и существует управление зависимостями. В WordPress оно реализовано через функции wp_register_script, wp_enqueue_script, wp_register_script, wp_register_style, wp_enqueue_style и прочие. Если использовать управление зависимостями, то вам достаточно просто в одном зарегистрировать нужные скрипты, стили, переводы и другие данные, указать их зависимости, а потом на нужных страницах подключать через enqueue-функции. В итоге не нужно будет каждый раз вспоминать какие библиотеки нужны для какого-то скрипта, в каком порядке их подключать, а также проверять не подключены ли они уже на странице. Также появляется возможность объединять скрипты в один файл, а стили - в другой.

Угадайте, благодаря каким функциям работает указанный функционал в WordPress? Правильно, благодаря "ненужным" wp_head() и wp_footer() :D

Только его мало кто использует.

И вообще - мало кто в курсе.

А если в курсе =- пытаются отключить :)

Так и со многими другими функциями.

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

Мои вопросы были риторическими. У вас примеры из серии "мы делаем сайт со сложно выборкой из различных типов изображений и с кучей форм разных мастей, расцветок и форм" - и вот для этого чуда нам необходимо соглашаться со всем, что пихает в head вордпресс, а пихает он туда все, что пришло в больную голову разрабов. Поддержка Windows Live Writer - это безусловно, нужно всем и каждому. И т.д.

Не стоит судить по себе) Для меня это теперь незаменимая вещь. Например - выгрузка товаров из магазина в 1с

---------- Добавлено 16.12.2016 в 19:09 ----------

Завидуйте молча))) Можете куря кальян.))

Управление зависимостями и указанные функции используют очень многие разработчики дополнений. Представьте на секундочку в какой ад превратится поддержка популярного дополнения, если в инструкции по его установке будет написано: "добавьте эти скрипты в шапку сайта, убедитесь, что подключен jQuery, а также не забудьте прописать вот такой массив с JS-кодом в конец".

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

В своей работе я очень активно использую управление зависимостями. Я могу быть уверен, что если я подключу jQuery, например, через wp_enqueue_script('jquery'), то у моих клиентов точно ничего не сломается при очередном обновлении WP.

Для удаления ненужных тегов можно использовать все тот же стандартный функционал WP:

add_action('after_setup_theme', 'tw_clean_header', 10);

function tw_clean_header() {

	remove_action('wp_head', 'wp_generator');
	remove_action('wp_head', 'rsd_link');
	remove_action('wp_head', 'feed_links', 10);
	remove_action('wp_head', 'feed_links_extra', 10);
	remove_action('wp_head', 'wc_products_rss_feed', 10);
	remove_action('wp_head', 'wlwmanifest_link');
	remove_action('wp_head', 'index_rel_link');
	remove_action('wp_head', 'wp_shortlink_wp_head');
	remove_action('wp_head', 'wp_oembed_add_host_js');
	remove_action('wp_head', 'wp_oembed_add_discovery_links');
	remove_action('wp_head', 'print_emoji_detection_script', 7);
	remove_action('wp_head', 'rest_output_link_wp_head', 10);
	remove_action('wp_print_styles', 'print_emoji_styles');

	add_filter('the_generator', '__return_false');

}

TiA, Вы все отлично пишете, но человеку, который не хочет читать) Такая позиция для меня как купить мерса и поставить в него движок от жигулей. Ну а чо, едет же, устроен просто и чинить легко. А то что чинить через день и едет еле-еле, уже неважно)))

Нет. Человек хочет блог, а ему говорят: ты че, как ты товары будешь из 1С выгружать?

95% пользователей не нуждаются в половине из этого функционала. Принципы KISS и YAGNI знаете же. Тема не должна управлять функциональностью приложения, а тем более "отключать" функционал. Вы когда покупаете продукты в магазине: вы нагребаете целую тележку, оплачиваете, а на выходе выбрасываете то, что не нужно? Точно также и тут, но вместо денег - ресурсы. И платите вы ресурсами. Все это безусловно можно аргументировать только одним: хомяки не в состоянии включить что-то, поэтому по умолчанию включаем им всё что можно включить. Именно такая аудитория у Wordpress сложилась. Крупный сайт, который дорос до какого-то функционала, и у него появилась нужда, уж точно найдет в документации инструкцию по включению необходимого функционала. Но это, конечно, бесконечный спор. Если сейчас поменять философию WP, то пропадет его популярность. Это как философия UNIX - пишите программы, которые будут делать что-то одно, и делать это хорошо. В WP тема делает уж точно не что-то одно.

Завидовать и курить кальян — не совместимые вещи.

---------- Добавлено 16.12.2016 в 18:57 ----------

Я только хотел это написать. Без шуток.

---------- Добавлено 16.12.2016 в 18:58 ----------

Просто БОГ МЕТАФОР.

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

Да, правильней. Но...

А почему вы вообще решили, что отключать то, что 10мс. назад подключили - правильно?

TiA,

Да я изначально написал, что на заказ ничего не меняю, в том числе и из-за профилактики конфликтов.

Но у себя я могу что угодно делать. И делаю. Если вижу, что оно не нужно, но зачем-то есть. Если бы я в php нормально разбирался, я бы может и не использовал ВП вообще для блога.

Я и в теме многое упростил.