Konito, если вам требуется по какой-то причине запихнуть слеши в саму ссылку, то лучше для этого использовать дополнение: https://wordpress.org/plugins/custom-permalinks/
HotLab, как вариант можете попробовать установить https://ru.wordpress.org/plugins/wp-colorbox/
Извините, но для кого я потратил полчаса своего времени и подробно рассказал для чего нужно использовать функции wp_head() и wp_footer()?
Если вы знакомы с WordPress, то должны знать, что вместе с вызовом первой из них выводиться куча других мета-тегов. Они подключаются на уровне самой системы. Ваше замечание о том "что вы сами подключили", мягко говоря, не к месту.
Вы можете добавить слеш в настройках постоянных ссылок в админке.
Указанный код для чистки wp_head правильней было бы оформить в виде плагина. Почему вы решили, что его нужно встраивать в саму тему?
Управление зависимостями и указанные функции используют очень многие разработчики дополнений. Представьте на секундочку в какой ад превратится поддержка популярного дополнения, если в инструкции по его установке будет написано: "добавьте эти скрипты в шапку сайта, убедитесь, что подключен 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');}
Если вы что-то не используете, то это не значит, что это ненужно.
Я ранее уже подробно описывал почему в 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
Это не страшилка, на самом деле.
Сам WordPress и многие дополнения используют функцию wp_head() для вывода своих мета-тегов, скриптов и стилей. Да, можно ее убрать, но не стоит потом удивляться почему это некоторые плагины вроде того же Yoast SEO перестали работать или работают не так как ожидается.
По этой причине отказ от wp_head() и wp_footer() в большинстве случаев лишен смысла и приводит к лишним проблемам.
О "правильном" кешировании данных есть целая статья на официальном сайте.
В последнее время WordPress развивается в сторону REST API. Это очень мощный инструмент, который позволяет создавать целые приложения на основе WP (см. проект Calypso на React). К слову, последний скорее-всего не будет работать без wp_head() т.к. там выводятся точки входа API.
А в каком шаблоне размещена пагинация? Вы изменяли стандартный объект запроса WP_Query или создали новый?
Тогда просто прописываете в настройках DNS маску *.xxx.ru. Эту же маску указываете в настройках Apache или nginx для alias основного домена.
Vagrant - это чудесный инструмент, если требуется обеспечить одинаковое окружение на разных машинах. Docker, к слову, решает эту же проблему, но работает по другому принципу.
Мое сообщение совершенно о другом. Если разработка ведется одним или несколькими разработчиками и в основном на WordPress, то нет необходимости в Vargant. Достаточно один раз настроить сервер и там вести разработку.
