Чтение онлайн

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

Самые известные и распространенные в Рунете: Drupal, Joomla! Wordpress.

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

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

Разработчики студийной CMS знают ее как свои пять пальцев и обычно готовы расширять ее функциональность в соответствии с требованиями заказчика. Еще бы, это их хлеб. Часто такие решения имеют бесплатную версию с урезанной функциональностью и полновесную платную.

Цена. Студия, предлагающая свою CMS, – это, конечно, не портной королевского двора, но и не фабрика «Большевичка». Скорее уж ателье. И веб-разработка даже на готовом движке в ее исполнении, вполне возможно, влетит в копеечку. Хотя средняя по отрасли цена создания сайта неуклонно снижается, всегда будут небанальные проекты, реализуемые на небанальных же финансовых условиях. Собственно, таковые, как правило, в студиях и делаются. Перед тем как заводить серьезный разговор о создании сайта в студии, обязательно узнайте, по какой схеме выдается лицензия на использование ее CMS: единовременная оплата, абонентская плата, гибридный вариант и т. д.

Самая большая проблема с подобным движком возникает при расставании с породившей его студией. Например, вам потребовалось расширить функционал таким образом, какого архитектура CMS никак не предполагает, или вас перестали устраивать условия сотрудничества. Лоскутный феодализм студий – штука коварная. Доброго вассала найти можно, хотя у сюзерена без опыта шансы на это средненькие. А выйти из отношений вассалитета порой ох как трудно: как известно из курса истории, то и дело вассалы оказывались сильнее сюзеренов и диктовали им свои условия.

Приходится констатировать: развернуть сайт на «частной» CMS – в общем случае значит поставить себя в тотальную зависимость от студии. Такой движок чаще всего неотчуждаем: доступ к ядру системы не предоставляется, а сам сайт зачастую размещается на хостинге студии. Даже если при разрыве отношений вам предоставили в открытом виде исходные коды сайта и полный дамп [12] его базы данных, нужно будет еще найти в равной мере отчаянного и квалифицированного разработчика, готового вникнуть в хитросплетения чужого движка и понять, что с ним делать.

Другая индейская хитрость – отдать бывшему клиенту исходники сайта, но без документации (в договоре о ней не сказано ни слова, так чего же требовать?). Если только она вообще существовала.

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

Самые известные и распространенные в Рунете: RBC Contents, AstroCMS, WebBuilder.

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

Не случайно львиная доля крупных, высоконагруженных сайтов Рунета функционирует на основе «самописных», созданных под них движков. Да, это дорого и долго. Причем не факт, что надежно: зависит от программиста, а вернее, от программистов: над такими нетривиальными проектами должна работать целая команда. Зато так обеспечивается тонкая «заточка» сайта под решение его сугубо специфических задач. Именно поэтому, например, на лето 2013 года соцсеть «ВКонтакте» при дневной посещаемости под 30 млн уникальных пользователей не испытывала существенных проблем со скоростью работы, сколько бы видео, музыки и фотографий ни загружали школьники на каникулах, а офисные работники – в отпусках.

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

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

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

Попытайтесь спрогнозировать, что потребуется вашему бизнесу года через три, и заложите возможность соответствующих изменений в концепцию сайта, но знайте: почти наверняка – процентах в восьмидесяти – два – три года спустя при оптимистичных темпах развития вашего бизнеса с CMS придется что-нибудь делать. Либо менять, либо всерьез модифицировать конструкцию. Думайте на перспективу, но помните: сделать сайт на века не удастся. Раз и навсегда вы CMS не выберете!

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

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

Самое важное – то, что использование готового движка не влечет за собой отказа от услуг разработчика или по меньшей мере веб-мастера. И перечисленными вопросами лучше всего задаваться вместе с ним, поддерживая непрерывный диалог.