Движок сайта — основная платформа, от которой зависит весь дальнейший процесс разработки проекта. К сожалению, часто приходиться сталкиваться с ситуацией, когда выбор CMS происходит по необъективным причинам: разработчик не знаком с другими сервисами, не было предусмотрено дальнейшее развитие ресурса и т.д.
Это только на первый взгляд кажется, что в любой момент любой движок можно допилить и доделать под свои нужды. На самом же деле каждый из них имеет ограниченный функционал, который можно расширить только правкой исходного кода CMS, что есть великий грех.
Так на что же действительно стоит опираться при выборе движка под интернет-проект?
Знания о платформе
Наличие опыта и знаний о какой-либо CMS или CMF – серьезный аргумент только для тех создателей сайтов, которые не очень хорошо знакомы с программированием. Разработчики же имеют некоторые преимущества в этом плане. Большинство популярных движков написано на PHP, поэтому если знаешь этот язык, то уже сможешь разобраться с основной структурой платформы.
Конечно, изучение документации и API – это тоже непростой процесс, требующий времени и практики. Однако он в любом случае неизбежен, если, конечно, не хотите всю жизнь заниматься созданием и поддержкой сайтов на одном только Wordpress. Тщательный разбор внутреннего устройства CMS не только позволит основательно узнать ее, но и в целом улучшит навыки программирования.
Поэтому делать выбор движка только на том основании, что уже раньше доводилось иметь с ним дело, стоит разве что в том случае, если очень важны сроки сдачи проекта и действительно нет времени изучать новую платформу.
Зависимость от коммьюнити
Очень часто приходится сталкиваться с мнением, что наличие большого сформировавшегося сообщества вокруг движка как-то характеризует его качество. Мол, если у Wordpress есть большое русскоязычное коммьюнити, а у Drupal оно не так велико и по большей части англоговорящее, то первый движок имеет преимущество над вторым.
Наличие возможности оперативно узнать ответ на любой интересующий ответ, найти готовое решение или общаться на родном языке – это, конечно, полезно, особенно при первом знакомстве с CMS. Однако это все очень важно только поначалу, потом вам все равно придется столкнуться с нерешаемыми проблемами, такими как излишняя тяжеловесность и плохая масштабируемость того же Wordpress. Иначе говоря, после изучения движка вам все равно придется иметь дело с его недостатками, и тут сообщество ничем не поможет.
Поэтому совет тот же – выбирайте CMS с большим коммьюнити только в том случае, если вам критично важна скорость изучения платформы.
Развитие проекта
Любой более-менее крупный и успешный проект рано или поздно придется масштабировать. Это могут быть как новые пожелания по функционалу ресурса, так и банальное следование за новыми тенденциями – движок либо его технология устареет. А значит, внесения изменений не избежать, как и головной боли, связанной с их внедрением.
Однако значительной части проблем удастся избежать, если выбирать CMS «на вырост». Для этого еще при разработке концепции сайта нужно ответить на следующие вопросы:
- Какой функционал для сайта базовый и должен быть реализован в первую очередь?
- Что можно отложить на потом и сделать уже после релиза основной версии?
- Какие фичи могут понадобится в долгосрочной перспективе?
- Какие могут быть проблемы с разработкой всех необходимых функций и насколько они решаемы в текущей версии CMS и ее ближайших релизах?
- Актуален ли используемый движок и его технологии и сколько лет они таковыми останутся?
- Насколько просто можно будет реализовать на выбранной CMS абсолютно новый функционал, не предусмотренный в пунктах 1-3?
Ответы на эти вопросы должны получиться как можно более подробными, а не что-то вроде «сегодня поставлю сайт на хостинг, завтра сделаю форму обратной связи, через год прикручу форум». Может быть так, что, проанализировав ситуацию всего по нескольким пунктам, придется отказаться от выбранного изначально движка.
Доступные ресурсы
Имея неограниченные деньги, можно, конечно же, абсолютно любую CMS подогнать под свои нужды, а то и написать с нуля. Но, как правило, такой возможности нет. Поэтому выбирать нужно не идеальный движок, а тот, который вы сможете купить и установить на сервер, выдерживающий нагрузку.
С первым пунктом все понятно: есть платные CMS, есть бесплатные, подобрать что-либо под свои нужды не так сложно. А вот как определиться с нагрузкой? Есть несколько вариантов:
- Проанализировать конкурентов. Это поможет понять примерную посещаемость сайтов подобной тематики.
- Если проект новый и имеет всего несколько таких же конкурентов, не достигших пика аудитории, то следует изучать темпы ее прироста и исходя из этого рассчитать нагрузку в краткосрочной и долгосрочной перспективе.
Как определить, сможет ли сайт выдержать предполагаемую посещаемость? Самый простой способ – провести стресс-тест выбранной платформы. Как правило, даже коммерческие движки предлагают пробные версии своего ПО, вот их и следует проверять.
Если возможности провести нагрузочное тестирование нет, может помочь изучение других проектов, выполненных на том же движке. Какая у них посещаемость? Какой хостер? Какие тарифы у него есть и какой из них данный сайт может позволить себе? Ответы на эти вопросы дадут примерную информацию о нагрузке CMS на сервер и необходимой конфигурации для нормальной работы движка.
Итого, при изучении стоимости движка и цены поддержания его работоспособности стоит искать разумный баланс в этих характеристиках.
Необходимость и длительность поддержки
Если проект предполагается масштабным, то выбирать необходимо из тех движков, к которым регулярно выходят обновления для текущей версии, а также активно разрабатываются новые масштабные релизы. Также важно, чтобы переезд со старой версии на новую осуществлялся как можно проще.
Если же жизненный цикл сайта предполагается недолгим, всего несколько лет, например, то тогда регулярность и простое обновление уже не так актуальны, лучше выбирать CMS по наличию необходимого в ней функционала.
Вывод
Чтобы выбрать движок, которая не только позволит сделать сайт быстро и качественно, но и прослужит достаточно долго без каких-либо серьезных ограничений и проблем с разработкой, нужно учесть множество факторов. Не стоит рассчитывать, что неправильный подбор CMS можно будет легко исправить. В лучшем случае это заставит потратить уйму времени на перенос контента и всего функционала, в худшем же может вовсе привести к закрытию проекта.
Комментарии (23)
maxpsyhos
06.09.2016 05:35+2Забыли главный критерий — на что изначально заточена CMS. Делать магазин на CMS-ке заточенной под блоги или новостной портал на CMF-ке заточенной под документооборот — это копать себе огромную яму.
kimisa
06.09.2016 09:19Полностью согласна. Т.к. по большей своей сути реализации получаются топорные.
NeoCode
06.09.2016 08:36Я например никогда вебом не занимался, и поэтому даже с опытом программирования 15 лет выбрать что-то для своего проекта представляется огромной проблемой.
К сожалению нет материалов с глубоким и всесторонним сравнением CMS/CMF.
Как нет и материалов с последовательным приближением к построению CMS/CMF, где от простой программки «hello world» например на php автор провел бы новичка до полноценной и суперсовременной CMF, на реальных примерах объясняя необходимость и внутреннее устройство каждого аспекта CMF.OnYourLips
06.09.2016 12:09На самом деле без опыта разработки самостоятельно такой выбор сделать очень сложно.
Вы не будете видеть всех подводных камней, а их огромное количество.
Лучший вариант — найти хорошего разработчика для консультации. И всегда стоит рассматривать фреймворки общего назначения: их использование будет более продуктивным, если вы не укладываетесь в узкие рамки CMF или крайне узкие рамки CMS.
Pr0per
06.09.2016 09:12Вы бы почаще слово «движок» использовали в тексте вместо CMS, а то смысл заголовка теряется.
ainu
06.09.2016 10:42+1Спорно.
Если меня попросить вспомнить 3 самых проблемных движка (действительно проблемных — спам, абузы от хостинга, невозможность (за разумные усилия) реализации многих вещей, безопасность, высокое потребление ресурсов), и попытаться проверить их по этим критериям, каждый из них превосходно под них подойдет. В итоге сайт худо-бедно сделан, и через месяц взломан.
Читающим эти строки я бы дал один совет. Прислушайтесь к нему, пожалуйста. Совет следующий: не выбирайте CMS. Ещё раз: не выбирайте CMS, это задача разработчика, а не ваша. Не ройте себе яму, не ройте яму разработчику. Пусть разработчик сам выбирает инструменты под ваши задачи, главное эти задачи до сведения разработчика доведите. Не лезьте не в своё дело. И уж точно не покупайте лицензию заранее.
AlexandreFrolov
06.09.2016 11:56CMS отлично подходит, если вас устраивают все ее функции и нет необходимости ничего доделывать или переделывать. В этом случае вы просто устанавливаете CMS на хостинг, и пользуетесь ей после небольшой настройки.
Однако в том, что касается интернет-магазинов, без доработок обойтись трудно, даже если для выбранной CMS есть много плагинов. Проблема в том, что в бизнес-процессах торговых компаний есть особенности, причем у всех разные. Кроме того, чтобы отличаться, каждый предприниматель хочет, чтобы его магазин в чем-то был не похож на другие.
Казалось бы, можно нанять фрилансера и доработать CMS. Да, можно. Но как только он доработает CMS или плагины для нее, сразу возникнет проблема совместимости доработок с обновлениями CMS и плагинов. Обновления нужно ставить регулярно, хотя бы потому, что и в ядре CMS, и в плагинах постоянно находят уязвимости, и обновления призваны их устранять.
Поэтому проблема создания хорошего интернет-магазина (или сайта) с функциями на заказ не всегда может быть решена доработками какой-либо CMS. Или она может быть решена этим путем, но с учетом проблем с обновлением CMS. В идеале нужно создавать такие магазины на базе фреймворков и постоянно сопровождать их силами ИТ-специалистов, хоть это и более затратно.
G-M-A-X
06.09.2016 12:34>В идеале нужно создавать такие магазины на базе фреймворков и постоянно сопровождать их силами ИТ-специалистов, хоть это и более затратно.
Так а смысл на фреймворке, если более затратно? :)
Странный вывод.AlexandreFrolov
06.09.2016 12:49Смысл в том, что если сделано на фреймворке, то не нужно сопровождать изменения CMS и плагинов, сделанные в рамках доработки, чтобы эти изменения были совместимы с обновлениями CMS и плагинов.
Распространенные фреймворки тоже обновляются, и это тоже может быть проблемой. Поэтому, в частности, на нашем сервисе мы пользуемся собственным фреймворком, который развиваем и сопровождаем уже больше 10 лет.
azsx
06.09.2016 13:53Интересно, если под большую нагрузку требуется именно CMS я правильно понимаю, что ничего не изменилось и надо брать DLE или есть другие варианты?
К сожалению нет материалов с глубоким и всесторонним сравнением CMS/CMF.
А что такое глубокое и всестороннее сравнение? ps извините, что не ответом на ваш вопрос.NeoCode
06.09.2016 20:13Ну глубокое и всестороннее. Объемом с хорошую книгу на 1000 страниц:) И я не шучу, действительно книги по конкретным CMS/CMF в каком-то виде все-таки есть, а вот книг, которые бы отвечали на вопрос «а какой собственно движок выбрать для нетривиальной задачи» — нет.
AlexandreFrolov
06.09.2016 22:06Скорее тут нужны консультации специалистов, уже имеющих опыт решения нетривиальных задач )
Потому что специалисту сначала нужно проанализировать задачу, а потом уже с учетом своего опыта найти решение. Только на основе чтения книги, без практического опыта, трудно принять правильное решение.
Конечно это не означает, что книги не нужно читать)NeoCode
09.09.2016 15:49Книга-путеводитель с примерами и упражнениями даст практический опыт.
Что сейчас есть? Есть множество книг по php как таковому. Обычно уровня «для начинающих». И есть некоторое количество книг по конкретным движкам, уже почти всегда уровня «для начинающих». То есть как не понимая ничего получить некий вроде бы работающий типовой стандартный сайт.
А вот книг, которые бы начальным вопросам посвящали бы лишь десяток первых страниц, а дальше бы погружали читателя в мир разработки и внутреннего устройства фреймворков как таковых — нет. По тому же C++ такие книги есть… пусть немного, но есть (Саттер, Мейерс, Александреску и т.п.)AlexandreFrolov
09.09.2016 16:16Тут же как, чтобы осознанно, с пониманием дела выбирать CMS и фреймворки, нужно профильное высшее образование и практический опыт работы. На все это уйдет несколько лет минимум. А прочитав 2-3 книги и статьи на форумах, предприниматель, на мой взгляд, не сможет сделать выбор с пониманием дела. Т.е. выбирать CMS, фреймворк, архитектуру, должен специалист с опытом и профильным образованием. Иначе велика вероятность ошибиться, пойти на поводу у маркетологов.
По каждому фреймворку есть документация от его разработчика, более или менее подробная, примеры использования. Но объем информации огромен, все на английском, а книги устаревают еще в момент их подготовки к печати. Фактически если у вас есть практический опыт использования фреймворка, вы сможете оценить его пригодность в той или иной ситуации. Т.е. чтобы выбирать, надо уже все знать и, главное, уметь )
azsx
09.09.2016 18:15а дальше бы погружали читателя в мир разработки и внутреннего устройства фреймворков как таковых — нет.
Это описание api для разных cms, cmf + почитать index.php установленного движка, на досуге.
Но я Вам лично (и всем в общем) не советую использовать никакую cms, если Вы не делаете слишком cms'ную задачу (доска объявлений, блог, форум).kimisa
12.09.2016 08:31Не совсем согласна. Я встретила сайт на yii1, такого извращения как там я еще нигде не видела, точнее даже не думала что так реально засрать код (по другому никак это описать не могу). Хотя как говорится он идет строго в модели mvc. Вот поэтому я предпочитаю не брать самописные движки на правки и поддержку.
P.S. Был один случай с самописной CMS. Там все файлы шаблонов и моделей имели timestamp имена. В итоге только поиск по файлам и никак иначе.
AlexandreFrolov
06.09.2016 14:32Интересно, если под большую нагрузку требуется именно CMS я правильно понимаю, что ничего не изменилось и надо брать DLE или есть другие варианты?
Для высоких нагрузок нужна не CMS, а грамотная разработка архитектуры. Балансировка, кеширование, репликации, использование при необходимости таких решений как Redis, MongoDB, шардинг, CDN и т.п. Такие архитектуры не встраиваются в CMS, а разрабатываются индивидуально для каждой системы исходя из ее функций, требований к нагрузочной способности и отказоустойчивости.
azsx
06.09.2016 15:39AlexandreFrolov Вы совершенно правы, я не уточнил. Конечно, речь идет об обычном новостном сайте или другого типа развлекательной тематики на 100 — 300 тысяч хитов в сутки с пиком в 50 тысяч хитов в какой-нибудь час — и остальные в течении суток.
То есть DLE ранее был эталоном производительности, когда вебмастеру была нужна именно cms, не требовательная к ресурсам, которая более менее держит нагрузку на дорогих shared тарифах. И мой вопрос проще, что-то лучше есть под нагрузку именно среди cms, или нет?
ps
Выше Вы перечислили очень сильные технологии. Применение всех этих технологий одновременно прекрасно поможет освоить любой бюджет, обеспечить заработной платой множество специалистов. Соответственно и хитов надо хотя бы от нескольких миллионов каждый день на каждом континенте. Или просто вместо сайта написать программу с веб мордой, тогда всё зависит от ресурсоёмкости самого приложения.
kimisa
06.09.2016 17:00Все гораздо проще. CMS нужна для начинающего сайта/интернет-магазина. Т.к. нет смысла вкладываться в то, что не знай как пойдет. А вот после того, как на сайт пойдет сильная нагрузка, то тогда и нужно начинать думать переходить на что-то свое. Только такой подход окупится.
AlexandreFrolov
06.09.2016 22:01Даже в недорогих проектах использование nginx для раздачи статики, memcached для кэширования запросов к базе, оптимизация запросов SQL, применение sphinx для поисковых запросов и даже просто грамотная настройка параметров MySQL может сильно повысить нагрузочную способность. И это без космических затрат.
Возможно, в каких-то CMS есть поддержка этого на уровне плагинов, либо это может настроить грамотный программист и системный администратор. Но обычно все же это приходится встраивать, подключать и настраивать вручную…
А вот при настройке хостинга и CMS по умолчанию, без использования кэширования и sphinx для полнотекстового либо параметрического поиска наверное, с нагрузочной способностью будут проблемы…
jemali_m
Короче Wordpress!