У цій статті описано, як дуже докладно розібрати процес створення простого модуля для DLE з кешуванням і власними шаблонами. Спочатку розберемо модуль без шаблону, а після доповнимо його власним шаблоном. Підсумком статті буде працездатний модуль без адмінки, що викликається в будь-якому місці сайту через рядок підключення.
Чому не варто використовувати 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 рядків коду!
Все досить просто, правда?
Запит в БД і перевірки
Найпростіша перевірка - умова if else:
тобто ми просто перевіряємо передана змінна через рядок підключення, якщо передана (тобто не порожня) - проганяє її значення через $ db-> safesql - це убезпечить нас від "неправильних" логінів користувачів, тому що значення змінної буде вставлено в запит до БД.
Змінну $ catId фільтрувати не потрібно, тому що вона крім як цифрою Ніяк не задається і нерозумно писати щось інше в рядку підключення. Однак повинно бути якесь дефолтний значення, тому перевірка потрібна і її ми можемо прописати безпосередньо в конфіги модуля:
Зі змінними розібралися, тепер запит в БД.
У нашому випадки необхідно всього одне значення з БД і використовувати повноцінний запит, а потім його розбирати - не має сенсу, тому ми будемо використовувати метод super_query, він за замовчуванням повертає одновимірний масив.
Наш підсумковий запит буде таким:
де:
$ MyConfig [ 'catId'] - id ктегоріі.
$ MyConfig [ 'userName'] - ім'я користувача.
нижче пропишемо оцінний код:
Виклик модуля здійснюємо так:
Якщо змінні вказані правильно - результатом налагодження буде масив з даними, що складається з одного елемента count
Тепер можна вивести результат по нормальному:
Тут слід зазначити, що якщо в кеш буде записаний один нулик - dle його не буде "вважати кешем" і створить новий, тому потрібно писати туди щось, відмінне від нуля.
Підсумковий код нашого модуля буде таким:
Всього 20 рядків коду - і отримуємо готове рішення конкретної проблеми.
Код модуля цілком робочий і його можна використовувати в реальному проекті, проте наведено цей код для ознайомлення з принципами правильного написання модулів для DLE.
На цьому можна було б закінчити, але вище я обіцяв показати код модуля з використанням власного шаблону.
Універсальна заготовка для модуля з кешем і власним шаблоном
В цілому той же модуль, що ми написали без шаблону цілком легко перетягнути і на "шаблонний" модуль, однак в нашому випадки це не має сенсу, тому що модуль виводить всього одну цифру. Власний шаблон в модулі краще використовувати коли необхідно вивести кілька значень з різним оформленням в різних місцях сайту.
$ C = new stdClass;
$ C-> INCPATH = dirname (__ FILE __). '/';
chdir ($ C-> INCPATH);