Почему CMS не используют фреймворки?

Может быть дело в том, что многие ныне популярные CMS начали разрабатываться, когда в обороте был plain PHP

this

Почему существует весьма немало проектов (к примеру, тех же магазинов), которые НЕ используют CMS

потому что существующие CMS не подходят под их задачи и потому что все CMS говно в целом по причине первого пункта.

Но есть например https://octobercms.com/, которая на ларавеле, и подобные им, но они слишком молоды что бы получить достаточную популярность, а старшие братья слишком сильные позиции имеют (в умах людей).

Последний Друпал переписали под фреймворком Symfony. Первые версии Друпал были до Симфони, так что в посте выше все правильно сказано.

Почему существует весьма немало проектов (к примеру, тех же магазинов), которые НЕ используют CMS, но при этом _используют_ фреймворки?

Потому что иногда проще написать самому и получить на 100% то, что нужно, чем пытаться прикрутить ЦМС под свою предметную область.

Например Django-CMS

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

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

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

инструменты берут понеобходимости в ином случае грош-цена разрабу.

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

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

бритва оккама - Не следует множить сущее без лишней на то необходимости

Wordpress?

Yii Framework Extensions / Laravel Packalyst?

Под твоё описание подойдёт множество фреймворков, если обвесить их плагинами.

drupal 8 переписали с использованием компонентов symfony
wordpress слишком старый
за остальных не скажу

вообще CMS на базе фрэймворков много. Laravel -> October, Ignite -> PyroCMS.

инструменты берут понеобходимости в ином случае грош-цена разрабу.

Ой только не надо вот этого. Опять получается у вас, что разраб - и швец, и жнец и на дуде игрец. А чем будет заниматься тимлид, манагер и дирехтор? Змузи хлебать? Чтобы знать хотя бы все популярные ныне фреймворки и CMS, нужно задротить на них всё свободное от работы время, и не иметь ни семьи ни чего-либо ещё. Инструменты берут не по необходимости. Если ты разраб, ты приходишь в контору, которая использует инструментарий, который ты знаешь, и пашешь там.

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

Ёршик и зубная щётка суть по себе идентичны - инструменты помогающие вычистить до блеска свой писуар и писуары однополчан.

Ну и дальше красивые пафосные речи. Бла-бла. Спасибо.

Но ведь можно, наверняка, сделать эдакую недо-CMS пере-фреймворк

это называется CMF. реализации - Drupal и MODX

это называется CMF. реализации - Drupal и MODX

Спасибо. И отдельное спасибо за адекватные ответы.

Почему существует весьма немало проектов (к примеру, тех же магазинов), которые НЕ используют CMS, но при этом _используют_ фреймворки

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

людей которые могут разрабатывать под cms намного меньше

Я читал исходники одного из самых популярных CMS. К сожалению, за давностью лет, не помню, какого. Но помню, что регулярно съезжал под стол. Потому что не смотря на то, насколько я паршивый разработчик, но там было много кода просто за гранью здравого смысла. Может, сейчас ситуация улучшилась, но что-то мне подсказывает, что не с чего ей улучшаться. А людей, разрабатывающих под цмс мало, потому что, как ты написал, никому не хочется ковыряться в _ГОВНО_коде, да и платят за это меньше, чем за разработку на каком-нибудь symphony.

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

Я читал исходники одного из самых популярных CMS.

Уж не phpNuke ли это был?

Уж не phpNuke ли это был?

Нет что-то из Drupal/Joomla/Wordpress. Что именно - уже не помню.

Это называется CMF

... Но если посмотреть на популярные же CMS, то, насколько я понимаю, для их разработки фреймворки не использовались. Как так?

Ну, во-первых, CMS-ки появились намного раньше всех популярных, современных фреймворков.

Во-вторых, это на хрен не нужно, и даже вредно ) Во всех «популярных» PHP-шных фреймворках в погоне за универсальностью накручено столько всего, что они процессор грузят весьма не по-детски. Зачем все это тянуть нижним, скрытым уровнем в CMS-ку?

Вообще, весьма не вредно уметь программировать на чистом PHP - например, чтобы реализовать эффективно работающее REST API.

Зачем все это тянуть нижним, скрытым уровнем в CMS-ку?

За тем же, зачем это всё тянут во все веб проекты.

... За тем же, зачем это всё тянут во все веб проекты.

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

Для решения каждой задачи нужно использовать наиболее подходящие инструменты, а не те, которые зазубрили один раз в начале профессиональной деятельности. Ну и здравый смысл не игнорировать в угоду популярным «шаблонам» мышления и деятельности. «Это всё тянут во все веб проекты» как раз те, кто не очень дружит со здравым смыслом - таких достаточно много на просторах Интернета )

Ну да. Дядя заказчик не может подождать неделю, пока ему на laravel магазин сделают. Петя-вордпресс за вечер что-нибуть сообразит. Через неделю: «Петя, сделай пожалуйста учет остатков на складе. Нужно очень срочно, ну прямо чтобы сегодня уже было готово. Петя ты где? А-у-у-у-у!»

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

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

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

держите наркомана

Ну, когда по существу сказать нечего оппонентам, только и остаются такие аргУменты - анонимно бзднуть )

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

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

Потому что всё это тормозное избыточное дырявое хипстерское говно. Никто не хочешь переписывать свою CMS over Framework каждый год.

Для этого уже написаны библиотеки-расширения для CMS-ок или фремворков.