Відкладене завантаження зображень - плагіни 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 Pl uggable //////////////////// // 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 менше файлів для їх включення.

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