Основные недоставки популярных CMS

Question

[Сергей Протько]

Собственно многие из нас работали с популярными CMS (особенно это касается движков интернет-магазинов). Какие минусы и неудобства (которые доставляли больше всего головной боли) вам доводилось встречать? Речь идет именно о разработке под эти движки а не интерфейс пользователя и прочее. Только нутро.

Answer 1

[bubuq]

Основной недостаток всех популярных CMS в том, что они написаны на PHP.

Comments

[impass]

предлагаете таки на ассебмлере?

[bubuq]

Предлагаю пёрл, питон, руби.

[Crash]

да ну?

[Сергей Протько]

Олег Серебряков: по что труп тревожите?

[Crash]

Сергей Протько: не обратил внимание на дату

Answer 2

[Артур Кох]

1C-Битрикс — синоним головной боли, ибо написание собственных компонентов не пожелаешь даже врагу. Боль чуточку облегчается после огромной практики, но не проходит.

Comments

[Евгений Безымянников]

Боль с головы переходит в другие места.

Answer 3

[un1t]

Минусы везде одинаковые — говнокод, дерьмовое API, огромные требования к ресурсам, скудная документация, сложности с деплоем и синхронизацией.

Answer 4

[Horse]

Безопасность:
популярное любят ломать и выкладывать рецепты в сети. К тому-же ломать легче т.к. есть исходники

Вес: подобные CMS любят предусматривать ВСЕ, в итоге набор функций, класов выростает до весьма внушительных значений. Оно же и приводит к толстому ООП, MVC и разобратся в таком коде будет весьма не легко…

Скорость: CMS не знает для чего она будет использоватся, однако, обязана быть масштабируемой (в плане функционала). В итоге появляется модульность, простые АПИ, общие структуры данных, что почти полностью срезает всякие возможности для оптимизаций.

Стабильность: вышеописанные проблемы часто приводят к 'хакам' движка, которые в свою очередь делают движок нестабильным.

Comments

[Сергей Протько]

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

А вот вопрос о «толстом ООП» и MVC меня немного смутил… Нелегко разобраться в конкретной реализации или в целом? Как-то паттер MVC призван все же более упростить разработку. Да и для меня разобраться с хорошо написанными приложениями было намного легче. Можете пояснить?

[Horse]

Я говорил относительно. CMS всегда больше (больше класов, файлов, строк кода), чем аналогичная не CMS. Таким образом намного сложнее найти тот кусочек кода который отвечает за, допустим, content-generator: joomla. Для того чтобы внести более менее серйозные изменения нужно разобратся с движком, а для этого нужно хотябы прочитать исходники, а их много…

Answer 5

[holyorb2]

Drupal + Ubercart
Недостаток всего 1 — нужен толковый программист :)
При наличии оного, недостатоков нет. Можно сделать все что угодно и как угодно

Comments

[Сергей Протько]

Собственно вопрос состоял в том, что думают программисты при работе с такими «монстрами» — что бы они хотели видеть, какую структуру и какие плюшки облегчающие жизнь. Пока я видел лишь пару вариантов идеальных для разработки но они жрут много ресурсов (чем-то приходится жерствовать). Конечно спасает кеширование, но иногда бесит отсутствие золотой середины между удобством и производительностью. Как вариант написать что-то типа «предкомпиляции» узких мест — когда то что пишется на уровне API системы склеивается и упрощается для уменьшения количества абстракций.

Answer 6

[ulitin]

Пару слов по повода WA Shop-Script`a
Из минусов это местами идиотский код, даже незнаю как это называется когда пхп4 всовывают в класс и типо считают рефракторинг оконченным. Второй момент это огромное количество файлов, но если понять структуру то работать с ними довольно таки понятно. Третье это то что шаблонов очень много, в качестве шаблонизатора используется смарти, но все что касается вывода находится в них, в пхп кода практически нет кроме пагинации и сообщений об ошибках. Качество фронтэнда плохое, для управления селекторами используется библиотека кажется 2005 года.
Собственно плюс один если постоянно использовать эту систему для разработки то если руки правильные все косяки связанные с шаблонами исправляются и от шопскрипта остается только админка, которая кстати говоря довольно удобная.
По ресурсам система особенно не прожорлива, на нормальном виртуальном хостинге все стабильно работает ~ 500 уникальных в день.
С осторожностью стоит отнестись к связке с 1с из коробки, картинки из 1с не заливает, дополнительные опции товара размер, цвет превращает в несколько товаров.
В общем продукт довольно странный, и начинать с ним работать довольно сложно, потом привыкаешь ))

Comments

[antonrr]

Присоединюсь к высказанному мнению об идиотском коде WA SC. Некоторые вещи реализованы в виде одного и тоже кода, раскиданного в разных местах движка.

Answer 7

[Derailed]

Joomla всем нравится, но вот только никак переползти не могу на версию 1.5.

Comments

[Сергей Протько]

Кому всем? С точки зрения кода — ужас. С точки зрения интерфейса — ну… может попроще Drupal но тоже жуть…

[Shvonder]

Может имелось ввиду всеми своими возможностями?

[ZloiZmei]

Возможности хорошие, но для разработчика разбираться в коде сложновато. Видимо потому и переползти не можете, сторонних компонентов наверно хватает. И уже вышла версия 1.6, если соберетесь — переползайте сразу на неё

[Derailed]

Сайт у меня уже довольно большой, и вручную переносить контент на новую версию как-то совсем не радует. А как это сделать автоматически — не разобрался.

Answer 8

[ZloiZmei]

Любая популярная CMS — это кухонный комбайн.
В ней разобраться сложнее чем в миксере, блендере и специализированных скриптах.
Сколько не обрезай — всегда остаются неиспользованные функции, и скорость\удобство работы и разработки соответствующая.
В отличие от самодельной, нужно быть готовым к тому, что будут проблемы со совместимостью компонентов и модулей при обновлении.

Что касается магазинов. Если делать под себя или постоянно работать над проектом — то можно брать любой движок и доводить до ума. Только все записывать, что бы повторить при выходе следующей версии движка… Для разовых клиентов лучше брать платные движки, где все востребованное уже сделано и на нормальном уровне.