Отложенная загрузка изображений — плагины Lazy Load для WordPress. Лучший способ разрешить плагины для PHP-приложения Вялый plugin php

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И к тому же:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наверняка, вы не раз сталкивались с тем, что нужно добавить какой-то кусок кода для вашего сайта на 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

Чтобы создать свой кастомный плагин для хранения вашего кода, вам нужно:

1. Создать текстовый файл с вашим кодом и сохранить его как.php файл
2. Запаковать полученный.php файл в.zip архив
3. Установить этот архив как обычный 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 , который позволяет легко добавлять ваш дополнительный код на сайт:

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

Другая классная особенность состоит в том, что вы можете импортировать/экспортировать ваши фрагменты кода между сайтами.

Итоги

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

Так что, этот метод действительно заслуживает внимания.

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 Мб, с точно таким же списком функций, без предварительного кэширования. Теперь мы можем добавить больше возможностей и поддерживать систему «чистой»,

надеюсь, это поможет

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

Отличным ресурсом является страница « Данные и объект» . Они просматривают шаблоны и дают вам как концептуальные, так и реальные примеры. Их справочный материал тоже замечательный.

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

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

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

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

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 + объекта-отправителя Каждый сигнал может быть привязан к приемникам, который просто является "вызываемым", Вы используете класс шины для передачи сигналов любому, кто заинтересован в их получении Когда что-то происходит, вы посылаете сигнал. Ниже приведен пример и пример реализации

login(); ?>

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

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

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