Какую cms выбрать для очень простого интернет магазина?

Question

[Андрей Решетов]

Есть готовая верстка интернет магазина. Дело в том что на нем не нужна корзина, процесс покупки и тд. Если только лента новостей, товары и страницы товаров, фильтры и форма предложения из функционала. Когда человек хочет купить товар он заполняет форму на странице товара и она должна отправиться на почту владельцу. Какую cms выбрать для такого функционала? Чтоб у нее меньше всего ненужного было. И можно было быстро интегрировать верстку без особых запар.

Comments

[PozitivVtl]

1) Wordpress + woocommerc
2) Opencart + модуль заказа в один клик + симпла
Если планирете много статей и мало товаров, то первый вариант. Если много товаров и мало статей то второй.

[Grenuy]

PozitivVtl, вордпресс с магазин, плохой вариант....
Не нужно, пожалуйста )

Answer 1

[Сергей Горностаев]

Вообще не использовать CMS.

Comments

[Сергей Горностаев]

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

[tden4ik]

Сергей Горностаев, много факторов влияет на разработку магазина. Если человек не программист? Ищет простое и удобное решение, да еще и в бюджете ограничен. Очень спорно.

[Сергей Горностаев]

tden4ik, если человек не программист, то CMS ему ничем не поможет.

[Grenuy]

Алексей, и через год поймет что проект не пошел и откроет уже второй, или заработает что бы делать версию 2.0 и себе ещё в карман положит )

[tden4ik]

Сергей Горностаев, не обязательно быть программистом чтобы сделать хороший магазин на cms.

Answer 2

[Sanes]

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

Comments

[Андрей Решетов]

ну товары там все-таки имеются и их в районе сотни, поэтому и нужны фильтры

[Sanes]

Андрей Решетов, modx как раз отлично подходит. И с версткой там просто и каталог с галереей нормальные и формы любые можно сделать.
Дополнение поиска и фильтрации платное. Либо как-то сами каталогизируйте эти 100 товаров. Не так много, чтобы без фильтров никуда.

[Sanes]

Андрей Решетов,
пример с одним товаром правда https://sanes.cf/

[Андрей Решетов]

Sanes, понял, думаю остановлюсь на этой cms) Спасибо

[Павел Ловцевич]

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

[Sanes]

Zigzag, хватит пургу нести. Для таких мелких сайтов он отлично подходит. Там работы на 3 дня, чтобы всё это хозяйство завести.

[Павел Ловцевич]

Sanes, соблюдайте корректность в общении для начала. На WP+WooCommerce можно и за пару часов завести и что? Только эту связку я не рекомендую, ибо решето дырявое и тормозное. Как и MODX+miniShop, ибо это стагнация и бесперспективняк, если целиться хотя бы на пару лет развития проекта без смены движка.

Answer 3

[Antonio Solo]

приложите немного усилий и изучите django.

Answer 4

[Павел Ловцевич]

Под ваши требования подходит платформа Shopaholic. Это экосистема плагинов для October CMS. Из коробки она как-раз не имеет корзины, а является просто продвинутым каталогом. Есть неофициальный плагин My clients который как-раз реализует функциональность оставления заявки на покупку. Верстка прикручивается любая, нет никаких требований к разметке, как в случае с WP, OpenCart, Magento и пр.

В целом связка October + Shopaholic это полная противоположность всему, что вы знаете. В основном CMS это комбайны, на которые сверху ещё "докручиваются" фичи. В October из коробки даже нет системы пользователей, управления навигацией и т.п. Все это вы ставите при необходимости отдельными плагинами. Потому у вас не будет перегруженной админки, как минимум. Философия платформы хорошо ложится на философию Unix, которая в упрощенном виде звучит, как "Делайте что-то одно, но делайте это хорошо". Ну а Shopaholic продолжает эти идеи, как я уже упоминал выше, он модульный до такой степени, что даже корзина ставится отдельным плагином, если необходима такая функциональность.

Answer 5

[Владимир Коротенко]

DLE вроде все есть что вам нужно

Answer 6

[Lord_Dantes]

Как по мне Wordpress справится, но не советую.

Comments

[tden4ik]

Вы правы, лучше будет joomla + joomshopping

[Grenuy]

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

[Lord_Dantes]

Grenuy, по-фактам если нормально все сделать магазин на вордпрессе отличный. Но нормальная работа такого магазина будет стоит свыше 1000$ как по мне и месяц работы минимум.

Answer 7

[lukoie]

CMS GetSimple
без базы данных потому что
и get-simple.info/extend/plugin/itemmanager/936 для товаров

Comments

[Grenuy]

Если клиент захочет поменять команду разработчиков будет настоящий гиморой искать новых разработчиков (.
Фактично это "скажание на иглу".
Любой функционал который прямо не предусматриваеться сразу достаточно дорого в разработки, та как самопис.
Любой хитрый вывод чего либо будет невозможен, так как нет базы данных.
Любые массовые изменение (к примеру ЧПУ или тайтлы или кейвордсы, без базы данных, подозреваю так же сложная задача ....
Но главное это малая комьюнити а соответственно людей работающих на ней. Не нужно рекомендовать. Если себе пишем и на этом умеем не вопрос правильное решение, нечего что то новое учить для одного проекта будет дольше и сложнее , но если выбирать, считаю плохим выбором

[lukoie]

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

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

Любой хитрый вывод чего либо будет невозможен, так как нет базы данных.

В его описании четко указывается что ему нужно. Никаких хитрых выводов. А если таковые и нужны - он вполне может заюзать xml
В его задаче не нужна БД

Любые массовые изменение (к примеру ЧПУ или тайтлы или кейвордсы, без базы данных, подозреваю так же сложная задача ....

странный вывод. нет, они максимально просты.

Но главное это малая комьюнити а соответственно людей работающих на ней.

Там, фактически, обычный пхп. Это в Друпале всё завязано на ядро и модули. Здесь цмс только выводит пхп в роуты. Как раз то, что нужно в ЕГО ЗАДАЧЕ.

Answer 8

[Grenuy]

1.сразу же выберете популярные cms, а не что то мало популярно.
2. Окуратно с платными cms, часто они дают откаты программистам/студиям, поэтому их и выпаривают
3. С выбранных почитайте как они живут с магазином(если не профильный)
4. Обратите внимание на мультиязычность если она нужна иногда вызывает проблемы(даже в 2020)
5. Обратите внимание как потом со всем что нужно движок оптимизируется под СЕО и под недорогой хостинг.

По существу. Есть облочное решение shopify его посмотрите. Крутое дороге (далеко не всегда оправдано) magento, мне нравиться drupal 7/8
Есть ещё несколько cms магазинов которые популярные , разные cms которые редко слышали или у которых модуль магазин не очень интегрирован с cms, а работает как сам по себе рекомендовал бы обходить.
Для старта и проб самопис не рекомендую ввиду того что будет не оправдано дорого + привязка к первичному программисту + может по времени занять

Comments

[lukoie]

ну вот КАК может нравиться дрюпал, Вы мне скажите?

[Grenuy]

lukoie, Вы мне скажите, как может не нравиться друпал, сравнительно с другими cms? Один недостаток это уровень входа программиста выше чем для wp или joomla, но это проблема программиста, а не клиента.

[lukoie]

Grenuy, дрюпал это как раз таки проблема КЛИЕНТА!!!
И очень прискорбно что Вы этого не понимаете.

[Grenuy]

lukoie, и все же можно узнать в чем проблема клиента? Создания магазина в бюджетном ценовом диапазоне, + возможность расширить до серезного функционала без смены ядра. Разоабочики досточно легко меняемые в проекте так как строгость подхода в разработке обеспечивает поддерживаемость. Для клиента админка есть. Без особых танцев с бубемном Гуглспидтест(к примеру) даёт 85-99% для мобилки и 95-100 для десктопа сходу(друпал8). Для посетителей так же все хорошо работает. Где есть недостаток как в магазина это если куча типов продуктов с разными фильтрами, фильтра прейдеться настраивать отдельно. (В некоторых эта проблема отсутствует, в некоторых присутствует, но много других проблем везде присутствует которых с друпалом нет)

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

[lukoie]

Разработчик делает сайт для клиента. Который, в большинстве своем, просто предприниматель. У него могут быть контент-менеджеры, которые, в большинстве случаев "секретарши".
Друпал дает возможность разработчику создавать сайты любой сложности благодаря своей ЦМФ архитектуре. Разработка и поддержка сайта посредством драша, гита и других фич оно делается для разработчика.
В итоге, фактически вся разработка Друпала(а я слежу за ним с версии вроде четвертой еще, и до текущей девятой) ведется для добавления свистелок и трещалок для разработчика. При этом забывают для кого на самом деле создается "система УПРАВЛЕНИЯ контентом"(в роли которой и выступает друпал как только его отдали в продакшн).
Так вот, примерно лет 15 назад делал сайт на Друпале для одного заказчика, сайт одного бумажного журнала. Управлять сайтом сел дядька лет 65. Стоит ли говорить что он по сути ничего не мог адекватно там науправлять?
Три сайта нашей компании сделаны на Друпале. И ВСЕ от них просто в огромном ауте, и давно бы переделали, если бы можно было как то объяснить руководству на кой мы выбросили столько баблища на разработку этого поделия, если можно то же самое сделать в разы проще и дешевле.
Наш отдел друпалистов делал десятки сайтов. В итоге, даже если сейчас есть какая-то проблема, и надо поправить, им самим надо долго искать как же они тогда сделали.
То есть, простейший пример - на сайте написано "наши преимущества". Надо просто исправить опечатку. В итоге, потратив с час, менеджерка плюнула на это, и вызвонила чувака, который когда-то его делал. Он назвал с пять-шесть мест, где оно могло быть, но там не оказалось. Я уж не помню куда они его засунули, но в итоге это было ну офигительно не логично что там вообще что-то может быть, связанное с контентом. Где-то в разделе "конфигурации" на два уровня меню надо было идти, они туда переменными засунули. И сейчас сами плюются от этих сайтов, но переделать не смогут - потому что клиент не будет платить снова за то, что должно было быть сделано адекватно.
Зато чтоб поменять опечатку - приходится связываться с разработчиком!
Интерфейс, логика и эргономика работы - не просто недружелюбны, но и, я бы сказал, уродские.
Мне приходится заниматься поддержкой нескольких сайтов на Друпале(7 и 8), и каждый раз это просто какой-то трэш, по сравнению с нормальными системами УПРАВЛЕНИЯ КОНТЕНТОМ.
Я сторонник того, что программисты должны упрощать жизнь себе и всем вокруг, делать вещи, которые просто работают. Это как есть Эппл -вей, где программа делает всё что нужно простым действием, и с минимумом вмешательства. В отличии от этого, Друпал делает ровно то же, что и большинство ЦМС могут намного проще сделать. В то же время, там где нужно больше, чем ЦМС, Друпал проигрывает нормальным фреймворкам, вроде того же Ларавеля.
Итого, Друпал ни ЦМС нормальной не стал, ни фреймворком адекватным не вырос.
Простейший пример - если мне нужно получить доступ до файлов или базы данных в проекте, возьмем самый банальный Вордпресс - я могу прямо в нем же открывать вкладкой адмайнер, и в нем же файловый менеджер. В Друпале такое по определению не прокатит. Потому что, видите-ли, безопасность. Но я уже админ, сижу в админке, с рычагами и тумблерами, нафига мне-то ограничивать безопасность?
Второй пример, на том же Вордпрессе: если нужен какой то плагин магазина, можно прямо в админке написать "магазин", там же нажать "инсталлировать", и готово. В любом проекте будет так. В Друпале, когда тебе надо поставить какой то модуль, тебе нужно на сайте качать, потом менеджером пакетов самому инсталлировать. И тут Друпал...спросит доступы ФТП... Какого? Что за дичь дичайшая? Ты уже скрипт, имеющий права и доступы, да залей ты файл и распакуй, нет надо же еще в "безопасность" поиграться. То есть, если некий Андрей Решетов хотел бы на своем сайте, который ему сделал Гренуй, просто поставить магазин, он не сможет одним тыком это сделать. А даже если и сможет, ему нужно предварительно знать как это сделать - где искать модули, как среди них вообще что-то адекватное найти, как установить, как его на сайте интегрировать...
При этом,в том же банальном ВП он просто в разделе плагинов напишет "магазин", нажмет инсталлировать, и у него вот уже всё будет. Даже, по моему, в меню само добавится. Потому что оно сделано для пользователя. Программисты уже постарались сделать всё так, чтоб пользователю не пришлось за каждым чихом звать разработчика, или должно учиться как же сделать то или иное действие, которое, если они не будут повторять ежедневно, через месяц уже снова не повторят, потому что эргономикой и логикой там и не пахнет.
Опять же, как фреймворк это убожище снова не годится, потому что делать на нем какие-то серьезные проекты, и отдавать заказчику вот это поделие недоинтерфейса админки - тоже не вариант. Даже самодельная админка на АдминЛТЕ в разы презентабельней друпального интерфейса будет. Потому намного проще самому делать логику работы, чем подстраиваться под то, что дарует Друпал.
Вот в жизни, ни под один проект никогда бы не выбрал Друпал, а я с ним, вообще-то, хорошо знаком(как и с десятком других систем разработки и управления контентом), причем у нас и разработчики есть друпалисты, но как в кошмарном сне я не хотел бы работы с вот этим вот.

[Grenuy]

lukoie ,

То есть, если некий Андрей Решетов хотел бы на своем сайте, который ему сделал Гренуй, просто поставить магазин

Вижу крик души, и переход на личности )) Отвечу, но не буду заострять, вот решил некий Андрей Решетов что то поставить себе на сайт, который ему сделал lukoie на CMS GetSimple, и практично вообще нифига не может сдлеть. Он думает, ладно заплачу обращается lukoie, а он к примеру занят\не хочет\не может\заболел и т.д. Думает ладно пойду найду кого-то и так же не найдет, так как очень не популярная CMS, или найдет за 3 дорого, ну и lukoie в поддержке сможет брать в три дорого, а при попытки сменить возвращаемся снова к тому что не найдет спецов...

Теперь по недовольствиям немного развею.
1. запрос по FTP зависит только от хостинга, и если друпал спрашивать, так же не получится и в WP там поставить. (если php выполняется от имени www-data, а папка создана от ftpUserName)
2. Действительно как и говорил недостаток разработки на Drupal, это уровень входа, и не предполагается что будет создавать сайт секретарь или его апгрейдить, в этом выигрывает тот же WP, и я ничего против WP не имею, но против woocommerce кое че имею )
3. Можно на угодно делать криворуко и сложно, но есть концепции и философии которые дают однотипность разработок, они местами в командах отличаются, но если нормальные уровни разработчиков, то не особо сложно предпринимать сайты от других разрабов.
4. По той же опЯчатки, в каждой CMS можно запхнуть в Ж, что фиг найдешь, разработчики друпала достаточно быстро и просто (если более менее адекватно разрабатывали сайт) обычно находят, в Drupal 7 по классам четко можно понять в какой стркутуре находится(блоки\панельки\вюшки) ну если нет в админке то в шаблонах уже втулил разраб(что не правильно), в Drupal 8 есть mode:dev там вообще в комментариях в исходном тексте страницы будет написано с какого файла генерируется шаблон(безумно удобно для разработки, кастомизации, если где то с ядра тянет, просто копируем, называем нужным именем(так же в комментах указывается варианты) и все, не ищем постояно как нужно именизировать. Так что здесь или не достаточная квалификация Ваших друпалистов, или супер криворукость первичного разработчика.

5. по поводу управления с админки. Покажите мне секретаршу которой нужно в файлах ковыряться? Она посидеть, даже с админки если нужно ковыряться файлах, это плохой подход, а вот "случайно" клацнуть и сделать элементарно синтаксическую ошибку в коде легко. Сдавать сайт, и говорить "вы должны знать что такое HTML и немного CSS это так же не очень подход.
Окей я знаю есть разные конструкторы(плагины) которые +- решают проблемы, вот только потом страницы грузятся по 10 секунд, а добавляем мультиязычности, и вообще начинается аут на других CMS то не совместимые модуля, то распадаться, и самая частая проблема что после обновление стает что то не совместимо.
Сломы сайтов так же самое часто происходят на WP и самое реже на DRUPAL года два назад был прорыв сломов на друпале, один раз глобальные, на WP и joomla регулярно происходит, на WP пофиксили тем что бесконтрольно обновляют, и хорошо пока хорошо, пока что то не ломается и сайт просто не ложится...

Насчет создания сложных сайтов drupal так же прекрасно справляется, но согласен если с типичных задач в проекте остается 5% а остальное все равно писать то нет смысла. Но насчет перфоменса и нагружености и сложных логик спокойно справляется. К пример был промопроект на drupal 7 года так 3 назад, с нагрузкой больше 50к пользователей в день без никаких оптимизация и настраиваемых кэшей, на шаред хосте спокойно жил, и хостинг не ругался.

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

магазин и его под пункты

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

Что может друпал того что не может тот же WP(с под админки)

Создавать thumb image, менять их при желании в любой момент по всему сайту.
Создавать views + открытые сортировки и фильтры.
Создавать типы материалов(с разными уникальными полями)
Создавать типы блоков (с разными уникальными полями)
Инструмент создания вебформ саммая гибкая.
Полную мультиязычность (с 8ки с ядра).(в WP в основном пользуются платным wpml)

на уровне кода (особенно с 8ки) гораздо лучше OOП чем практично в любых, все плагины нормально переплетены между собой и в то же время независимые, а не так как часто бывает каждый живет своей жизнью и иногда переходит дорогу друг другу.

Это так то что в голове сразу.
Что не имеет:
Файлового редактора внутри админки(и честно, слава Богу )
Дружелюбный интерфейс(мениее дружелюбный чем у WP но в не такой уж и страшный как описали выше ) )

p.s. Базу данных в принципе можно открыть, но так же плохая идея в админке это держать, да и в бд лесть в целом. (кстати если вам нужно регулярно лесть в бд и вы разрабатываете что то в CMS плохая тогда cms\или плохо разрабатываете (:
https://www.drupal.org/project/dat
https://www.drupal.org/project/adminer

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

[lukoie]

Базу данных в принципе можно открыть, но так же плохая идея в админке это держать

когда есть проект, который делал тыщу лет назад, и надо что-то быстро поправить, нет смысла разворачивать у себя проект, гиты и вот это вот всё, когда в теории АДМИН в АДМИНКЕ должен бы иметь все нужные инструменты. В т.ч. посмотреть код, файлы и БД.
У меня постоянно так происходит. В то же время у "друпалистов" когда нужно сделать такие задачи, они _по трекеру_ потратят час-два на подготовительные работы, потом будут ковыряться, тогда как я задачу уже давно сделал и забыл. Просто потому что зашел, поправил, и сайт дальше работает. И мне не нужен "правильный друпал вэй" для этого, с гитами и драшами, если я это могу сделать простым движением, без вот этого вот широко известного в узких кругах "правильного" подхода.

https://www.drupal.org/project/adminer

вот теперь посмотрите ЧТО предлагают делать чтобы его установить:

spoiler

Install module
Download Adminer from www.adminer.org/latest.php
Put adminer-x.x.x.php into MODULE_PATH/adminer/
Download required plugins: plugin, frames, version-noverify from www.adminer.org/en/plugins
Put downloaded plugins into MODULE_PATH/adminer/plugins/
Download styles from www.adminer.org/#extras
Put downloaded styles into MODULE_PATH/adminer/styles/

В то же время в том же ВП всё делается как для людей. Ты в плагинах написал что тебе надо БД, нажал на инсталл, и оно всё сделало само, ты только в менюшке уже открываешь свою базу.
Именно об этом я и говорю - в друпале всё делается через одно место - требуется кучу телодвижений сделать чтоб осуществить простейшее действие. Которое программисты должны были для себя же упростить.

[lukoie]

Grenuy,

Но я понимаю у Вас есть негативный опыт работы с Drupal, и позитивный в других системах, у меня есть позитивный опыт с Drupal, мир и прекрасен тем что можно выбирать

то есть, Вы не внимательно читали что я писал? Я ведь говорил что лично мне, как разработчику, совершенно индиферрентно на чем это делать. У друпала есть инструменты чтоб сделать большинство задач.
Проблема наступает тогда, когда: надо сделать простые задачи, и для этого не городить кучу ненужных сущностей. Вроде как ездить в гастроном за батоном на Камазе, или делать скриншоты Фотошопом. Когда нужно сделать нечто простое, Друпал недружелюбен к разработчику.
Но что самое главное - Друпал недружелюбен для заказчика, для контент-менеджера. Он уродлив, если уж на то пошло. Разработчик может себе позволить сделать формы просто как есть,без дизайна, сильно не цсс-ся, потому что "и так же работает, главное ж функционал"(да, есть у меня такие убогие проекты). Тогда как клиенту и посетителям надо чтобы красиво и современно выглядело. Чтобы было интуитивно понятно и удобно.
Но если даже мне неудобно заниматься наполнением, то нетехнарям - и подавно. Потому, по сравнению с "попсовыми" цмс, в друпале меньше ведут наполнение контентом. Потому что оно к себе не располагает.
То есть, возвращаемся к тому же - Друпал это продукт сам в себе, программисты сделали для программистов, и тешатся штуками, которые в ЦМС (ой, простите великодушно - в СМФ) ни разу не первостепенные. Да пофигу заказчику что ты пушишься в гит, через консольку, и что вьюшки отделены от логики. Ему нужно удобство наполнения сайта. Именно для этого ему и делали сайт на системе управления. А по факту нам саппортить сайты на Друпале приходится намного больше чем любое другое, даже самопис. Да, для аутсорса это плюс, потому что деньги. Для здравого смысла же это надругательство. Нужна ЦМС - Вордпресс. Нужно больше - Ларавель. Друпал тут ни туда ни сюда не лезет.

[lukoie]

решил некий Андрей Решетов что то поставить себе на сайт, который ему сделал lukoie на CMS GetSimple, и практично вообще нифига не может сдлеть.

В его случае, который он описал ему нужны страницы - он их сможет редактировать. Любое дополнение делается ванильным пхп, я об этом уже писал. Там нет привязок к ЦМС(типа как в Друпале - где код неработоспособен вне Друпала), которые надо изучать, гуглить, учить, ютьюбить.
Не нужно загружать мозг и ЭВМ избыточным кодом, который ему в жизнь не пригодится. Он же четко описал что ему надо. Зачем городить монстра, на такие простейшие задачи?

[Grenuy]

lukoie, тоесть ему уже нужно знать "всего лишь" "ванильным пхп"... Класс. Ну при таком подходе можно на ЛЮБОЙ cms\framework сделать вставку на "ванильным пхп" без привзяки к ядру.
В друпале при нормальном подходе все редактируется с админки. и в нескольких логичных местах.
Меню в меню
Сквозные вставки блоков, в блоках
Сам контент в содержимом
Категоризация в таксономиях

Чего же более нужно?
более того практично по всему сайту всегда есть быстрые линки для перехода редактирования, на самом материале таб "редактировать" на блоках\меню шестеренка с линками на переход редактирования текущего блока\меню.

За мозг ЭВМ я не беспокоился, если взять магазин на битриксе то этот вообще не прожорливый, и любой шаред хост даже на самых минимальных тарифах без проблем принимает друпал.

[lukoie]

Теперь по недовольствиям немного развею.
1. запрос по FTP зависит только от хостинга, и если друпал спрашивать, так же не получится и в WP там поставить. (если php выполняется от имени www-data, а папка создана от ftpUserName)

Вы не сможете "развеять", т.к. опыта у меня с ним предостаточно, и при этом есть с чем сравнивать.
ситуация с запросом ФТП(при этом клиент не помнит доступы) постоянно возникает с Друпалом. Последний случай был вот недавно - хостинг Диджитал Оушен. При этом с ВП такого не было ни разу. Он просто работает. Потому что когда он ставится, он создает директорию, в которую будет складировать плагины и темпы с теми же доступами, от которых сам стартанул. Потому он не вспомнит как склеротик потом "ой батюшки, я ж забыл, вы не под тем юзером хотите лить файлы". Альо, это не я их пишу, сам Друпал их пишет. И он не озаботился тем, чтоб темпы и модули адекватно создавать.

2. Действительно как и говорил недостаток разработки на Drupal, это уровень входа, и не предполагается что будет создавать сайт секретарь или его апгрейдить

Вы видимо не совсем понимаете что есть разница между тем, кто ДЕЛАЕТ сайт и кто им ПОЛЬЗУЕТСЯ?
Если мне нужен сайт для себя, у меня будет хедлесс цмс. Если я делаю сайт для кого-то - мне параллельно на чем делать - могу на любом. Но я ожидаю удобства рутинной работы, которой в Друпале нет, и что в итоге мне не придется клиенту проводить онбординг. В Вордпрессе он просто сел и поехал. В Друпале же нет эргономики, и клиенту приходится учиться. В итоге он тратит время на то, что можно было продумать так, чтоб ему не надо было тратить время.
Он страшный, как сайт 90х. Он совершенно не продуманный с точки зрения UX.

но против woocommerce кое че имею )

вукоммерс успешно справляется с поставленными задачами. Это опять тот же "сел и поехал". Оно просто работает.

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

Вот это всегда друпалисты приводят как якобы преимущество.
И оно было бы может и так, если бы удобство ПОЛЬЗОВАНИЯ у Друпала было хоть рядом с тем же ВП. А ведь именно для пользователя создавался этот инструмент, а не для разработчика.
Разработчику не нужны десятки функций, которые предоставляет ЦМС. Он всё мог бы делать напрямую в коде и БД. Но ведь он делает используя ЦМС. Потому что в итоге ей должен пользоваться заказчик. Вот где нужно искать преимущества, а не в методологиях и унификациях.

4. По той же опЯчатки, в каждой CMS можно запхнуть в Ж, что фиг найдешь

я оперирую исключительно фактами саппорта сайтов. при использовании ВП подобных запросов просто на порядок меньше. А если и есть, менеджер(проджект, который) может сам поправить, не отвлекая на это разраба. При этом для Друпала такая история не прокатывает.
Любой пхпшник у нас может делать правки по ВП. При этом для Друпала то же не прокатывает. То есть, Друпал превратился не в хелпер, надстройку на пхп, а в самостоятельное изделие, в который "просто пхпшник" уже не сможет с наскоку прийти и сделать правки. Это для меня плохой показатель.
Представте что есть такая марка унитаза, которую не сможет починить любой сантехник, нужна отдельная каста сантехников только по этим унитазам...

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

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

5. по поводу управления с админки. Покажите мне секретаршу которой нужно в файлах ковыряться?

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

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

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

Окей я знаю есть разные конструкторы(плагины) которые +- решают проблемы, вот только потом страницы грузятся по 10 секунд, а добавляем мультиязычности, и вообще начинается аут на других CMS то не совместимые модуля, то распадаться, и самая частая проблема что после обновление стает что то не совместимо.

Такие конструкторы позволяют человеку самому создать одностраничники, накидывая блоки. Мультиязычность вполне нормально работает, также как и кеширование.
Кстати, как раз таки сайт на Друпале у меня выдает счас TTFB 10 секунд, чего на ВП не было никогда, даже с конструкторами. Именно ТТФБ, на секундочку, от конструктора не зависит.

Сломы сайтов так же самое часто происходят на WP и самое реже на DRUPAL года два назад был прорыв сломов на друпале

вот первый же ответ в гугле:
https://medium.com/@briskinfosec/drupal-core-remot...
ВП делают реальные программисты, а не энтузиасты, и множество народу им подсказывает под руку, так что всё адекватно патчится. Миф о дырявости ВП разгоняют по привычке.

WP пофиксили тем что бесконтрольно обновляют, и хорошо пока хорошо, пока что то не ломается и сайт просто не ложится...

он хотя бы обновляться может, даже сам. Друпал и это не в состоянии нормально сделать.
тем более: https://www.drupal.org/about/strategic-initiatives...
вот тут чуваки сами ратуют чтоб сделать автоапдейты в Друпале, и тоже говорят что аптейт может быть сложной задачей. Афигеть помощничек, которому надо еще кучу времени угробить просто чтоб его апдейтнуть. Помню я как отключил просто счетчик посещений на сайте, и сайт упал просто к чертям собачьим.
Оказывается и такое бывает.

Насчет создания сложных сайтов drupal так же прекрасно справляется

Нет. Прекрасно с этим справляется и Голанг и пхп. Можно на чем угодно делать сложные сайты, и обьявлять это прекрасным справлянием. Реальность такова, что сложные сайты надо делать на настоящем фреймворке, а не этом поделии. Потому что в итоге админка и конктрукции контента будут просто катастрофически выглядеть, когда это надо будет отдавать в прод. Оно не позволяет делать нормальную админку, и приходится "лепить из того что было", в итоге все эти вьюхи и формы превращаются в хаос, где на одной странице чтоб управлять данными надо в 3-4 разные локации перемещаться.

но согласен если с типичных задач в проекте остается 5% а остальное все равно писать то нет смысла.
Даже если типичные задачи - их правильней взять для нормального фреймворка. Потому что тут даже если и есть, скажем, медиабиблиотека и аутентификация с ролями, то в итоге ты все равно зависаешь в ограничениях админки и визуальной реализации конструктора вьюшек, с табами и контроллами привет 90ые, которые больше на конструктор похожи, там где это уже не нужно, но оно всё равно есть.

Но насчет перфоменса и нагружености и сложных логик спокойно справляется.

у меня местный городсткой новостной сайт на ДО на одном ядре уже на 250 посетителях нагружает память и проц под завязочку. Оптимизированный и настроенный. Это ужасный показатель.

Что может друпал того что не может тот же WP(с под админки)

Создавать thumb image, менять их при желании в любой момент по всему сайту.

Вы наверное не в курсе, но ВП это может уже очень давно.
Да и менять тоже можно было, мне как то один раз это нужно было, и ВП сделал.

[lukoie]

Создавать views + открытые сортировки и фильтры.

Признак дурного тона - придумать свою заморочку, а потом гордиться что только у тебя она есть. Я уверен что если вдруг мне понадобиться такое сделать в ВП, это можно сделать и без каких-то изобретений своих "представлений с глобализированным выкрутасом", которого ни в одной цмс больше нет.

Создавать типы материалов(с разными уникальными полями)

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

Создавать типы блоков (с разными уникальными полями)

Это делают виджеты с кастомфилдами или подс

Инструмент создания вебформ саммая гибкая.

да неуж то гибче контактформ7? : )
нет, в Друпале оно уродское, если что. У нас на сайте нашей конторы резюмешки собирает такая форма. Хай меня кони покрасят, яке воно дурне : (
Причем после очередного апдейта Друпал решил взбрыкнуть, и теперь все ссылки на резюме, которые приходят в письме эйчарам они уже не могут открыть. При этом разраб, который делал его, уже года два как не с нами. Оно работало. После апдейта - хоба, и не открывает уже. То есть код не трогался, а функционал сдулся. Магия? Не думаю. Криворучие друпальщиков!

Полную мультиязычность (с 8ки с ядра).(в WP в основном пользуются платным wpml)

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

на уровне кода (особенно с 8ки) гораздо лучше OOП чем практично в любых

о да, вот это и "преимущество" для системы УПРАВЛЕНИЯ содержимым. Как я и говорил - продукт в себе, программирование ради программирования.

все плагины нормально переплетены между собой и в то же время независимые

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

а не так как часто бывает каждый живет своей жизнью и иногда переходит дорогу друг другу.

В ВП я такого не встречал. Может потому что из модулей использую адекватное. Впрочем, когда искал что-то нормальное для Друпала из готового, я в той мусорной свалке не смог определить как с наскоку понять что там нормальное а что нет, так что подозреваю что дерьмокода там в модулях тоже хватает.
Кстати да, был как то проект, куда пару модулей влепил, так сайт не смог нормально работать. Собственно, не стал дальше думать почему так.
Кстати, рекомендованный Вами Адмайнер для Друпала естественно даже не завелся.
Я адмайнером пользуюсь всегда в ВП когда мне нужна БД(и у клиента либо под рукой нет доступов, и чтоб не ждать когда он их где-то выудит я просто сам беру и делаю, не тратя время), я просто в том самом файловом менеджере, которого нет у Друпала, подкидываю пхп файл, и вперед. Будучи админом - имею право так делать и иметь возможность так делать.

Что не имеет:
Файлового редактора внутри админки(и честно, слава Богу )

файловый МЕНЕДЖЕР не равно файловому редактору.
Файловый менеджер, среди прочего, дает возможность забрать проект в пару тыков, прямо там заархивировав и скачав пользовательскую директорию. Я проект забираю быстрей чем друпалисты только доступы у клиента нужные выпросят, зайдут в сипанель и сделают себе ссш или фтп пользователя - у меня уже ВП проект развернут на локале.
Правка на сервере тоже очень часто помогает при саппорте. Когда не нужно тратить время на разворачивание проекта только для того чтобы сделать "вот этот вот пункт меню временно сделать невидимым для гостей, пока мы там добавим товары"(как раз сегодня такой таск прилетел). То есть, ради вот этих вот двух строчек. Что я сделал фактически за минуты две, имея только админский доступ в админку.

if ( ! current_user_can( 'manage_options' ) ) {
	echo ("<style>#menu-item-82730 {display:none;}</style>");	}

Дружелюбный интерфейс

Это далеко не так. Интерфейс Друпала нелогичный, с обилием собственной терминологии, что увеличивает время обучения и привыкания, ну сам дизайн - привет из 90х.

[lukoie]

Grenuy,

тоесть ему уже нужно знать "всего лишь" "ванильным пхп"...

ЕМУ- нет.
Точно так же как и уметь натягивать верстку в Друпал(а ведь у него только верстка имеется)!
А вот в ГетСимпл может ЛЮБОЙ пхпшник. Ему не нужно "знать ГетСимпл", потому что там нужен просто пхп.

Класс. Ну при таком подходе можно на ЛЮБОЙ cms\framework сделать вставку на "ванильным пхп" без привзяки к ядру.

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

В друпале при нормальном подходе все редактируется с админки.

в ЛЮБОЙ цмс всё редактируется с админки. То, что нужно редактировать менеджеру контента. Потому что цмс это именно для него инструмент.

За мозг ЭВМ я не беспокоился, если взять магазин на битриксе то этот вообще не прожорливый, и любой шаред хост даже на самых минимальных тарифах без проблем принимает друпал.

А, ну конечно, сравнивать с самым упоротым политиком - то и Пу станет великим гением. ЗАЧЕМ в его задаче тяжеловесная цмс и бд?? Что за выбор архитектуры такой? "я умею дрюпал, значит давайте всё делать на дрюпале"?

[lukoie]

Кстати, надо было поискать возможную уязвимость, и в базе данных эксплойтов обратил внимание на ВП:

и Друпал:

что-то я не вижу особой разницы!
Итого, МИФ о якобы вечной уязвимости ВП и неуязвимости Друпала опровергается простой базой данных эксплойтов.

[Павел Ловцевич]

lukoie, а можно поинтересоваться, что это за скриншоты? Точнее, что за база эксплойтов такая?

[Grenuy]

lukoie,
Ой пропустил ответы, ну что же поотвечаю

Создавать views + открытые сортировки и фильтры.

Признак дурного тона - придумать свою заморочку, а потом гордиться что только у тебя она есть. Я уверен что если вдруг мне понадобиться такое сделать в ВП, это можно сделать и без каких-то изобретений своих "представлений с глобализированным выкрутасом", которого ни в одной цмс больше нет.

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

Создавать типы материалов(с разными уникальными полями)

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

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

создавать типы блоков (с разными уникальными полями)

Это делают виджеты с кастомфилдами или подс

Вот они уже кастофилды появляться, снова таки не говорю что нельзя на WP говорю что WP тут проигрывает насчет удобства быстроты и затрат на создание(денег\времени)

Инструмент создания вебформ саммая гибкая.

да неуж то гибче контактформ7? : )
нет, в Друпале оно уродское, если что. У нас на сайте нашей конторы резюмешки собирает такая форма. Хай меня кони покрасят, яке воно дурне : (
Причем после очередного апдейта Друпал решил взбрыкнуть, и теперь все ссылки на резюме, которые приходят в письме эйчарам они уже не могут открыть. При этом разраб, который делал его, уже года два как не с нами. Оно работало. После апдейта - хоба, и не открывает уже. То есть код не трогался, а функционал сдулся. Магия? Не думаю. Криворучие друпальщиков!

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

Полную мультиязычность (с 8ки с ядра).(в WP в основном пользуются платным wpml)

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

1. Вот в этом и проблема, что 3 разные системы мультиязычности бесплатные, кому то любимый WMLP, есть qtranslate который вообще перестали поддерживать. В этом и проблема...
2. Не пихают всем, есть ряд плагинов которые идут с ядром, и большенство отключенных, и их можно включить(что то мне говорит не знаете вы друпала, как утверждали выше....)

на уровне кода (особенно с 8ки) гораздо лучше OOП чем практично в любых

о да, вот это и "преимущество" для системы УПРАВЛЕНИЯ содержимым. Как я и говорил - продукт в себе, программирование ради программирования.

ООП дает возможность расширятся гармонично и безглючно, а не так что тронишь одно поламается другое. Да оно нужно для более сложных проектов, но на легких не мешает. И если не знаешь ООП это проблема программиста, а не клиента. На внешнем проявлении никак не отображается. Отображается экономией бюджета клиента на сложных проектах. Та что там, сложный проект и WP вообще очень плохая история. Сложный проект и Drupal нужно смотреть и в половину случаях очень даже удачное решение, в другой половине берем какуе-то symfony или laravel

[Grenuy]

lukoie,

все плагины нормально переплетены между собой и в то же время независимые

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

Не грузите то о чем не знаете. Я видел Ваш делетанский запрос здесь про эту проблему. Загрузите любо куда несколько милионов записей проиндексированых, и обновляйте их при каждом заходе, здесь проблема не CMS, а mysql, ну накрайняк плагина, но не CMS. + То что вы не смоги отключить вопрос снова таки вашего понимания и умение. И да есть модули как дополнение к другим модулям. И тогда родительский модуль это обезательно, и так же ПРОДУМАНО что нельзя просто так отключить родительский модуль без того что бы не отключать зависимые от него модуля. иначе получилось бы что? Что отключили одно, а перестало работать другое, водя в заблуждение как пользователя так и программиста. и да есть консольные тулзы которые облегачают работу типа drush или drupal(имено тулза) есть. Так же как и в WP wp-cli(кстати если не знаете берите в вооружение еще по несколько часов а может и с десяток на проекте будете экономить)
Бекапы это всегда нужно.
Кривой плагин это не означает что кривая система, система opensorce и плагины может писать кто угодно и как угодно, как и в WP так и в Drupal, и можно написать очень криво. (не вникал глубоко что в вашем случаи плохо, но в WP могу так же назвать много проблемных подобных моментов, например конструкторы а к ним добавить мультиязычность, залить хотя бы десятка 2 -3 статей собранных визуальным конструктором, все сайт грузится по 5-10 секунд..., но проблема не в WP, а в том что нефиг так делать)

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

Плохо так работать, будучи админом у Вас ДОЛЖНЫ быть доступы к SSH, нормлаьные десктопные тулзы на компе для работы с базой даных, и соеденив эти две вещи спокойно подключатся. Но работая с CMS ЗАЧЕМ так нужна база даных, и подключатся туда? о_О от таких подходов, потом вот столько и проблем....

PHP файлы подкидывать через админку очен плохо, прям очень... Снова таки sftp\ftp должны быть.
Но я понял, вам этого не хватает, и если бы это была одна причина которая останавливает, то попросту можно было бы запилять модуль, подобный модуль думаю занял бы часов 5-10...
Я понял что у вас свое видиние к файловому редактору\менеджеру, с вами не согласен, но каждый имеет право на свое мнение, без проблем :)

Дружелюбный интерфейс

Это далеко не так. Интерфейс Друпала нелогичный, с обилием собственной терминологии, что увеличивает время обучения и привыкания, ну сам дизайн - привет из 90х.

не нужно уж уже передергивать, я написал

Дружелюбный интерфейс(мениее дружелюбный чем у WP но в не такой уж и страшный как описали выше ) )

Насчет привет с 90х, 7ка достаточно старая, 8ка очень даже напоминает тот же WP(может и стырили, но мне все равно, вопрос что бы было хорошо)
Да и куча тем для админки в частности есть если прям не нравится...

тоесть ему уже нужно знать "всего лишь" "ванильным пхп"...

ЕМУ- нет.
Точно так же как и уметь натягивать верстку в Друпал(а ведь у него только верстка имеется)!
А вот в ГетСимпл может ЛЮБОЙ пхпшник. Ему не нужно "знать ГетСимпл", потому что там нужен просто пхп.

Как то странно, друпал так же на PHP написан, как и WP, как и symfony vs laravel.... Так что зная PHP везде разберется )))

В друпале при нормальном подходе все редактируется с админки.

в ЛЮБОЙ цмс всё редактируется с админки. То, что нужно редактировать менеджеру контента. Потому что цмс это именно для него инструмент.

все было хорошо бы, но не зря вы сделали вставку "что нужно редактировать менеджеру контента", и часто программист решая что это не нужно "редактировать менеджеру контента", а в результате оказывается что нужно, и дальше что? дальше платить снова программисту, потому что он решил не так как показала жизнь...
В друпале изначально все редактируется, то что как говорите не "нужно редактировать менеджеру контента" может быть в не очевидном месте для того же менеджера, но подсказав где редактировать менеджер просто берет и дальше редактирует. А в Вашем подходе, нужно лесть в код и править...

За мозг ЭВМ я не беспокоился, если взять магазин на битриксе то этот вообще не прожорливый, и любой шаред хост даже на самых минимальных тарифах без проблем принимает друпал.

А, ну конечно, сравнивать с самым упоротым политиком - то и Пу станет великим гением. ЗАЧЕМ в его задаче тяжеловесная цмс и бд?? Что за выбор архитектуры такой? "я умею дрюпал, значит давайте всё делать на дрюпале"?

Я показал сравнение для того что бы было понимание про прожерливость, насчет
"я умею дрюпал, значит давайте всё делать на дрюпале", очень не правда, я умею и на WP, и на фреймворках, и не только на php, а и на JS. Да и серверную часть знаю достаточно хорошо. А вот с точностью наоборот "я знаю WP все остальное г***" прослеживаю, и очень грустно что такая упоротость и узьколобость.

Кстати, надо было поискать возможную уязвимость, и в базе данных эксплойтов обратил внимание на ВП:

Действительно интересно было бы посмотреть на источник даных, но даже по куску скрина все таки видно что WP прошел 2 раза, друпал почаще проходил,
А если предметно то у меня есть небольшой хостинг(сотни 2-3 сайтов на нем) где из CMSных сайтов где-то 2/3х сайтов на друпале и 1/3 на вордпрессе(грубо коноечно но для понимание), так вот года два назад были сломы и друпалов и вп на уровне, там прям прорвало... Если закрыть глаза на тот небольшой период где выравнялись случаи заражение на двух CMS, то постояно WP ломают, заливают вредоносные коды и т.д. И практично никогда Drupal, вот прям серьезно, практично никогда. Так что не МИФы....

Answer 9

[rozadn]

Любая cms подойдет. Корзину можно закаментировать и она не будет выводится, так же поступить с личным кабинетом что бы нельзя было зарегистрироваться. А форму отправлять через модуль (быстрый заказ, купить в один клик....). Вот пример моего магазина flower.dn.ua

Answer 10

[tden4ik]

Joomla+joomshopping - легко, просто, расширяемо, функционала хватит и на серьезный магазин.

Answer 11

[Александр Филиппенко]

То что описано, это даже не магазин, а витрина. Тащить сюда целую CMS для магазина - перебор. Если вы уверены что процесса оформления покупки, доставки, оплаты на сайте не появится в обозримом будущем, то проще всего взять любой популярный фреймворк с админкой, и сделать на нём.
https://api-platform.com/
вот например.
Это будет реально проще и быстрее чем любая CMS.
Но если магазин окажется успешным, и потребуется расширять функционал, то тут наоборот, стоит присмотреться к готовым решениям. Их уже выбирать исходя из конкретных задач и бюджета.

Comments

[Андрей Решетов]

А имея только базовые знания js, как много времени займет изучение этого?

[Александр Филиппенко]

Андрей Решетов, хм. Ну если вы именно понимаете программирование, и хорошо с английским, то посмотрев годный видеокурс, и вооружившись документацией, вы в любом случае за пару недель разберётесь в новой технологии.
Чтобы было проще, имеет смысл остановиться на Node.js.
https://adminbro.com/ Тут есть готовая админка и пример приложения с использованием express

[Андрей Решетов]

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

[Александр Филиппенко]

Андрей Решетов, можете ещё посмотреть в сторону headless cms, или вещей типа hasura.io в качестве бэкенда. Но тогда придётся осваивать инструменты серверного рендеринга для фронтенд-фреймворков. Если конечно хотите чтобы сайт нормально индексировался всеми поисковиками.
Можно будет не вникать в бэкенд, и прокачать фронтенд.
Или действительно взять CMS. На Node.js они, кстати, тоже существуют, но популярных нет.

[Андрей Решетов]

Александр Филиппенко, тяжко конечно без хорошего английского( Но попробую разобраться может с hasura.io. Сейчас погуглил, проблема, что многое непонятно даже на русском. Ладно, еще посмотрю, почитаю по этому поводу, может что-то выйдет из этого. В любом случае спасибо за ответ)

[Александр Филиппенко]

Андрей Решетов, не за что) У хасуры, кстати, много хороших примеров на их ютуб канале) Там правда опять же на английском и в основном с индийским акцентом, но всё же)
И я на ней, некоторые вещи, которые делались достаточно сложно на фреймворках с ОРМ, повторил играючи)

Answer 12

[Алексей Неонов]

Самое простое решение - Wordpress + Woocomerce.
Но очень тяжелое и требовательное по ресурсам сервера.
Но и плюсов много. Очень много плагинов, как бесплатных, так и платных.