Совсем недавно, я стал разработчиком модулей для CS Cart. Случилось это по воле случая: меня взяли на работу в Петербургскую сеть интернет магазинов, торгующих вейпами и всякими интересными штуками для удовлетворения потребностей физического характера страждущих пар и одиночек (кто не понял - еще не дорос ). Оба интернет магазина развернуты на двух витринах с разными доменами, но одной админкой и общей базой данных. Что же с ней не так? Думаю о CMS написано много, но я добавлю свою ложку дегтя в бочку с дегтем .

Путешествие в модуль через лес директорий

В процессе разработки первого модуля для этой платформы, я столкнулся со множеством проблем, которых, как я полагал, имея опыт работы с ООП, а также с CMS MODX Revo, быть не должно. Первое, что бросилось в глаза - это очень сложная и запутанная структура модуля:

root/ app/   addons/                                     <- Модули и расширения     [id_модуля]/                              <- Папка модуля        controllers/                          <- Расширение контроллеров          backend/                           <- Панель администратора            [ваш_контроллер].php            <- Новый контроллер            [контроллер].pre.php            <- Расширение перед контроллером            [контроллер].post.php           <- Расширение после контроллером          common/                            <- Общие контроллеры            [ваш_контроллер].php            [контроллер].pre.php            [контроллер].post.php          frontend/                          <- Контроллеры витрины             [ваш_контроллер].php             [контроллер].pre.php             [контроллер].post.php        database/                             <- MySQL файлы        schemas/                              <- Расширение PHP схем          [папка_схем]/                      <- Папка схемы (тип схемы)             [название_схемы].post.php       <- Расширение после схемы        Tygh/                                 <- Классы          Shippings/                         <- Доставки            Services/                       <- Службы доставки               [СлужбаДоставки].php         <- Ваша служба доставки          [ВашКласс].php                     <- Любой новый класс        addon.xml                             <- Главный файл модуля        config.php                            <- Константы        func.php                              <- Функции и расширения хуков        init.php                              <- Подключение хуков design/   backend/                                    <- Шаблоны панели администратора    css/                                      <- Стили панели администратора     addons/       [id_модуля]/                          <- Ваш модуль         styles.css                          <- Ваши стили         styles.less    mail/                                     <- Email и шаблоны счетов     templates/       addons/                               <- Модули и аддоны         [id_модуля]/                        <- Папка модуля           hooks/                            <- Подключение к хукам            [тип_хука]/                     <- Папка хука              [название_хука].pre.tpl       <- Код перед хуком              [название_хука].post.tpl      <- Код после хука              [название_хука].override.tpl  <- Переписать хук           [шаблон_письма]_subj.tpl/           [шаблон_письма].tpl/    media/                                    <- Статические данные     images/       addons/         [id_модуля]/                        <- Изображения вашего модуля           изображение_1.jpg/           изображение_2.png/    templates/                                <- Шаблоны      addons/        [id_модуля]/          hooks/                              <- Подключение к хукам           index/                            <- Папка хука            scripts.post.tpl                <- Хук подключения вашего скрипта            styles.post.tpl                 <- Хук подключения вашего стиля           [тип_хука]/             [название_хука].pre.tpl         <- Ваш код перед хуком             [название_хука].post.tpl        <- Ваш код после хука             [название_хука].override.tpl    <- Ваш код перепишет хук          views/                              <- Собственная страница           [ваш_контроллер]/                 <- Контроллер             [режим_контроллера].tpl         <- Режим (mode) контроллера          overrides/                          <- Переписать любой шаблон            ...                               <- Создайте нужную структуру     themes/                                     <- Дизайн витрины  темы     [название_темы]/                          <- Название темы       css/                                    <- Стили        addons/          [id_модуля]/            styles.css                        <- Ваш стиль CSS            styles.less                       <- Ваш стиль LESS       mail/                                   <- Шаблоны писем и счетов        templates/          addons/            [id_модуля]/              hooks/                          <- Раширение через хуки               [тип_хука]/                 [название_хука].pre.tpl                 [название_хука].post.tpl                 [название_хука].override.tpl              [шаблон_письма]_subj.tpl/       <- Шаблон темы письма              [шаблон_письма].tpl/            <- Шаблон письма       media/                                  <- Статические данные        images/          addons/                             <- Изображения модуля            [id_модуля]/              изображение_1.jpg/              изображение_2.png/       templates/                              <- Шаблоны         addons/           [id_модуля]/                        <- Ваш модуль             hooks/                            <- Расширение хуков              index/                          <- Папка хука               scripts.post.tpl              <- Хук подключения вашего скрипта               styles.post.tpl               <- Хук подключения вашего стиля              [тип_хука]/                     <- Папка хука                [название_хука].pre.tpl       <- Ваш код перед хуком                [название_хука].post.tpl      <- Ваш код после хука                [название_хука].override.tpl  <- Перезаписать хук целиком             views/                            <- Новая страница              [ваш_контроллер]/               <- Папка вашего контроллера                [режим_контроллера].tpl       <- Шаблон для режима контроллера             overrides/                        <- Переписать любой шаблон темы               ...                             <- Файл который нужно переписать js/                                            <- Скрипты модуля  addons/    [id_модуля]/      func.js/ var/                                           <- Хранилище шаблонов модуля   themes_repository/                           <- Используется при установке     [название_темы]/       ...

Может показаться, что модуль имеет логичную иерархию внутри своей структуры, но, иногда, следуя по документации, случаются баги, которые не должны были появиться. Например: был у меня кейс, когда обращаясь к контроллеру через AJAX функцию, встроенную в класс CMS JS упорно не хотела работать с моим контроллером, хотя сделано всё было четко по документации. Поискав информацию и обратившись к комьюнити, состоящем, в основном из 3-4 активных завсегдатаев-разработчиков, я понял, что даже сами разработчики этой платформы не могут ответить на вопрос о том, почему их функция ведет себя некорректно.

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

То что мертво - труп, но потыкать палкой нужно

Второй задачей, которую поставило руководство, являлась оптимизация сайтов этого магазина. Я взялся за нее без энтузиазма, понимая, что это мертворожденное существо, и мы с коллегой путем мучений и отключения всего того зоопарка модулей, что были установлены до моего появления со словами: "А че бы нет?!" - добились улучшенных показателей Google и в LightHouse, но прироста, в 20 единиц на одном сайте и 10 на другом, было не достаточно. Тогда я полез смотреть БД более детально. Поняв, что БД у данной CMS - набор несвязанных друг с другом таблиц, я понял, что все взаимодействия с базой и связки данных проходят через PHP, что, как я считаю, неправильно. Почему сделано именно так? - всё просто: CMS создавалась в 2003-2004 годах, и в качестве движка для СУБД использовался MyISAM.

MyISAM - сам по себе, довольно медленный движок и он не рассчитан на 50 000 (!) товаров (о количестве поговорим позже). Более того связывание таблиц этом движке реализовано не так хорошо как, скажем, в том же InnoDB. Из-за этого сервер начинает очень страдать при одновременном обращении 500 - 1000 пользователей.

Теперь поговорим о количестве товаров. Откуда 50 000 спросите вы? "Потому что" - отвечу я. Дело в том, что одну из витрин отдали на SEO какому то подозрительному фрилансеру из Беларуси. Странность его суждений заключается в разнообразных уловках и ухищрениях. Например: для улучшения видимости сайта он просил коллегу создать несуществующую номенклатуру и каждый день подгружать несуществующий товар. Аргументировал он это тем, что пользователи будут искать товары из этого несуществующего списка и попадать к нам на сайт, на этот товар. Понятно, что пользователь уйдет сразу же после этого, так как товара в наличии нет и никогда не было и не будет. Сайт ни капельки не продвигается, а руководство с упорством продолжает считать мнение данного "спеца" авторитетней мнения штатного программиста и контент-менеджера.

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

Нужна скрепка? Плати 100 баксов

Последняя проблема, которую я освещу в данной статье - это плата за любое мелкое допиливание этого "зомби". Хочешь стандартный функционал cron в панеле админа - плати. Подключить метрику не через утиную гуску, а так, чтобы она не нагружала клиент - плати. И другие малозначимые, но иногда важные изменения - стоят денег. Ценник, как правило, начинается от 100$ за модуль. Да, разработчикам, как и мне, хочется кушац, но у меня сложилось впечатление, что CMS и её стандартные модули специально не доведены до нормального состояния. А так как структуру всех классов и методов знают только создатели данной CMS, то они и являются, по сути, монополистами на рынке, так как любой фрилансер или штатный проггер, не сможет нормально сделать модуль с первого раза, используя недописанную и костыльную документацию, что предлагается на данный момент.

Заключение

Я не верю, что ситуация с данной CMS когда нибудь изменится и мне, действительно, жаль тех, кто имея огромную номенклатурную базу сидит на ней и платит за все доделки баснословные деньги. Но хочется верить, что, хотя бы в моем магазине, я сумею побороть некоторые её недостатки.

Надеюсь, статья Вам была интересна. Я буду писать еще о своих изысканиях в этой CMS или о разработке модулей для неё.