Главная » Ошибки Windows 7 » Отложенная загрузка изображений — плагины Lazy Load для WordPress. Плагины — Документация Webasyst Как работать с описанной ниже функцией

Отложенная загрузка изображений — плагины Lazy Load для WordPress. Плагины — Документация 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/
В него мы помещаем нужные файлы-плагины. В отличие от обычных плагинов, здесь не нужно выдерживать специальный синтаксис, а функционал можно объявлять напрямую

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

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

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

cms mysql (4)

Я пытаюсь создать базовую систему плагинов, подобную той, которую вы часто находите в CMS, например WordPress. У вас есть папка плагинов, которые привязываются к операции основной системы с помощью уведомлений о событиях с использованием шаблона проектирования Observer или Event .

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

Существуют ли альтернативные способы сделать это?

Например, есть ли способ загрузить все это один раз, а затем кешировать результаты, чтобы ваша система знала, как плагины для ленивой загрузки? Другими словами, система загружает файл конфигурации, в котором указаны все события, которые плагин хочет связать, а затем сохраняет их в APC или что-то для будущих запросов?

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

Answers

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

/** * api: whatever * version: 0.1 * title: plugin example * description: ... * config: * depends: otherplugin */ $plugins [ "title_event" ] = "TitleEventClass" ; $plugins [ "secondary" ] = array ("Class2" , "callback" ); ?> В этом примере я предполагаю, что API плагина является простым списком. Этот пример скрипта feature-plugin-123.php ничего не делает, кроме добавления в массив при загрузке. Таким образом, даже если у вас есть дюжина плагинов функций, это приведет только к дополнительному include_once каждому. Но основное приложение / или API-интерфейс плагина может вместо этого просто создавать экземпляры упомянутых классов (либо new $eventcb; для raw- call_user_func_array либо call_user_func_array для обратных вызовов). В свою очередь, это приведет к загрузке фактической задачи автозагрузчику. Таким образом, у вас есть двойная система, где одна часть управляет списком, другая - реальный код. Я тем самым все еще воображаю простой config.php который просто перечисляет плагины и настройки, подобные этому: "user/wrapper-for-htmlpurifier.php" ); $cfg [ "pretty" ] = 1 ; Снова принимая во внимание, что это просто оболочки / сценарии данных, с описанием плагина для управляемости. Можно также использовать фактический API-интерфейс register_even() и определить дополнительную функцию-обертку в каждом. Но список классных имен кажется самым простым вариантом. Вышеупомянутый инструмент управления выглядит ржавым и уродливым: http://milki.include-once.org/genericplugins/ Но он не используется, если вам нужен только список (таблица sql) и управление настройками. Эти накладные расходы предназначены только для красивой печати метаданных плагина и сохранения удобочитаемого config.php . В заключение: spl_autoload() в include_path и простой регистр event-> classname, один скрипт-оболочка каждый, просто включается все сразу. Я бы сохранил имя класса плагина вместе с его подписанными событиями в файле конфигурации, а затем сохранил проанализированный файл конфигурации в APC, например. Затем, когда событие запускается, система может ленить загружать соответствующие классы плагинов по мере необходимости. Wordpress и другие системы CMS - очень плохие примеры. Мы должны понимать, что модульная, почти всегда означает, что она тяжелее. Лучшей схемой, с которой я когда-либо работал, чтобы решить эту ситуацию, является плагин на основе класса, со строгим соглашением об именах, использующим автозагрузчик. Таким образом, перед использованием плагина вам нужно создать экземпляр или использовать статические функции. Вы даже можете вызвать плагин: например: "/plugins/{$parts}/{$parts}.php" ); break ; } // ... } ?> Что касается событий: Вы должны регистрировать это событие статически, чтобы избежать динамического изменения. База данных будет правильным местом для этого. У вас могут быть таблицы событий и методы install () и uninstall () в классе плагина для добавления определенных событий или привязки методов к другим событиям. Это один запрос к базе данных, и если вы хотите получить больше от него, добавьте его в memcached или в плоский ini-файл. Хорошо работает для меня. Таким образом, мне удалось получить тяжелую систему, которая потребляла 8 мб на запрос, чтобы упасть до 1 Мб, с точно таким же списком функций, без предварительного кэширования. Теперь мы можем добавить больше возможностей и поддерживать систему «чистой», надеюсь, это поможет Лучший способ - начать кодирование с ними. Шаблоны дизайна - отличная концепция, которую трудно применить, просто прочитав о них. Возьмите несколько примеров реализаций, которые вы найдете в Интернете и создадите вокруг них. Отличным ресурсом является страница « Данные и объект» . Они просматривают шаблоны и дают вам как концептуальные, так и реальные примеры. Их справочный материал тоже замечательный. Файл функций — занимательный помощник в расширении функционала сайта! особливо, если используется по назначению, — однако, многие владельцы блогов/сайтов замечательным образом превращают 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. Каких-либо тестов не проводил, но там крутые разработчики и максимум скачиваний. Если будете пробовать другие решение, желательно проверять их эффективность. У кого есть что еще добавить по теме отложенной загрузки картинок и контента, пишите в комментариях. Наверняка, вы не раз сталкивались с тем, что нужно добавить какой-то кусок кода для вашего сайта на WordPress, чтобы добавить новую функциональность. Я говорю сейчас не о скриптах Google аналитики, которые вы вставляете в header часть вашей темы. Нет. Я о тех маленьких фрагментах кода, которые вы нашли на форумах в интернете и сразу же побежали добавлять их в свой файл functions.php . Давайте будем честны, ведь вы хоть раз делали это, не так ли? И это понятно, ведь на форуме так и было написано - добавьте этот код в functions.php вашей темы на WordPress. Правда в том, что добавлять каждый найденный в интернете код в functions.php - не всегда хорошая идея . Более безопасным решением будет создать свой кастомный мини плагин с этим кодом. В этом уроке мы расскажем, в каких случаях можно добавлять код в functions.php, а в каких лучше использовать отдельный плагин. Также мы покажем, как вы можете сами создать кастомный плагин и добавить в него свой код. Что такое functions.php Если вы когда либо лазили по файлам вашего WordPress сайта, вы могли наткнуться на несколько файлов functions.php. Файл functions.php, о котором мы будем говорить в этом уроке, находится в папке: wp-contentthemesваша_темаfunctions.php. Очевидно, это тот самый файл, который хранит все функции и настройки вашей конкретной темы, активной в данный момент . Обратите внимание на слово "активной", потому как в этом и будет крыться основной посыл этого урока. Почему всегда использовать functions.php - это плохая идея Не поймите неправильно, использовать functions.php для маленьких кусочков кода в пару строк - это вполне нормальная ситуация. Мы говорим о том, что нежелательно использовать functions.php как склад для абсолютно всего добавленного вами кода. Это не универсальное решение для любой ситуации. Причина №1. Если выйдет обновление для вашей темы оформления, вы потеряете всё, что вы дописали в файле functions.php. Я знаю, о чем вы только что подумали - но ведь есть как раз для таких ситуаций? Конечно есть. Но есть также много людей, которые понятия не имеют, что такое дочерняя тема. Или есть люди, которые обратились к вам за помощью добавить кусок кода в их тему. Поэтому эта причина находится в этом списке. Если вы добавляете код в functions.php без использования дочерней темы, это ваш первый тревожный звоночек. Причина №2. Даже если вы правильно настроили и используете дочернюю тему. Что случится, если вы захотите перейти на другую тему оформления? Я надеюсь, вы добавили комментарий к каждому внесенному изменению в вашем файле functions.php, потому как без этого переход на другую тему будет крайне болезненным. Думаю, вы уловили мысль. Причина №3. Если вы добавили код в functions.php, который совершенно неожиданным образом полностью сломал ваш сайт, и вы видите пустой белый экран - вам понадобится FTP клиент, чтобы закачать "испорченный" functions.php, отредактировать его и загрузить обратно на сайт. Удовольствие такое себе. Когда можно использовать functions.php Правильное использование functions.php для дочерней темы, активной в данный момент - это допустимый вариант. Но помните, я акцентировал внимание на этом слове "активной "? Если вы добавляете порции кода, которые будут иметь смысл только в работе с конкретно этой темой, тогда вы можете смело использовать functions.php (в дочерней теме). Вот несколько примеров, когда это будет уместно: Добавление еще одного файла стилей (.css) для вашей темы Изменение длины для анонса записи (post excerpt), чтобы сайт выглядел лучше Добавление кастомных шрифтов для текущей темы Добавление файла локализации для перевода текущей темы Другими словами, каждый раз при добавлении или изменении чего-либо, связанного с конкретной текущей темой, вы можете смело использовать functions.php. Когда лучше обойтись без functions.php Использовать functions.php для добавления более глобальных вещей и функций, которые вам теоретически могут пригодиться и для другой темы - вот это плохая идея. Вот пару примеров, когда лучше обойтись без functions.php: Создание кастомных виджетов, которые вы будете часто использовать Создание кастомных шорткодов Добавление кода, который не зависит от темы оформления (код Google Analytics и т.д.) В таких случаях лучше сохранять этот код независимо от вашей темы оформления. И вы можете сделать это с помощью кастомных плагинов. Вы сейчас подумали - ломать голову над созданием плагина, когда можно отредактировать functions.php? Это слишком сложно! Поверьте, это не так. Это делается очень легко и быстро. Как настроить кастомный плагин вместо functions.php Чтобы создать свой кастомный плагин для хранения вашего кода, вам нужно: Создать текстовый файл с вашим кодом и сохранить его как.php файл Запаковать полученный.php файл в.zip архив Установить этот архив как обычный WordPress плагин в меню Плагины → Добавить новый Вот и все, всего 3 действия. Шаг 1. Создание.php файла с вашим кодом Откройте Блокнот на вашем компьютере и вставьте следующий текст: Конечно, вы можете использовать свое имя для плагина в строке Plugin Name: Сохраните файл и дайте ему какое-то уникальное имя, чтобы WordPress не перепутал ваш плагин с уже установленными. Например: wpcafe-custom-functions.php. Да, не забудьте при сохранении выбрать тип файлов "Все файлы" и дописать расширение.php: Шаг 2. Создайте.zip архив Думаю, тут не нужно никаких пояснений. Просто создайте.zip архив с вашим файлом любым удобным архиватором. Шаг 3. Установите как обычный плагин Самая простая часть. Просто зайдите в админке WordPress в Плагины → Добавить новый и загрузите ваш архив как самый обычный плагин. Как только вы активируете его, вы сможете увидеть свой новый плагин в списке всех других установленных плагинов: Как добавлять свой код Чтобы добавить свой фрагмент кода, просто вставляйте его в файл.php, который вы создали. Или вы всегда можете сделать еще один отдельный плагин для двух разных функций. Например, вот так будет выглядеть ваш файл.php, если вы захотите сделать шорткод "Hello World!": Эти комментарии никак не влияют на работоспособность вашего кода и на скорость выполнения плагина. Но с ними вам будет проще ориентироваться и помнить, что делает каждая функция, которую вы добавили. Просто оберните свой комментарий в синтаксис из косой и звездочки: /* Ваш комментарий */ После внесения изменений в ваш код вы можете перезагрузить.php файл через FTP или просто создать новый.zip архив и загрузить как новый плагин, а старый удалить. Другие способы как избегать правок functions.php По большому счету, если вы достаточно уверены в своих силах и знаете, как добавлять код в functions.php, у вас не должно возникнуть никаких трудностей и с кастомными плагинами. Здесь нет ничего сложного. Но мы прекрасно понимаем, если у вас нет желания возиться со всем этим вручную. Все же, это WordPress. Поэтому вам может пригодиться бесплатный плагин Code Snippets , который позволяет легко добавлять ваш дополнительный код на сайт: С этим плагином вы можете добавлять разные сниппеты с кодом, давать им название, описание, активировать и отключать выборочно тот или иной фрагмент кода. Другая классная особенность состоит в том, что вы можете импортировать/экспортировать ваши фрагменты кода между сайтами. Итоги Это может показаться незначительной мелочью, но правильное расположение вашего дополнительного кода позволит в дальнейшем без проблем переключаться между другими темами оформления. Также вы можете по-отдельности включать или отключать ту или иную функциональность, если вы разделите каждую дополнительную функцию между отдельными плагинами. Так что, этот метод действительно заслуживает внимания.