Плагины - это способ расширить функциональность приложения без изменения его исходного кода. Функции, реализованные плагином, продолжают работать после установки обновлений приложения, когда перезаписываются его файлы. Исходный код плагина оформляется в независимых файлах, которые лишь подключаются к приложению.
Локализация
Локализация плагинов реализуется полностью аналогично локализации приложений (документация). В папке locale следует разместить файлы переводов *.po и *.mo и подключать ключи в коде следующим образом:
- _wp("string") в PHP (вместо метода _w(), который работает только с локализацией приложения, следует использовать метод _wp(), подгружающий локализацию плагина),
- [`string`] в шаблонах Smarty (здесь нет отличий от локализации приложений).
Название и описание плагина (name и description в конфигурационном файле) переводятся с использованием локализации плагина по умолчанию, таким образом указывать "name" => _wp("НАЗВАНИЕ ПЛАГИНА") не надо - достаточно просто указать "name"=>"НАЗВАНИЕ ПЛАГИНА" .
Использование локализации в статических методах
В случае вызова публичных статических методов классов плагина во внешнем окружении, например, в коде темы дизайна, локализация плагина автоматически не подключается, и функция _wp() не возвращает перевод строки, как ожидалось. Для того чтобы использовать локализацию плагина в таких методах, необходимо помещать все вызовы функции _wp() внутри специальной конструкции, выделенной жирным шрифтом в показанном ниже примере:
Class appMyPlugin extends waPlugin { public static function displayData() { //в обеих строках укажите ID приложения и своего плагина waLocale::loadByDomain(array("app_id", "plugin_id")); waSystem::pushActivePlugin("plugin_id", "app_id"); $result = _wp("..."); waSystem::popActivePlugin(); return $result; } }
База данных
Если плагин использует собственные таблицы в базе данных, то имена таблиц должны начинаться с фрагмента вида __ , например: shop_ebay_ tablename .
Подключение плагина
Для того чтобы написанный плагин заработал, необходимо подключить его в системном конфигурационном файле приложения wa-config/apps/ APP_ID/plugins.php , добавив в него строку:
"plugin_id" => true
Пример этого файла для приложения «Блог» (wa-config/apps/blog/plugins.php):
true, "tag" => true, "category" => true, "gravatar" => true, "favorite" => true, "troll" => true,);
В этом же файле можно отключить ненужные плагины.
install.php и uninstall.php
Если при установке плагина требуется выполнить какие-то нестандартные действия (например, добавить новые поля в существующие таблицы приложения), то логику таких действий необходимо описать в конфигурационном файле lib/config/install.php . Пример добавления дополнительного поля в таблицу при установке плагина:
$model = new waModel(); try { $model->query("SELECT `custom_field` FROM `shop_product` WHERE 0"); } catch (waDbException $e) { $model->exec("ALTER TABLE `shop_product` ADD `custom_field` INT(11) UNSIGNED NULL DEFAULT NULL"); }
Действия, которые нужно выполнить при удалении плагина, аналогичным образом описывайте в файле lib/config/uninstall.php .
Создание и удаление собственных таблиц плагина в файлах install.php и uninstall.php описывать не нужно — таблицы автоматически создаются и удаляются на основании содержимого другого конфигурационного файла: db.php . См. « ».
Пример
Плагинная платформа была внедрена во фреймворк вместе с приложением «Блог », поэтому для дальнейшего изучения рекомендуем установить это приложение и рассмотреть плагины, написанные для него (плагины устанавливаются через «Инсталлер»). Для «Блога» написаны плагины различной направленности и практического применения: для фронтенда, бекенда, расширяющие возможности пользовательского интерфейса, выгрузки данных и пр.
Приветствуют, друзья. Сегодня мы с вами разберемся в том, как заставить работать любой PHP код в виджетах, статьях и на страницах WordPress. По умолчанию такая функция в этой CMS недоступна и максимум, на что может рассчитывать пользователь – это внедрение HTML кода.
Почему PHP код не работает по-умолчанию
Казалось бы, почему разработчики не наградили столь популярный и удобный движок полезными возможностями по автоматическому исполнению PHP кода. Поначалу я задумывался об этом, но пришел к выводу, что такая политика ведется с позиции безопасности, ведь, неумелое применение PHP в виджетах или внутри записей может привести к непоправимым последствиям – в базе данных что-нибудь нарушится и весь сайт крякнет.
Поэтому, работа с PHP отдана на откуп программистов или людей более менее продвинутых в этом вопросе – непосредственно в файлах любые скрипты исполняются.
Для публичных сайтов (там, где несколько авторов) исполнение PHP в теле статьи повышается риск умышленного саботажа, так как любой автор может получить полный доступ к сайту через окно редактирования статей.
По степени опасности я бы разделил всю эту ситуацию на 3 уровня:
- Оставить все как задумали разработчики – безопасно, случайно или умышленно повредить сайт сложно.
- Разрешить исполнение PHP в виджетах – средний уровень опасности, только администратор сайта имеет доступ.
- Применение кода везде – опасно, так как управлять сайтом может каждый кто допущен к редактированию статей и страниц (модераторы, авторы)
Для чего нужен PHP в виджетах
Вопрос индивидуальный, так как реализовать с помощью этого языка программирования можно все что угодно. Лично меня к написанию этого поста подтолкнул заказ клиента, сайт которого я сейчас делаю. На нем необходимо было вывести в сайдбаре в отдельном виджете список новостей из одной рубрики – «Новости». В стандартных виджетах WordPress нет такой возможности.
Вопрос стоял между поиском плагина с соответствующими возможностями или применением несложного PHP кода. Скрипт для такой задачи, действительно, небольшой и нагружать сайт лишним плагином, который больше нигде использоваться не будет, не хотелось.
В целом, разрешая исполнение PHP, мы можем решить 2 задачи:
- Заменить часть плагинов сайта на скрипты и снизить таким способом нагрузку на хостинг;
- Реализовать функции, для которых плагинов пока не существует.
На первом этапе я расскажу о виджетах, а потом, отдельным блоком про вывод кода в контенте.
Плагины для PHP в виджетах
Преимущество плагинов: При смене темы оформления WordPress не нарушается работа функций добавленных в шаблон, все продолжает работать не требуя вмешательства вебмастера. Хуки добавленные в шаблон при смене темы придется переносить на новую вручную.
В моем примере выше, я делаю сайт для клиента и, если он захочет самостоятельно сменить дизайн, то пропадут настройки, которые сделаны через файлы functions.php и др., поэтому я максимально упрощаю ему управление сайтом, опираясь на плагины (тем более, в его нише трафик невелик и нагрузки много не будет).
PHP Code Widget
Этот плагин я давно использую в своей работе, он добавляет в список доступных виджет, похожий на обычный текстовый, только способный обрабатывать кроме текста и HTML еще и PHP.
PHP Code Widget присутствует в официальном репозитарии WordPress, легко находится по названию. Как устанавливать такие плагины .
Настроек не требуется, виджет в списке появится сразу после установки и активации плагина. В сайдбар перетаскиваете «PHP Code» и добавляете туда любой скрипт.
PHP в виджете WordPress без плагина
В этом случае нам потребуется хук, который будет подменять стандартную функцию, обеспечивающую работу текстового WordPress виджета, функцией разрешающей обрабатывать PHP.
Такой хук добавляется в файл functions.php текущей темы (в самом конце перед закрывающей скобкой?>). После этого, новых вариантов виджета, как в случае с плагином, не появляется, PHP коды начинают работать в стандартном текстовом.
Готовый код:
Add_filter("widget_text"," text_html_php_widget ",100); function text_html_php_widget($text) { if(strpos($text,"".$text); $text = ob_get_contents(); ob_end_clean(); } return $text; }
Первая строка является фильтром, который заменяет при каждом вызове стандартную функцию текстового виджета на новую – text_html_php_widget, а далее идет описание самой новой функции.
Зачем PHP код в статьях и постах WordPress
Внутри записей исполняемый PHP код требуется значительно реже, чем в виджетах, поэтому в первой части статьи я отдельно рассматривал сайдбар, чтобы вы могли не подключать потенциально опасные функции без необходимости.
Но и в постах бывает потребность использования скриптов. Самый частый пример – это вывод карты сайта без плагина. Правда, для карты можно использовать другой приём – сделать специальный шаблон страницы (это отдельная тема).
Мне однажды понадобилось выводить PHP для следующей цели:
Делал я видео сайт. Серии сериала выводились в плейлистах по сезонам и надо было под каждым плейлистом сезона вывести список серий со ссылкой на свою страницу. Похоже на карту сайта, только сложнее – вывод делать надо было списками отдельных рубрик. Можно было вручную HTML кодом каждую ссылку прописать, но там несколько сот серий и процедура муторная. Тем более, при появлении новой серии ссылку на нее пришлось бы добавлять вручную – неудобно. Вот я и решил использовать PHP функции для реализации.
Плагин для исполнения PHP в контенте Exec-PHP
Несмотря на то, что этот плагин не обновлялся уже 7 лет, он прекрасно справляется с обязанностями. И я его выбрал не просто так – он не использует никаких шорткодов, как конкуренты, а дает возможность вставлять в записи WordPress код в чистом виде, начиная с .
Плагин Exec-PHP есть в репозитарии и устанавливается через меню в админке движка.
Из настроек есть только одна – разрешение/запрет на исполнение кода в текстовом виджете, возможности отключить работу в постах и на страницах отсутствует, если надо ее убрать – деактивируем плагин.
Для вставки PHP кода в статью, должен быть переведен в HTML режим (вкладка «Текст»). Визуальный режим, скорее всего, код попортит.
Выполнение PHP кода в статьях WordPress без плагина
По аналогии с виджетами, мы можем заменить плагин на специальную функцию, разрешающую выполнение PHP скриптов в контенте. К сожалению, мне не удалось найти вариант, при котором код работал бы автоматически как в случае с плагином, реагируя на теги. Требуется использование шорткода. Моих познаний в PHP не хватило для самостоятельного написания нужной функции, за сим привожу как есть. Работа с шорткодом имеет существенный недостаток, осложняющий работу, о нем я расскажу ниже.
Как работать с описанной ниже функцией
- Вставляем ее в файл functions.php темы;
- В нужном месте статьи вставляем конструкцию – исполняемый код без
Функция:
/* Запуск php в статьях и страницах WordPress: код */ function start_php($matches){ eval("ob_start();".$matches."$inline_execute_output = ob_get_contents();ob_end_clean();"); return $inline_execute_output; } function inline_php($content){ $content = preg_replace_callback("/\((.|\n)*?)\[\/startphp\]/", "start_php", $content); $content = preg_replace("/\((.|\n)*?)\[\/startphp\]/", "$1", $content); return $content; } add_filter("the_content", "inline_php");
Недостаток
Если внутри вставляемого PHP кода есть HTML вставки или текст, то он работать не будет. Любой текст или теги придется вставлять с помощью команды echo, что не всегда удобно. То есть, код должен быть чисто PHP-шный на 100 правильного формата.
Правильно
Echo "Так работать будет";
Неправильно
Echo "Эта строка правильная"; Так работать не будет
В плагине Exec-PHP такой заморочки нет – и текст и HTML исполнятся, но все элементы PHP кода должны быть обрамлены в соответствующие теги.
Для многих вебмастеров тема, описанная в этой статье открывает бесконечные возможности для творчества – можно реализовать то, чего раньше сделать не получалось, а также избавиться от массы плагинов, заменив их на разные фильтры, функции и хуки.
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 вашей активной темы. Но в 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. Вред может быть от большого количества одновременно работающих плагинов. Особенно с дублирующим функционалом. Возможен и банальный конфликт плагинов, плагинов с темой. А при грамотном и разумном подходе, плагины принесут вашему сайту исключительно пользу .
При работе в Интернете всем хочется, чтобы страницы сайтов загружались как можно быстрее, никому не нравится долго ждать завершения загрузки той или иной страницы. Причём это ожидание может затягиваться весьма существенно в тех случаях, когда изображений на странице великое множество. Присутствие изображений на странице делает страницу более привлекательной для посетителей, увеличивает наглядность и в конечном счёте, способствует повышению посещаемости вашего сайта. Однако приходится считаться с тем, что наличие изображений значительно утяжеляет страницы, увеличивая время их загрузки.
Медленная загрузка страниц отрицательно сказывается на SEO оптимизации вашего сайта. В настоящее время многие сайты используют в своих постах изображения в GIF или PNG -формате. Такие изображения имеют больший объём, чем изображения в формате JPEG, в результате загрузка страниц может занять ещё больше времени. Для загрузки каждого такого изображения требуется отдельный HTTP-запрос, что также не способствует ускорению загрузки.
Для решения этой проблемы применяется так называемая «ленивая» или отложенная загрузка, при которой загружаются только те изображения, которые необходимы пользователю. В данной статье приводится описание шести лучших бесплатных плагиновWordPress для “ленивой” загрузки, помогающих значительно повысить скорость загрузки страниц.
1. a3 Lazy Load — лучший плагин ленивой загрузки
Плагин ускоряет блог и повысить визуальный отклик страницы на ПК, планшетах и мобильных телефонах.
a3 Lazy Load не создает нагрузки на сайт и при этом является мобильно ориентированным. Простой в использовании плагин, который ускорит работы сайта. Чем больше на сайте будет тяжелых элементов, тем лучше плагин будет выполнять свою работу и тем больше вы увидите улучшений в производительности.
- Ленивая загрузка для всех изображений, граватары, видео и фреймов
- Выбор эффектов загрузки
- Поддержка WooCommerce
- Высокая производительность и низкой нагрузкой
- Можно делать исключения изображений и видео
- Резервная подключение JavaScript
- Поддержка всех браузеров
2. Lazy Load
Это плагин для отложенной загрузки изображений, разработанный WordPress.com, командой TechCrunch и Джеком Голдманом. Он имеет простой код, поэтому не перегружает ресурсы сервера.
Lazy – простой в установке и настройке плагин. Он практически не требует настройки, начиная работу сразу после установки.
Основные характеристики плагина:
- Простой код.
- Работает на WordPress.
- Простота в использовании.
- Использует jQuery.sonar.
3. BJ Lazy Load
BJ – ещё один бесплатный плагин WordPress для ленивой загрузки, который заменяет все ваши изображения, миниатюры, граватары и содержимое элементов iframe в отслеживаемой области “заглушкой”. Сами изображения подгружаются после появления в окне браузера. Такой способ позволяет ускорить загрузку страниц, а также сэкономить трафик пользователя.
Плагин имеет отзывчивый дизайн, позволяющий работать с мобильными устройствами. На мобильных устройствах изображения автоматически масштабируются в соответствии с размером экрана. Этот плагин имеет поддержку Retina, что означает возможность работы на устройствах Apple.
Основные характеристики плагина:
- Замена изображений “заглушкой”.
- Автоматическое изменение размеров изображений.
- Поддержка Retina.
- Экономия пользовательского трафика.
4. jQuery Lazy Load
jQuery – бесплатный плагин для “ленивой” загрузки, использующий Java-скрипт. Java-скрипт подгружает изображения только тогда, когда они оказываются в видимой области окна браузера.
jQuery – весьма популярный плагин из WordPress репозитория.
Основные характеристики плагина:
- Популярность.
- Использование Java-скрипта.
- Небольшой объём.
- Практически не нуждается в настройках.
5. Advanced Lazy Load
Это очень хороший плагин WordPress для ленивой загрузки, который подгружает изображения тогда, когда пользователь, прокручивая страницу, достигает области изображения. Этот плагин также использует jQuery-скрипт. Он позволяет уменьшать время загрузки, так как сначала загружается текст, а для изображений создаётся новое HTTP соединение.
То, что страницы не загружаются одновременно, позволяет уменьшить количество HTTP соединений и значительно снизить нагрузку на сервер.
Основные характеристики плагина:
- Использует jQuery-скрипты.
- Позволяет уменьшить количество HTTP соединений.
- Позволяет ускорить загрузку страниц.
- Имеет два типа настроек.
6. Unveil Lazy Load
Это очень небольшой плагин, использующий jQuery-скрипт. Он подгружает изображения с помощью скрипта объёмом всего 0.6 Кб. Плагин позволяет снизить нагрузку на сервер, уменьшая количество соединений.
Изображение подгружается в HTML код страницы по схеме data: URL, благодаря чему не требуется дубликат изображения, необходимый для “ленивой” загрузки.
Основные характеристики плагина:
- Использует jQuery-скрипты.
- Использует лёгкие скрипты.
- Использует схему с data: URL.
- Позволяет уменьшить количество соединений.
Заключение
В данной статье приведено описание бесплатных плагинов WordPress для «ленивой» загрузки изображений, которые помогут страницам вашего сайта WordPress загружаться быстрее. При помощи этих плагинов вы сможете просто творить чудеса. Напишите в комментариях о том, каким плагином для ленивой загрузки изображений вы пользуетесь.