Правильный plugin php. Плагины — Документация Webasyst

Это главный файл в вашей теме WordPress. Располагается в /wp-content/themes/{тут название вашей темы}/functions.php .
В нём определяются важные свойства темы, кастомизируются хуки, внешний вид и её функциональность, а также добавляются некоторые необходимые вам функции. Этот файл загружается каждый раз при открытии любой страницы WordPress, поэтому с его помощью можно изменить любой элемент сайта. В связи с этим, многие советы а-ля «как изменить что-то в WordPress без плагинов » часто касаются именно внесения изменений в functions.php, вместо того, чтобы создать под этот функционал отдельный плагин или воспользоваться готовым решением. Зачастую это приводит к информационной перегрузке этого файла, код становится тяжело разобрать, а внести исправления ещё сложнее. Но не это самое опасное. Самое опасное — это то, что при смене активной темы пропадёт часть или весь необходимый функционал сайта .

Чем отличается functions.php от плагина

Ничем. По своей сути, functions.php и есть эдакий глобальный неотключаемый плагин, который привязан к текущей теме. Как он подключается в WordPress, можно посмотреть в wp-settings.php . Как видно из исходного кода, его загрузка происходит после всех плагинов, однако, это не даёт никаких недостатков или преимуществ, разве что возможность переопределить что-то в подключенных плагинах. На скорость исполнения кода это также никак не повлияет. Влияет только содержание плагинов и functions.php. Поэтому, будьте внимательны при выборе активных плагинов для своей темы и откажитесь от ненужных, малополезных вам, тогда вы сможете облегчить ваш сайт и ускорить его работу.

Когда нужно использовать functions.php

Руководствуйтесь следующим правилом: если функционал напрямую связан с текущей темой, но не с работой сайта, записывайте его в functions.php.

К примеру, это может быть

Настройка миниатюр
Установка размеров сайдбаров
Настройка мест под виджеты
Объявление мест под навигационное меню
Настройки темы
Дополнительные функции вашей темы

Когда стоит избегать использования functions.php

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

Определение счётчиков посещаемости (Google Analytiсs, Yandex.Metrika, Liveinternet)
Настройка дополнительного функционала админки (например, )
Конфигурирование исходного кода ()
Определение шорткодов
Регистрация

Списки неполные, вы можете определить их содержание сами под себя.

Куда внести данный код, если не в functions.php? Вы можете написать специальные плагины под них, однако, есть способ интереснее и проще.

mu-plugins как альтернатива functions.php

К нам в современные версии WordPress из WordPress MU(Multi-User) пришёл интересный функционал, называемый MU Plugins . Суть его заключалась в следующем. Администратору WordPress MU порой требовалось определить плагины для всей сети сайтов. Обычным функционалом этого было не добиться, поэтому ввели специальный раздел: /wp-content/mu-plugins/ , где они и определялись. Ещё что интересно, файлы плагинов из этой директории загружаются раньше всех остальных, что даёт возможность предопределить некоторые константы или настройки.
Позже WPMU упразднили, его код интегрировали с основным блоговым, и теперь любой WordPress может использовать функционал MU-plugins, который теперь расшифровывается как Must Use , то есть обязательный к использованию.

Как использовать mu-plugins

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

Здесь для примера создан файл с кодом счётчиков посещаемости.
Внутри этот файл выглядит вот так

// ... Вместо этой строки вставляем код счётчиков...

В админке он будет выглядеть как Необходимые

Файл функций — занимательный помощник в расширении функционала сайта! особливо, если используется по назначению, — однако, многие владельцы блогов/сайтов замечательным образом превращают functions.php в сборную солянку.

В любом деле существуют целесообразности и ограничения (ограничения, чаще логические), а посему некоторый исполняемый код, призванный регулировать параметры ядра WP (не темы), правильнее вынести за пределы шаблона…

Когда разговор ведётся об модернизации функциональных возможностей сайта, в линейке статей «без плагинов…» непременно советуют пихать все блоки кода в легендарный functions.php . Это неправильно!

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

Создадим его! а также потолкуем о плюсах и минусах (коих значительно меньше)…

Разделы статьи:

как создать свой плагин

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

в чём отличие файла functions.php от плагина

Почему следует некоторый код, относящийся непосредственно к функционалу сайта, перенести в отдельный плагин?

Самый файл функций, его цель и сообразность ничем не отличается от плагина (попросту — плагин в теме))! — его основная задача — обогатить полезным функционалом конкретный (активный) шаблон.

Например, «навигация», где по логике, меню кнопок оформлено CSS соответственно стилю активной темы — может быть, правильнее оставить в корне шаблона.

В чём выгода — разбить файл функций на отдельные файлы, либо отдельный плагин?

Например, самое банальное — вы решили поменять шаблон!? …как итог — пропадут все функциональные наработки, ибо весь полезный код расположен в файле функций (видел однажды такой размер файла 750кИЛО)

Конечно, можно перенести документацию функций в новую тему, но — чаше всего, без правок, что отнимают уйму полезного времени, не обойтись: обезьянка и труд)

И к тому же:

очерёдность загрузки файлов сайта

Кратко: порядок загрузки файлов ядра сайта в нашем примере такой — чуть раньше подгружаются активные плагины сайта (из папки plugins) и их содержание, и уж потом обрабатывается файл functions.php с содержимым. Это всё миллисекунды, и вряд ли тут стоит всерьёз говорить о выигрыше самой скорости страниц.

Хотя, думается, что одна из причин такой очерёдности загрузки, установленной разработчиками, где второе место отведено файлу функций (как предположительно более лёгкому элементу), как раз тот факт широкого использования плагинов, зачастую массивного содержания…

Кто-то воскликнет: ещё один плагин…? это тяжело!

А я говорю, ни на какую скорость это не повлияет… скорее — наоборот, если к созданию сайта подходить вдумчиво.

Притом — выгода переноса некоторого кода очевидна в другом, а именно, — скорость загрузки сайта зависит не от количества активных плагинов, но от их содержимого! Так почему же не уменьшить файл функций, который, как говорилось, подгружается чуточку позже..? и к тому же является полноценным массивным ПЛАГИНОМ уровня шаблона! Так где же место большей части его кода?

По моему мнению, (активный, рабочий) шаблон должен содержать в себе только касаемые конкретно его параметры.

экскурс к арифметике…

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

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

Проще и логичнее создать лёгенький плагин, настроить и забыть…

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

Тогда как учится следует в библиотеках вордпресс, но не по статьям… из статей возможно почерпнуть лишь ту или иную идею…

Как-то так вот-с)

…для тех, которым интересно:

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

…в одной из следующих статей как раз такая тема-бедекер! …и ссылки на полезные странички.

!..подписываясь на обновления сайт -
...расстаёмся с невежеством..!

как создать плагин дополнительного файла functions.php

Рассматриваемый плагин, конечно же, простенькое решение, но и изучение должно стартовать от азов!

Тем паче, для достижения взятых в статье целей, никаких мощных плагинов и не нужно!

Заходим в панель управления хостигом (или средствами FTP) открываем файловый менеджер.

Открываем папку plugins и в ней создаём ещё одну директорию (папку для файлов нашего плагина). Имя абсолютно любое, на латинице. У меня в качестве примера имя «test».

Обратите внимание, что имя плагина в админке будет таким, которое прописано в информационном заголовке Plugin Name: test (см. комментарии).

Открываем созданную папку и в ней создаём основной файл плагина:

…с названием, скажем my-functions.php и занесём в его тело такие строки (и имя файла может быть абсолютно любым)

Строки в комментарии — информация о плагине, которая появится в админпанели (меню плагины).

Сразу после того как создадите папку и файл, в админке появится ваш плагин. Посмотрите.

В качестве экса, можете его на время активировать — но ничего не произойдёт, плагин пока холостой.

Вот и всё!! простенький плагин создан и, что примечательно, своими руками и для своей же пользы (как говаривал кот Матроскин).

На этом занавес представления опускается…
…на рампы пыль печальная ложится…

А вот кстати и полезное кино из сериала «без плагинов» — посмотрите, подумайте, стоит ли предложенный в видео код оставлять в файле функций??

Скорость загрузки является важным требованием к сайту как со стороны поисковиков, так и с точки зрения пользователей. Люди хотят быстро получать информацию, а не ждать несколько секунд пока отобразится страница. Именно поэтому разработчики пытаются всячески улучшить данный процесс: внедряют подборки рекомендаций как на mkels.com , экспериментируют с сервисами и CMS модулями.

Если говорить про картинки, то тут 2 варианта: оптимизация с помощью веб-решений или графических редакторов, а также ленивая загрузка изображений (англ. — Lazy Load). В WordPress для второго метода имеется целый ряд плагинов, которые сегодня рассмотрим.

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

Как работает Lazy Load:

браузер подгружает содержимое сайта без медиафайлов;
с помощью некого JavaScript определяются какие картинки/видео должны выводиться изначально при запуске страницы;
«дополнительная» материалы отображается при прокрутке, когда пользователь доходит до нужного контента.

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

Первый модуль основан на скрипте jQuery.sonar (автор Dave Artz, AOL), позволяющем определить какая картинка находится в видимости пользователя. Я использую именно его т.к. в описании сказано, что созданием занималась команда из Automattic (wordpress.com) и другие опытные программисты. К тому же здесь больше всего установок (90 тыс.), хотя он и обновлялся давненько + оценка лишь 4. По личному опыту все работает отлично.

Кроме картинок в постах плагин добавляет ленивую загрузку изображений из миниатюр, + iframes (включая популярные видеохостинги YouTube / Vimeo). Поддерживается контент в виджетах — особенно актуально после добавления в WP виджетов вставки видео/графики. Пользователи без Javascript будут видеть обычную неоптимизированную страницу. Нормально работает с CDN. Загрузок — 50 тыс, оценка 4, обновление было не так давно.

a3 Lazy Load

Одно из самых «новых» решений — апдейт 2 месяца назад + поддержка самой . Скачивания — более 10тысяч, оценка 4,5. Отличительной его особенностью есть целый блок настроек в админке, где вы можете вручную выбрать какие типы объектов будут обработаны: миниатюры, виджеты, граватары и т.п.

Аналогичные настройки есть для видео и iframe контента (встроенного кода). Также модуль совместим с CDN, AMP, WooCommerce, WPTouch, WP Super Cache и W3 Total Cache. По ощущениям это самый продвинутый вариант из всех — тут реализована не просто отложенная загрузка картинок, а предоставляется целый комплекс функций по оптимизации.

Собственно модуль делает то же, что и остальные — улучшает время загрузки и сокращает число HTTP запросов. В описании сказано, что он не использует тяжелые библиотеки по типу jQuery, а скрипт весит 6Кб. Для старта не нужны дополнительные настройки — просто устанавливаете и активируете.

Rocket Lazy Load работает в том числе с аватарами и превью, хотя в отзывах были замечания, что могут возникать ошибки с дизайном — проверяйте работоспособность сайта после внедрения. А еще лучше использовать пример кода с репозитория, позволяющий отключить вызов решения на некоторых ненужных страницах (оставить только single).

Crazy Lazy

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

Скачиваний — 5000, оценка — 4,5. В описании нет информации, что аватары и виджеты также «подхватываются» автоматические, уточните при тестировании. С другой стороны, если у вас, например, для комментариев используется сторонний скрипт, то это нормально.

Авторы охарактеризовали свое творение как самый быстрый, легкий и производительный метод отложенной загрузки в Вордпресс. Лучше бы они, конечно, детальнее рассказали о списке настроек, которые получит пользователь после установки. Здесь есть: выбор типов графики для обработки, использование минифицированных версий скриптов, а также перемещение их в футер, добавление эффектов прелоадеру и некоторые другие аддоны. Таким образом, модуль позволяет дополнительно реализовать некоторые SEO рекомендации для WordPress , что весьма удобно.

Плюсом Lazy Load XT можно назвать использование прозрачной картинки-загрузчика, поэтому на странице пользователи не увидят «белых блоков» вместо подгружаемых изображений. Также здесь есть поддержка фоновой графики при желании (но это уже выходит за рамки контента, и нужно быть внимательным).

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

Lazy Load for Videos

Модуль заменяет встроенные видео с Vimeo и Youtube на кликабельные изображения. Загрузка ролика начнется только после клина пользователя на превью. Используется поэтому никаких дополнительных скриптов не нужно. В принципе, у него есть достаточно много функций, он активно развивается + показатели скачивания (6тыс.) и оценка (4,5) весьма неплохие. В предыдущих модулях вы могли видеть также поддержку видеоконтента и iframes, но здесь гораздо больше разных опций. Думаю, Lazy Load for Videos идеально подойдет для видео-сервисов с подборками клипов, трейлеров, смешных роликов и т.п.

Эффективность отложенной загрузки

Как я уже сказал, работаю с модулем Lazy Load — проблем пока не возникает, картинки грузятся только при прокрутке, причем достаточно быстро. Лично я никаких специальных замеров не проводил, ориентируюсь исключительно на визуальный эффект, который наблюдаю «до» и «после».

Можно заметить, как ленивая загрузка изображений и контента с помощью a3 Lazy Load значительно отличается по показателям у других методов. Все дело в обработке картинок:

По умолчанию WordPress передает браузеру все доступные значения размеров , которые имеются. Тот в свою очередь загружает наименьшую версию, доступную для текущего размера окна.
Модули BJ Lazy Load, Lazy Load XT подменяют базовую функцию системы и атрибуты в коде, что позволяет использовать полноценную версию картинки.
Решение a3 Lazy Load полностью копирует логику Вордпресс — то есть считываются минимально возможные по объему файлы.

Не смотря на меньшее число запросов и итоговый вес в последнем варианте, BJ Lazy Load все равно оказывается быстрее. Дело в том, что плагин отправляет в браузер информацию вида data:image/gif, которая вынуждают его создавать gif файлы локально, а не скачивать с сервера (через HTTP запросы).

Однако тут есть один очень важный момент — отложенная загрузка изображений в BJ Lazy Load будет хорошо работать, если сами картинки были оптимизированы ранее . То есть, допустим, пользователь добавляет на сайт 10 фоток 3000х2000 пикселей — в таком случае вы рискуете получить глюк, когда при прокрутке страницы во время загрузки графики будут выводится белые непрозрачные блоки-прелоадеры.

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

Итого

Можно сделать следующие выводы:

Если вы используете оптимизированные изображения через программы или Tinypng, то самый быстрый вариант BJ Lazy Load (при сравнении трех модулей).
Когда фото вставляются на сайте «как есть» (с большим разрешением), оптимальнее будет решение a3 Lazy Load, которое кроме ленивой загрузки использует встроенную в WP логику работы с графикой.
Могу также посоветовать плагин, которым пользуюсь я — Lazy Load. Каких-либо тестов не проводил, но там крутые разработчики и максимум скачиваний.
Если будете пробовать другие решение, желательно проверять их эффективность.

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

8 ответов

Вы можете использовать шаблон Observer. Простой функциональный способ выполнить это:

Вывод:

This is my CRAZY application 4 + 5 = 9 4 * 5 = 20

Примечания:

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

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

Извините, похоже, символы подчеркивания заменяются объектами HTML Markdown? Я могу повторно опубликовать этот код, когда эта ошибка будет исправлена.

Edit: Nevermind, он появляется только тогда, когда вы редактируете

Итак, скажем, вам не нужен шаблон Observer, потому что он требует, чтобы вы изменили методы класса для обработки задачи прослушивания и хотите получить что-то общее. И скажем, вы не хотите использовать наследование extends , потому что вы уже можете наследовать свой класс из какого-то другого класса. Было бы здорово иметь общий способ сделать любой класс подключаемым без особых усилий? Вот как:

_Class = get_class(&$RefObject); $this->_RefObject = $RefObject; } public function __set($sProperty,$mixed) { $sPlugin = $this->_Class . "_" . $sProperty . "_setEvent"; if (is_callable($sPlugin)) { $mixed = call_user_func_array($sPlugin, $mixed); } $this->_RefObject->$sProperty = $mixed; } public function __get($sProperty) { $asItems = (array) $this->_RefObject; $mixed = $asItems[$sProperty]; $sPlugin = $this->_Class . "_" . $sProperty . "_getEvent"; if (is_callable($sPlugin)) { $mixed = call_user_func_array($sPlugin, $mixed); } return $mixed; } public function __call($sMethod,$mixed) { $sPlugin = $this->_Class . "_" . $sMethod . "_beforeEvent"; if (is_callable($sPlugin)) { $mixed = call_user_func_array($sPlugin, $mixed); } if ($mixed != "BLOCK_EVENT") { call_user_func_array(array(&$this->_RefObject, $sMethod), $mixed); $sPlugin = $this->_Class . "_" . $sMethod . "_afterEvent"; if (is_callable($sPlugin)) { call_user_func_array($sPlugin, $mixed); } } } } //end class Plugin class Pluggable extends Plugin { } //end class Pluggable //////////////////// // PART 2 //////////////////// class Dog { public $Name = ""; public function bark(&$sHow) { echo "$sHow
\n"; } public function sayName() { echo "
\nMy Name is: " . $this->Name . "
\n"; } } //end class Dog $Dog = new Dog(); //////////////////// // PART 3 //////////////////// $PDog = new Pluggable($Dog); function Dog_bark_beforeEvent(&$mixed) { $mixed = "Woof"; // Override saying "meow" with "Woof" //$mixed = "BLOCK_EVENT"; // if you want to block the event return $mixed; } function Dog_bark_afterEvent(&$mixed) { echo $mixed; // show the override } function Dog_Name_setEvent(&$mixed) { $mixed = "Coco"; // override "Fido" with "Coco" return $mixed; } function Dog_Name_getEvent(&$mixed) { $mixed = "Different"; // override "Coco" with "Different" return $mixed; } //////////////////// // PART 4 //////////////////// $PDog->Name = "Fido"; $PDog->Bark("meow"); $PDog->SayName(); echo "My New Name is: " . $PDog->Name;

В первой части, что вы можете включить с вызовом require_once() в верхней части вашего PHP скрипт. Он загружает классы, чтобы сделать что-то подключаемое.

В части 2, где мы загружаем класс. Примечание. Мне не нужно было делать ничего особенного для класса, который существенно отличается от шаблона Observer.

В части 3, где мы переключим наш класс на "подключаемый" (т.е. поддерживаем плагины, которые позволяют нам переопределять методы и свойства класса). Так, например, если у вас есть веб-приложение, у вас может быть реестр плагинов, и вы можете активировать плагины здесь. Обратите внимание также на функцию Dog_bark_beforeEvent() . Если я установил $mixed = "BLOCK_EVENT" перед оператором return, он заблокирует собаку от лая и также заблокирует Dog_bark_afterEvent, потому что не будет никакого события.

В части 4, что нормальный код операции, но обратите внимание, что то, что вы могли бы подумать, будет работать не так. Например, собака не объявляет его именем "Fido", но "Coco". Собака не говорит "мяу", но "Уоф". И когда вы захотите посмотреть имя собаки потом, вы обнаружите, что это "Разное", а не "Коко". Все эти переопределения были представлены в части 3.

Итак, как это работает? Ну, пусть исключают eval() (которые все говорят "злые") и исключают, что это не шаблон Observer. Таким образом, способ, которым это работает, - это скрытый пустой класс под названием Pluggable, который не содержит методов и свойств, используемых классом Dog. Таким образом, поскольку это происходит, магические методы будут задействованы для нас. Поэтому в частях 3 и 4 мы связываемся с объектом, полученным из класса Pluggable, а не с самим классом Dog. Вместо этого мы позволяем классу Plugin "касаться" объекта Dog для нас. (Если это какой-то дизайн, о котором я не знаю - сообщите мне.)

Метод крюка и слушателя является наиболее часто используемым, но есть и другие вещи, которые вы можете сделать. В зависимости от размера вашего приложения и того, кто хочет увидеть код (это будет FOSS script, или что-то в доме), сильно повлияет на то, как вы хотите разрешить плагины.

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

1 к kdeloach от меня.

Вот подход, который я использовал, это попытка скопировать из механизма Qt сигналов/слотов, своего рода шаблон Observer. Объекты могут излучать сигналы. Каждый сигнал имеет идентификатор в системе - он состоит из идентификатора id + объекта-отправителя Каждый сигнал может быть привязан к приемникам, который просто является "вызываемым", Вы используете класс шины для передачи сигналов любому, кто заинтересован в их получении Когда что-то происходит, вы посылаете сигнал. Ниже приведен пример и пример реализации

Я считаю, что самый простой способ - следовать советам Джеффа и взглянуть на существующий код. Попробуйте посмотреть на Wordpress, Drupal, Joomla и другие известные PHP-CMS, чтобы посмотреть, как выглядят и ощущаются их API-интерфейсы. Таким образом, вы даже можете получить идеи, о которых вы, возможно, раньше не думали, чтобы сделать вещи немного более густыми.

Более прямой ответ заключался бы в том, чтобы написать общие файлы, которые они бы включили в include файл, чтобы обеспечить удобство использования. Это будет разбито на категории и НЕ предоставлено в одном файле "hooks.php" MASSIVE. Будьте осторожны, потому что то, что заканчивается, заключается в том, что файлы, которые они включают, в конечном итоге имеют все больше и больше зависимостей и функциональности. Попытайтесь ограничить зависимость API. I.E меньше файлов для их включения.

Там аккуратный проект под названием

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

Конечно, проще и привычнее пойти традиционным путем и тупо вставить сниппет в файл functions.php вашей активной темы. Но в 9 из 10 случаев будет целесообразнее и правильнее вынести код сниппета в отдельный плагин . В крайнем случае, добавить его в специальный функциональный плагин вашего сайта. Т.н. Site-Specific WordPress Plugin , в котором-то и будет храниться весь дополнительный функционал вашего сайта.

Зачем это нужно

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

Как же быть

Нужно понять простую истину. В файле функций темы должны располагаться только функции, относящиеся к дизайну вашего сайта. Конкретно к той теме, файл функций которой редактируется. А вся т.н. «механика», рабочий функционал сайта и все его кастомизации правильнее размещать в плагинах. Или в одном плагине. Тогда при смене темы, он останется нетронутым.

Создаем специальный плагин функций WordPress

На самом деле, все делается очень просто.

В директории плагинов вашего WordPress создаете папку. Например: /wp-content/plugins/mysite-plugin/ ;
Создаете в этой папке файл, назвав его, к примеру, my-plugin.php ;
Вставляете в этот файл примерно такой код:
Переходите в настройки управления плагинами и активизируете свой новый плагин.

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

На этом можно и остановиться, но с моей стороны было бы не совсем правильно не упомянуть про т.н. MU-плагины .

MU-плагины (Must Use Plugins)

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

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

Преимущества MU-плагинов

MU-плагины не нужно активировать, они всегда активны, их невозможно отключить в консоли управления сайтом;
MU-плагин подключается и активируется банальной закачкой файла плагина в директорию mu-plugins;
MU-плагины загружаются в алфавитном порядке перед загрузкой обычных плагинов.

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

В заключение

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

Возможно, будет полезно почитать: