Пишемо свій модуль для DLE - докладна інструкція - ПафНутій-Блог
У цій статті я постараюсь докладно розібрати процес створення простого модуля для DLE з кешуванням та власними шаблонами. Спочатку розберемо модуль без шаблону, а потім доповнимо його власним шаблоном. Підсумком статті буде працездатний модуль без адмінки, який викликається у будь-якому місці сайту через рядок підключення.
Вступ
З чого почати?
Чому не варто використовувати DLE_API
Використання dle_api значно збільшує витрати оперативної пам'яті, що зовсім, зовсім не добре. Методи, описані в dle_api розходяться з оригінальним функціоналом.Загальна порада: якщо вам потрібна яка то метод або функція з dle_api - просто скопіюйте її в свій модуль. Можливо моїх скромних напрацювань вистачить на набір методів та функцій, які можна буде використовувати надалі, але це тема для окремої статті.
Перш ніж писати будь-який модуль (крім файлів, що відповідають за ajax), потрібно в обов'язковому порядку, на самому початку прописати один рядок:
Це не дозволить користувачеві звернутися до файлу модуля безпосередньо, а значить він не зможе передати власні параметри модуль і зламати сайт через цей модуль. Думаю важливість цього моменту важко переоцінити, але я дуже часто натикаюся на відсутність подібної конструкції в коді модуля.
Конфігурація та кешування
Я вирішив зупинитися у цьому моменті докладно, т.к. це одне із найчастіших питань, які задаються, якщо людина вирішила написати свій модуль.
Конфігурацію модуля найкраще записувати в масив- це дасть можливість безпроблемного створення кеша для кожного виклику модуля з різним набором конфігурації, у нашому випадкудля кожного користувача. Поясню чому. Допустимо ми написали модуль, він кешується, і рядок створення кеша виглядає так:
де: -$var1.$var2.$var3.$var4- змінні модуля. -$myModule- текст, який повинен записатися в кеш.
а рядок створення кешу буде такий:
Таким чином нам взагалі не доведеться лазити в цей код ніколи, все відбуватиметься автоматично.
Використовуйте префікси та суфікси кеша- це дозволить гарантувати автоматичне очищення кеша, а так само дозволить (за потреби) створювати окремі кеші для різних груп користувачів. Для наочності поясню погляньте на картинку:
Текст кеша- це результат роботи модуля, який буде записаний в кеш, тут все просто. вище і змінну $config['skin'] - це для того, щоб мати різні кеші для різних шаблонів сайту. для кожної групи користувачів буде створюватись свій кеш-файл, це буває потрібно, якщо різним групам користувачів потрібно показувати різний контент.
Універсальна заготовка для модуля з кешем, без шаблону
Враховуючи все вище написане, ми можемо створити просту заготівлю для модуля, який використовуватиме кеш, але не використовуватиме шаблон.Усього 15 рядків коду!
Все досить просто, правда?
Запит у БД та перевірки.
Невеликий відступ: Я раджу використовувати одноманітний тип змінних модуля та змінних конфіга модуля, тобто.
виглядає набагато більш читабельним, ніж
Однак використання нижньоїриси не практикую в dle, т.к. Через це спрацював фільтр в dle і модуль не відпрацював, хоча можливо це лише одиничний випадок.
Найпростіша перевірка - умова if else:
тобто. ми просто перевіряємо чи передано змінну через рядок підключення, якщо передано (тобто не порожнє) - проганяємо її значення через$db->safesql- це убезпечить нас від "неправильних" логінів користувачів, т.е. до. значення змінної буде вставлено запит до БД. Змінну $catId фільтрувати не потрібно, т.к. вона як цифрою не задається і безглуздо писати щось інше в рядку підключення. Однак має бути якесь дефолтне значення, тому перевірка потрібна і ми можемо її прописати безпосередньо в конфізі модуля:
Зі змінними розібралися, тепер запит у БД.У нашому випадку необхідно всього одне значення з БД і використовувати повноцінний запит, а потім його розбирати - не має сенсу, тому ми будемо використовувати методsuper_query, він за умовчанням повертає одновимірний масив. Наш підсумковий запит буде таким:
Виклик модуля здійснюємо так:
Якщо змінні вказані правильно - результатом налагодження буде масив даних, що складається з одного елементаcount
Тепер можна вивести результат за нормальним:
Підсумковий код нашого модуля буде таким:
Усього 20 рядків коду - і отримуємо готове вирішення конкретної проблеми.
На цьому можна було б закінчити, але я обіцяв показати код модуля з використанням власного шаблону.
Універсальна заготовка для модуля з кешем та власним шаблоном
Осьтепер мабуть можна закінчити статтю! Якщо буде час, ідея і бажання - я постараюся написати про створення більш складного модуля. А поки що чекаю на ваші запитання та думки.