Выбор CMS для ИМ на 500-1000 товаров

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

Это я о нюансах, если что...

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

Господа товарищи, за время ваших прений можно было уже 2 магазина запустить и настроить их.

ТС давно на всех забил и правильно сделал.

Лонг Лив CMS!

Для ТСа вариантов других и нет. Но я для себя решил, что если что-то хоть немного сложнее блога, то я это делаю на самописе. Есть библиотеки, с которыми я привык работать (логирование, роутинг, ABAC, иногда ORM), подключаются 4 командами, шаблонизацию на бекенде вообще не вижу смысла лепить, только байты туда-сюда гонять. Делаю файлик с декларацией OpenAPI, по нему генерирую и клиент, и сервер. На фронте все красиво делается на том же Vue. В итоге сами CRUDы пишутся очень быстро. Бизнес-логику оставляю на уровне entites/use-cases, все через DI интерфейсов, в итоге любой слой можно мокать и тестировать. На выходе получаем код:

• без избыточности, весь код работает, нет целых классов и модулей, которые висят и никогда не будут вызваны (линтер не даст проекту собраться, если есть структуры, методы/функции или переменные, которые не используются)
• покрытый тестами (включая бизнес-логику)
• очень быстрый (нет вызовов парсинга XML файлов, в которых хранится инфа о модулях, или какое-нибудь дерево шаблонов и и наследований у темы)
• независимость от хранилища данных (из-за абстракций-репозиториев)
• не нужно обновлять (а значит более стабильная работа), как показывает практика, не всегда обновления в админке ставятся так, как хотелось бы. зависимости в рамках мажорной версии обновляются одной строчкой, и API у них как правило стабилизировано.

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

Более того, вот список фич, которые вы практически никогда не сможете реализовать на CMS:

• UUID PK, очень удобно, когда постоянно добавляются/обновляются сущности пачками, особенно со M:M связями. Я могу сгенерировать ID у сущностей без единого запроса к базе, добавить связи к ещё не существующим сущностям. Также, это открывает возможности для масштабирования. Заложив такой функционал ещё в фундаменте, можно решить очень много проблем в будущем.
• роутинг, хорошо, если он из коробки адекватный, но если ты хоть на секундочку задумаешься его сменить, то есть вероятность наткнуться в модулях и JS скриптах на захардкоженые значения (изменить которые ты не сможешь, потому что придеться попрощаться с обновлениями)
• эксепшены, выброшенные модулями, часто ломают работу всего сайта целиком. нет возможности сделать graceful degradation. например, какой-нибудь плагин микроразметки может выбросить эксепшн из-за отсутствия нужного ему класса, но вместо того, чтобы просто не рендерить нужный блок и написать ошибку в логи, мы получаем 500 статус на всю страницу целиком, и сообщение об ошибке. такое регулярно случается в том же Webasyst.
• дикий паравоз зависимостей, когда фронтенд использует кучу модулей jQuery, зависящих от версии, все это грузится в шапке сайта. вынести все в конец body невозможно, потому что в том же head плагины подключают свои JS скрипты, которые зависят от jQuery. Опять же, на примере Webasyst. Как результат, получаем 3 балла по Google PageSpeed, вонь сеошников, и корвалол на столе директора.
• не оптимальный дизайн БД и вытекающие оттуда проблемы. либо разработчики упарываются до 25 нормальной формы, либо делают только им понятный дизайн. На примере того же Webasyst, я кидал им PR где ускорял два запроса, которые работают каждый раз при открытии категории, в 20 раз. PR так и висит (как и все остальные PRы у них чуть больше чем в одну строку кодом). Тут же идет очередной сайд-эффект, в разработке всегда есть свои трейд-оффы, почти все решения хороши в чем-то одном, но абсолютно не приемлимы в другом. Если вам не повезло, и в вашем кейсе какой-то запрос тормозит, чтобы сменить дизайн базы, вам скорее всего придеться править ядро, которое ставит крест на обновлениях
• отсутствие обновлений ставит под угрозу безопасность проекта. даже корявый самопис с дырками вряд ли кто-то взломает, ведь проще купить уязвимость на форуме и пройтись скриптом по CMSкам, получив профит в несколько сотен/тысяч ломаных сайтов, чем ломать один определенный сайт, не имея никакого понятия где у него эндпойнты, куда заливать шелл, и т.д.

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

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

оО Выбор, конечно, огромен.

НО!

Есть системы красивые, но неудобные для юзера, есть системы красивые, но кривые еще в чем-то.

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

Лично я ставлю удобство пользователя на первое место.

Короче можно долго перечислять.

Идеальную систему придется пилить, пилить и допиливать.

Вопрос надо ставить уже намного шире, нежели лет десять назад.

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

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

Поначалу так и было, что то типа prmid|itemid|catid|strval|numval, потом своя таблица на категорию (набор параметров, например для самосвала, автобуса и автомобиля с кму сильно разный, как по кол-ву, так и по типам). Ну а потом, монга, которая решила все проблемы со структурой данных.

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

Вероятно, люди работающие примерно так же существуют.

Кстати могу. В чём проблема-то ?

И будет дешевле, если проект не мусорный и просуществует хотяб лет 3-5.

Нет. Понимаете, читая документацию по c# я получаю нужные полезные знания.

Читая документацию по cms - я получаю информацию о ненужных чужих тараканах, которая устареет за полгода.

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

Повторюсь - я изучил, внедрил, убедился, что результат "никуда не годится" и выкинул.

А результат никуда не годится потому, что создатели коробочных ИМ не в состоянии написать нормальный SRS на свой продукт.

У них все работает так как им надо, а не так, как надо мне :). И настройкам это не может поддаваться.

Невозможно иметь дело с продуктом, при использовании которого в команде разработчиков был хотя-бы один дебил...

Проблема в том, что потратив кучу времени на изучение чужих тараканов всё-равно олучаешь полное говно на выходе.

Если, конечно, хватает квалификации оценить результат. Мне хватает.

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

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

"одежда для бедных". Кто-то готов мириться с тем, что у него вечно член не в той штанине, а кто-то имеет денег на то,

чтобы он всегда был в той, в которой ему удобно, только и всего.

Причем, если спланировать всё хорошо, то применительно к ИМ, "правильные брюки" оказываются еще и дешевле неправильных. В этом парадокс ситуации.

У меня никакой проблемы нет. У меня всё работает. Я крайне прагматичен в выборе инструментов.

Смотрите, что мы имеем:

1. Или мы берем CMS, тратим месяц на изучение и исправление её кода, на выходе имеем очень неоптимальные решения, колоссальные проблемы с обновлениями, кучу геммороя везде где только можно. И иллюзию, что это переделанное везде где только можно (а иначе увы никак) говнище будет кому-то как-бы проще сопровождать.

В результате вы остаетесь с знаниями о том, как сов на глобус натягивать. Т.е. с абсолютно ненужным скилом.

Ну и кода у вас будет вызываться сотни мегабайт для генерации одной страницы. Когда понадобится наконец разобраться в чём-то - это будет особенно увлекательно.

2. Или мы не берем CMS, тратим 2 недели(вдвое меньше!), получаем на выходе ровно то, что нужно. Изменять результат, безусловно будет труднее, чем тыкать в админке кнопки, зато он предсказуем, может быть покрыт тестами итд итп.

При объеме кода в десятки-сотни килобайт не вижу проблем при сопровождении хоть с нуля переписать если не нравится.

Вы правда предлагаете мне просрать х2 времени, чтобы потом просрать его еще неизвестно сколько.

Ради чего ?

Там кто-то рассказывал о каких-то проблемах со смарти.

Я более 20 лет назад имел свой аналог смарти. Упрощенный, но обычно никто сложных вещей из смарти и не использует.

Сделать такой задача для джуниона на неделю максимум.

А имея доку на сматри и того меньше....

На любом языке.

Я понял в чём "ваша" проблема :)

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

Но с того момента, как понимаешь, что "нет", ну вот "нет", ну никак так не получается, что они комптетентнее.

Вот тут, смысла пользоваться тем что они понаписали уже нет.

К сожалению, ныне коробочные CMS и ИМ разрабатывают джуны. Их код часто вообще никак не проверяется.

Либо, в команде нет неджунов вообще. Иначе объяснить то, что я вижу, мне не под силу.

Комментарии требуются?

---------- Добавлено 19.02.2020 в 18:50 ----------

А теперь пациент заявляет, что самопис быстрее и дешевле, хотя изначально признавал обратное.

От тебя не особо.

Правильно, тебе к психиатру.

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

Остальной бред комментировать не буду.