У цій статті описано, як дуже докладно розібрати процес створення простого модуля для DLE з кешуванням і власними шаблонами. Спочатку розберемо модуль без шаблону, а після доповнимо його власним шаблоном. Підсумком статті буде працездатний модуль без адмінки, що викликається в будь-якому місці сайту через рядок підключення.
Природно результат роботи модуля краще кешувати тому зайві запити в БД нам абсолютно не потрібні. Так само нам не потрібен шаблон модуля, але для прикладу я наведу код модуля і з шаблоном, тому що правильне підключення шаблону теж дуже важливо і при більш-менш складному модулі економить багато ресурсів за рахунок зменшення коду самого модуля.
Коло завдань визначено, можна приступати до написання коду. Згадуємо що у DLE є API. і цілком логічним здається використання готового API для цього завдання, але я вкрай не рекомендую взагалі його використовувати навіть (особливо!) в складних модулях.
Чому не варто використовувати DLE_API
Все просто - це вкрай крива штука, яка не розвивається аж з версії 8.2 (на момент написання поточна версія движка - 10.0 і в порівнянні з попередньою версією пофіксити лише баг з неможливістю реєстрації користувача через api, ніяких доробок не проводилося).
Використання dle_api значно збільшує витрату оперативної пам'яті. що зовсім, зовсім не добре.
Методи, описані в dle_api розходяться з оригінальним функціоналом.
Загальна рада: якщо вам потрібна будь то метод або функція з dle_api - просто скопіюйте її в свій модуль.
Можливо моїх скромних напрацювань вистачить на набір методів і функцій, які можна буде використовувати в подальшому, але це тема для окремої статті.
пишемо код
Перш, ніж писати будь-модуль (крім файлів, що відповідають за ajax), потрібно в обов'язковому порядку, на самому початку прописати один рядок:
Це не дозволить користувачеві звернутися до файлу модуля безпосередньо, а значить він не зможе передати власні параметри в модуль і зламати сайт через цей модуль. Думаю важливість цього моменту важко переоцінити, але тим не менше я дуже часто натикаюся на відсутність подібної конструкції в коді модуля.
Конфігурація і кешування
Я вирішив зупинитися на цьому моменті докладно, тому що це один з найбільш частих питань, які задаються, якщо людина вирішила написати свій модуль.
Конфігурацію модуля найкраще записувати в масив - це дасть можливість безпроблемного створення кеша для кожного виклику модуля з різним набором конфігурації, в нашому випадки для кожного користувача.
Поясню чому. Припустимо ми написали модуль, він кешируєтся, і рядок створення кеша виглядає наступним чином:
де:
- $ Var1. $ Var2. $ Var3. $ Var4 - змінні модуля.
- $ MyModule - текст, який повинен записатися в кеш.
а рядок створення кеша буде така:
Таким чином нам взагалі не доведеться лазити в цей код ніколи, все буде відбуватися автоматично.
Використовуйте префікси і суфікси кеша - це дозволить гарантувати автоматичне очищення кеша, а так само дозволить (при необхідності) створювати окремі кеши для різних груп користувачів.
Для наочності поясню погляньте на картинку:
Значить в нашому випадки потрібен префікс archives тому кеш модуля треба скидати тільки при додаванні або видаленні новини (він мені просто сподобався, можна використовувати і calendar і rss). Код конфіга і створення кеша тут наводити не буду щоб не захаращувати статтю, весь код модуля можна подивитися нижче.
Текст кеша - це результат роботи модуля, який буде записаний в кеш, тут все просто.
ID кеша або його ім'я - сюди найкраще передавати змінну $ cacheName, про яку писалося вище і змінну $ config [ 'skin'] - це для того, щоб мати різні кеши для різних шаблонів сайту.
Префікс кеша - може приймати два значення true або false, якщо передано значення true, то для кожної групи користувачів буде створюватися свій кеш-файл, це буває потрібно, якщо різним групам користувачів потрібно показувати різний контент.
Універсальна заготовка для модуля з кешем, без шаблону
З огляду на все вище написане ми можемо створити просту заготовку для модуля, який буде використовувати кеш, але не буде в своїй роботі використовувати шаблон. Всього 15 рядків коду! Все досить просто, правда?
Невеликий відступ:
Я раджу використовувати однаковий тип змінних модуля і змінних конфіга модуля, тобто
виглядає набагато більш Новомосковскбельним, ніж
Однак використання нижньої межі я не практикую в dle, тому що разок через це спрацював фільтр в dle і модуль не відпрацьована, хоча можливо це лише одиничний випадок.
Тепер можна вивести результат по нормальному:
Тут слід зазначити, що якщо в кеш буде записаний один нулик - dle його не буде "вважати кешем" і створить новий, тому потрібно писати туди щось, відмінне від нуля.
Підсумковий код нашого модуля буде таким: Всього 20 рядків коду - і отримуємо готове рішення конкретної проблеми.
Код модуля цілком робочий і його можна використовувати в реальному проекті, проте наведено цей код для ознайомлення з принципами правильного написання модулів для DLE.
На цьому можна було б закінчити, але вище я обіцяв показати код модуля з використанням власного шаблону.