DLE - некоторые нюансы при создании своих модулей (для начинающих)

Категория: Код

– Автор: Игорь (Администратор)

DLE или DataLife Engine это изначально статейная CMS, рассчитанная на предоставление своим пользователям быстрого и оптимизированного под SEO движка. И действительно, сам движок очень шустрый, но не потому, что он жутко оптимизированный, а лишь потому, что многие вещи, которые присущи другим движкам в нем просто отсутствуют. Например, самое банальное - установка большинства модулей потребует от вас запуска phpMyAdmin и ручной правки статей. Об этом вы, вероятно, уже и сами знаете, прочитав хотя бы пару материалов в интернете.

Примечание: Будет не верно считать, что DLE это плохая система или нечто подобное. Просто эта CMS не является универсальным и, как следствие, тяжеловесным движком. Кроме того, помните про скорость и SEO.

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

1. Два вида DLE - под UTF-8 и под Win-1251 (cp1251)

Самое первое, что удивит многих авторов модулей это то, что DLE предоставляется в двух вариантах - с кодировкой под UTF-8 и кодировкой Win-1251. Такой нюанс можно назвать исключительным явлением. С одной стороны, это облегчает заботу тем, кто использует WAMP для хостинга своих сайтов на Windows. С другой стороны, порождает ряд проблем с php.

Примечание: Обычно, движки заточены под UTF-8 и база с кодировкой utf8_general_ci, поэтому многие даже не сталкиваются с такими проблемами.

Например, есть функция htmlspecialchars, которая в php 5.3 абсолютно нормально формирует результат (будь то utf-8 или cp1251). Однако, в php 5.4 появилось существенное отличие - по умолчанию используется только utf-8, в остальных случаях необходимо явно указывать кодировку. Так, что если у вас DLE под Win-1251, то код должен выглядеть так:

<?php
// PHP 5.3 - нормально (в 5.4 вернет пустую строку)
htmlspecialchars($str, ФЛАГ);
// Для PHP 5.4 и выше
htmlspecialchars($str, ФЛАГ, 'cp1251');
?>

Поэтому, при создании модулей стоит отдельно уделять внимание кодировке (например, явно ее указывать, даже если на текущей версии php все запускается).

2. Упрощенная структура БД в DLE

Если открыть БД DLE, то можно заметить, что структура ее достаточно проста. Многие вещи просто раскиданы по таблицам. Однако, есть некоторые моменты, которые не сразу бросаются в глаза, но являются достаточно важными. Например, есть такое понятие в теории реляционных баз данных как отношение "многие ко многим". Для тех, кто не знает, это когда две сущности базы данных (обычно таблицы) связываются между собой промежуточной таблицей таким образом, что каждая запись одной таблицы может ссылаться на множество записей другой таблицы (и наоборот).

Самым частым примером такого отношения в БД являются "категории" и "отдельные сущности" (например, статьи, товары и прочее). Таким образом, если, к примеру, статья может входить в несколько категорий, то в базе данных обычно присутствует промежуточная таблица.

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

Однако, у DLE это не так. Статьи могут входить в разные категории, но при этом промежуточной таблицы нет. Вся информация о том, к каким категориям принадлежит статья, записывается в записи самой статьи в отдельном поле в виде перечисления идентификаторов категорий через запятую ("2,4,12...").

Примечание: Кстати, такой подход организации взаимосвязей сущностей говорит о том, что сама БД не является оптимальной и при достаточно больших объемах могут возникать проблемы с производительностью. Тем не менее, в интернете прекрасно существуют сайты с DLE, у которых порядка 10000-20000 статей.

Соответственно, если вы собираетесь писать модуль под DLE, то стоит проверять каким образом хранятся данные в БД, так как техническая реализация может отличаться от привычной.

3. Необходимость ручной правки php файлов ядра DLE

Если вы прочитали хотя бы одну статью на тему как создать свой первый модуль под DLE, то, наверное, заметили что все правки вносятся вручную в коде ядровых файлов. В принципе, в самом этом факте ничего страшного нет. Например, тот же OpenCart построен на этом принципе (хотя в плане модулей там лучше с точки зрения их развертывания).

Проблема в данном случае заключается в другом - возникающие конфликты при установке разных модулей. Простой пример. Допустим, вы устанавливаете два модуля - один вставляет модное по последним временам "содержание статьи с заголовками", а второй заменяет фразы внутри статьи на ссылки (автоматическая перелинковка).

С одной стороны, чисто по функциональному назначению эти два модуля никоим образом не мешают друг другу, в каком бы порядке они не были запущены. С другой стороны, оба этих модуля требуют правки "engine\modules\show.full.php", а именно строчки:

$tpl->set( '{full-story}', $row['full_story'] );

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

Конечно, вполне возможно, что модули могут просто корректировать само значение $row['full_story']. Однако, это так же может быть не совсем корректно. К примеру, в таком случае если дополнительно установить модуль "скрывать/раскрывать полный текст" (аля "show more"), то этот модуль может некорректно выполняться, так как, по сути, громоздкое содержание со ссылками не является текстом.

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

Как видите, у DLE есть ряд своих особенностей, которые стоит учитывать при создании своих модулей.

• PrestaShop 1.6 - памятка для авторов модулей (для новичков)
• PrestaShop 1.6 - локализация собственных модулей (для новичков)