12 причин не использовать самописные CMS

12 причин моей нелюбви к самописным CMS

Чаще всего, самописные системы возникают как «наш ответ Чемберлену» — в пику уже существующим CMS. И этим «заболеванием» страдают 99% разработчиков сайтов — в какой-то момент, в порыве инфантильного максимализма программист, многие десятки часов проведший «в обнимку» с кодом какой-либо системы, восклицает — «Доколе! Сколько можно возиться с этим убожеством?! Я же знаю как сделать лучше!» и мало-помалу «я знаю!» превращается в твердую уверенность «я могу!» и вот уже, глядишь, строчка за строчкой начинает вырисовываться костяк нового детища.

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

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

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

Кроме того, на рынке присутствуют и бесплатные самописные системы, разрабатываемые одиночками-энтузиастами.

Под понятием «самописная CMS» подразумевается массовый продукт. Уникальные разработки, предназначенные для решения «одноразовых» нестандартных задач — в этой статье не рассматриваются.

1. Жесткая привязка к одному разработчику

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

Ситуация с самописными CMS выглядит абсолютно так же — приобретая или устанавливая самописную систему, клиент попадает в полную зависимости от ее разработчика, которая выражается в следующем:

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

Говоря откровенно, автор системы может делать все, что ему заблагорассудится — закрывать разработку, продавать ее кому угодно, да хоть по примеру Одноклассников — ввести платные смс за регистрацию/скачивание дистрибутива/обновлений или встроить в последнее бесплатное обновление системы скрытый скрипт, скачивающий базу данных клиентов тех сайтов, чьи владельцы отказались платить за использование системы. Примеры, конечно, максималистские, но по факту автора практически ничто не ограничивает.

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

2. Аудит безопасности

Основой любой системы является не красивый дизайн или удобный функционал, а безопасность. Согласитесь, никому не нужна CMS, пусть даже обвешанная всевозможными «рюшиками», но которую может взломать студент первого курса КПИ.

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

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

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

3. Малая распространенность системы

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

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

4. Проработка системной архитектуры

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

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

по материалам Википедии

Учитывая, что заказчик обычно не способен оценить корректность архитектуры системы по причине закономерной недостаточности знаний в этой области, естественно этот вопрос остается на совести разработчика. Но как и в случае с безопасностью — вундеркинды встречаются крайне редко, а потому вопрос построения архитектуры самописной системы чаще всего раскрывается по методике — «не нужно изобретать велосипед». Разработчик берет за основу архитектуру одной из уже существующих популярных систем, вносит пару-тройку правок (но абсолютно не факт, что нужных и полезных) и говорит: «смотрите, моя новая архитектура революционна!».

4. Качество кода

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

5. Программистам для программистов

Давайте вспомним, почему Windows, при всей своей проблемности и ошибочности, до сих пор занимает лидирующее место среди операционных систем, используемых пользователями? По простой, в сущности, причине — она проста для освоения и не требует специфических знаний.

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

Итак, помимо того, что наш автор должен быть разработчиком, специалистом по безопасности и системным архитектором — кроме этого, он должен быть еще и специалистом по юзабилити.

6. Отсутствие полноценной пользовательской документации

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

Остальные же 95%, в лучшем случае описывались разрозненными статьями на тему «Как сделать…» или же инструкциями уровня «нажмите левую кнопку мыши», а в худшем — просто ничем, предоставляя пользователю самостоятельно догадываться о назначении того или иного элемента «методом научного клика».

7. Отсутствие API

Почему Twitter в одночасье стал настолько популярен? Почему Yandex.Карты с некоторых пор можно встретить практически повсеместно? Ответ прост — полноценный API, который позволяет программистам разрабатывать на его основе сторонние приложения.

Интерфейс прикладного программирования (иногда интерфейс программирования приложений) (англ. Application Programming Interface, API [эй-пи-ай]) — набор готовых классов, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для её использования во внешних программных продуктах.

по материалам Википедии

И хотя API не является обязательным атрибутом CMS, его наличие ощутимо упрощает разработку сторонних приложений для сайта, таких как, например — связь с внутренними системами компании (SAP, SRM, модули электронной торговли и документооборота).

8. Проблема наличия лазеек

Разработчикам популярных Open Source или же проприетарных систем невыгодно оставлять какие-либо «черные ходы» по той простой причине, что в Open Souce системе они будут быстро найдены пользовательским сообществом, а в платных CMS с закрытым кодом — аудитом. Кроме того, если в отношении системы любого типа лицензирования хотя бы несколько раз будет поднят вопрос лазеек и будут приведены доказательства их наличия, то с популярностью и прибылью можно будет попрощаться раз и навсегда.

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

9. Отсутствие профессионального сообщества и службы поддержки

Популярные Open Source CMS хороши своими открытыми сообществами, в которых можно быстро найти ответ на большинство типовых задач. Поддержка проприетарных систем управления всегда обеспечивается службой поддержки и help desk. А к кому обращаться в случае использования самописной системы?

10. Отсутствие поддержки сторонних специалистов (бес- и платных)

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

11. Отсутствие профессиональных тестировщиков

Многие считают, что тестирование — довольно простое дело. Казалось бы, ну чего там — сел, прошелся по функциям системы, выписал ошибки и отдал программисту на исправление. Однако на практике все далеко не так просто. Я не буду детально останавливаться на методиках тестирования, интересующиеся могут почитать отдельную статью в Википедии, достаточно полно раскрывающую общие понятия и профессионального тестирования программного обеспечения.

12. Отсутствие четкого вектора монетизации или скрытый вектор (для бесплатных CMS)

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

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

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

Второй же вариант развития событий выглядит и вовсе удручающе — автору в какой-то момент попросту надоедает заниматься не приносящей прибылью деятельностью или в его жизни что-то меняется и ему требуются дополнительные финансы (женитьба, рождение ребенка, постройка дома — мало ли что), но внутренние убеждения не позволяют принуждать пользователей платить за использование системы, а времени на ее разработку остается все меньше и меньше. А на donation долго не проживешь — наши реалии отличаются от западных. Закономерным итогом станет полное прекращение поддержки и в лучшем случае найдется тот, кто перехватит падающий «флаг» и продолжит разработку, а в худшем — система благополучно канет в лету.

Выводы

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

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

Подумайте, стоит ли оно того?

159 комментариев к “12 причин не использовать самописные CMS”

  1. И да и нет. Так как можно каждый пункт выполнить правильно :) Google делали два человека Сергей Брин и Лари Пейдж, WordPress вообще студент делал, а MyYear Book делали дети 15 лет(брат и сестра) ))

    Конечно они все эти системы которые мы видим сейчас не сделали сами и досих пор не делают сами. Они собрали команду со временем :) Но первые значительные строчки написали они :)

    ОтветитьОтветить
  2. Awilum, соглашусь, но приведенные примеры — скорее исключение из правил и тут есть свои ремарки — Брин с Пейджем делали не столько Google как таковой, сколько именно алгоритм поиска; WordPress делался уже не тем студентом, который делал b2/cafelog; а в MyYear Book — дети были, насколько я помню, только авторами идеи :)

    Но, к сожалению, в массе своей — разработчики самописных CMS никак не относятся к этой когорте и те поделки, которые получаются — совсем не похожи на перечисленные системы, а те «первые значительные строки» настолько кривы, что с самого начала получаются просто гомункулусы :)

    ОтветитьОтветить
  3. Хорошо! Я согласен с Вашими выводами,но что конкретно хотите предложить?

    ОтветитьОтветить
  4. © Yaroslav.Ch я соглашусь конечно с тем, что большинство считают себя революционерами мира и делают свою систему чего либо, что перевернуть мир, но выходит это у единиц… А какая польза от этих велосипедов ? Опыт…. может они и пишут свою CMS хоть она и не станет убийцей друпала но опыт разработки подобных систем получить можно :) Программист(веб) должен написать свой шаблонизатор,фреймфорк и CMS :)

    ОтветитьОтветить
  5. Сам ответил и убил все вышеуказанные аргументы :-)

    Все зависит от цели, постановки задачи и преследуемой идеи. Если идея банальна и автор изобретает велосипед (кстати, тут давеча очередной изобрели http://donbass.ua/news/technology/2009/11/03/izobresti-velosiped-nevozmozhno-a-vot-obrezat-vpolne-foto.html) — дело не возможно подпадает под изложенное выше. А если, как правильно сослался первый комментатор, автор делает что-то действительно новое и своё, то о не самописной системе и речи быть не может.

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

    Да, и я написал свой движок. С информацией, админкой и т.п.

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

    Т.е. смысл делать уже есть. Теперь осталось ответить себе на вопрос — а вдруг кому-то еще нужно именно такое решение? Без особых требований к безопасности, требованиям по памяти и т.п.? Именно такое: простое и работающее. Не требующее многих дней на сравнения, работу с сотнями форумов в сетях, разворачиванием дополнительных тестовых площадок для сравнений и т.п.

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

    ОтветитьОтветить
  6. Воспользоваться самописным CMS можно если быть уверенным на все сто процентов. Я отдаю предпочтение команде спецов программистов, нежели одному самоучке. Хотя и среди самоучек есть гении.

    ОтветитьОтветить
  7. Иван, предложение очень простое — не использовать самописные CMS и не соглашаться на предложение их применения для разрабатываемых сайтов (личных и коммерческих). Существует масса как платных, так и бесплатных систем, хорошо себя зарекомендовавших по всем 12 изложенным выше пунктам.

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

    ОтветитьОтветить
  8. Awilum, а вот тут соглашусь, но с одной корректировкой — программист должен написать ее для себя и не предлагать ее другим пользователям до тех пор, пока не будет уверен в том, что его система действительно чего-то стоит и кроме того, он готов заниматься ее развитием и вкладываться в нее.

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

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

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

    ОтветитьОтветить
  9. Vovas,

    Сам ответил и убил все вышеуказанные аргументы :-)

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

    автор делает что-то действительно новое и своё, то о не самописной системе и речи быть не может.

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

    Да, и я написал свой движок. С информацией, админкой и т.п.

    Ну и, ты стал продавать его (как ты сам говоришь — неидеальный, незаконченный, с уровнем кода не выше среднего) хоть одному клиенту? Или ты активно стал его пиарить по «интернетам» с предложением использовать? Ведь нет, правильно? Ты написал его исключительно для себя и сам же его и использовал.

    Тут вопрос не в том — нужно разрабатывать или нет, важен момент камерности или публичности, а кроме того ответственности.

    Теперь осталось ответить себе на вопрос — а вдруг кому-то еще нужно именно такое решение? Без особых требований к безопасности, требованиям по памяти и т.п.?

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

    Вот и вопрос — чего ради использовать то, что заведомо не соответствует нужному уровню?

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

    Только как правильно заметил Awilum — в качестве тестовых площадок для оттачивания программистом своего умения и мастерства. Не больше.

    ОтветитьОтветить
  10. Rostislav., честно говоря, я не очень себе представляю, какие действия нужно произвести, чтобы быть уверенным в чужом самописном на 100%. Разве что отдать его на аудит специалисту действительно высокого уровня или же получить его от такого специалиста, после чего перепроверить у еще одного.
    Правда не совсем ясно — какой смысл в этом действии.

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

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

    ОтветитьОтветить
  11. @© Yaroslav.Ch: вот это — считаю почти истиной.

    «Основная проблема в том, что львиная доля эти гомункулусов сразу выбрасывается в свет и, более того, начинает предлагаться пользователям (как платно, так и бесплатно).»

    Потешить ЧСВ — без этого многие начинающие программеры не могут. :-)

    ОтветитьОтветить
  12. Спасибо! Вы ответили на многие мои вопросы.Я не использую самописные CMS. Для успешной продажи продукта нужен хороший продукт, хорошая цена и хорошая реклама, она не зависит своя система или чужая, но безопасность нужна той и другой.

    ОтветитьОтветить
  13. @vovas: ну тешить Чувство Собственной Важности можно и каким-то другими путями, и кроме того, в большинстве случаев находится кто-то слегка по-профессиональнее, который радостно макает новоиспеченного «убийцу чего-то там» носом в его же продукт жизнедеятельности.
    Проблема только в том, что чаще всего это происходит далеко не сразу.

    ОтветитьОтветить
  14. Замечательный блог, интересные материалы, буду заглядывать.
    Вроде как все разложено по полочкам, но если брать конкретные примеры «самописных» КМС, из хотя-бы ру-говорящего нета, то нифига не понятно.
    Итак, №1: MaxSite CMS — вроде самопис, но ведь заслуживает уважения / lдоверия? Хотя отпадает, поскольку там уже небольшое коммунити есть.
    №2: семейство «танцующих» КМС, они же Румба (Румба ХМЛ, Румба Бланк, Румба Ньюс и тп). Да, разработчик один, но и сами КМС уже достаточно продвинутые на данный момент, и судя по отзывам сведущих в программировании людей, код у последних версий неплох, АПИ достаточно простое, шаблонизатор тоже не самый сложный, надежность — вроде не слышно, чтобы Румбу взломали….
    №3: Блоголет — отличный проект, тоже самописный. И что? Имеющий прямые руки и светлый мосх программер не сможет использовать уже наработанное, и доделать при необходимости?
    #4: NGCMS — тоже на сегодняшний день разработчиков не куча. Но проект уже в нынешнем состоянии догонит ДЛЕ, АПИ как-бы тоже не сложен (ну пишут же люди плагины, значит, не закрытый АПИ).
    №5: Open Blog — разработка словенского программера(офсайт open-blog.info). По качеству интерфейса для конченого пользователя этот проект «сделает» все вышеназванные. Жаль, что он реально самотужный, и коммьюнити там пока увы, нет, а глюков хватает.

    Что скажет уважаемый автор поста про вышеуказанные проекты?
    И что он скажет про качество кода также «самописной» КМС xzengine (к сожалению, проект полумертв, или скорее мертв, так что вопрос чисто риторический)? Спасибо.

    ОтветитьОтветить
  15. @Ацкий сисОдмин: спасибо за оценку и комментарий.
    Я могу продолжить Ваш список еще пятью-десятью системами того же уровня, каждая из которых будет включать в себя пару-тройку пунктов из списка, приведенного выше. А еще могу прибавить столько же закрытых систем, разработанных студиями. Но только вот что это изменит?

    Суть качественной системы в соответствии всем вышеизложенным пунктам, но не каким-то определенным на выбор. Да, я могу согласиться, что 90% соответствие можно приравнять к полному, но если из 12 пунктов соответствие можно найти только по 2-3, то это не будет верно.

    MaxSite CMS: уважения — заслуживает, но доверия — объективным причинам пока нет. И тут дело не в Максе, которого я глубоко уважаю, а именно в самой системе. И никуда не отпадает по причине того, что единственный пункт, который можно исключить: наличие комьюнити, да и то не слишком активного.
    Мы обсуждали с Максом его систему — например, тот же аудит безопасности пока что проводить не планируется, поскольку у него нет на это ни времени ни средств. Распространенность системы — покажите мне хотя бы один серьезный проект, который работает на MS CMS? Разработчик — только сам Макс. Зависимость — только от него. И т.д. Именно поэтому пока что я бы не рекомендовал ее использовать для своих проектов.
    Кроме того, получить от Макса ответ на вопросы: «как долго будет продолжаться разработка системы» и «каким образом планируется ее монетизация» — мне не удалось, этот комментарий по каким-то причинам уже не был утвержден :)

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

    Блоголет: лично мне в нем не нравится как минимум один серьезный момент — он изначально построен не на БД. Доработка — это вообще очень сложный вопрос, поскольку никто не знает какой уровень этой самой доработки потребуется. Если мы возьмем какой-то движок и перепишем в нем 90% кода — это будет вообще считаться уникальным проектом, не имеющим отношение к CMS.

    NGCMS: как и румба — более-менее устоявшаяся система. Разработчиков несколько, что уже позволит избежать жесткой привязки. Хотя скорость ее разработки тоже не слишком велика, но вроде бы двигается. Но при этом форум — слабый, что явно показывает не слишком высокую распространенность и заинтересованность.

    Open Blog: не видел, оценить не могу.

    xzengine: могу сказать только то, что она мертва. Последнее обновление, если не ошибаюсь, было в 2008 году. Я ее увидел уже позже и потому даже не пытался оценивать.

    А теперь у меня вопрос к Вам — представим, что я сделал клиенту сайт на Блоголете, но потом мои пути с заказчиком разошлись и он ищет нового. Какой процент разработчиков знаком с Блоголетом и будет готов взяться за дальнейшее развитие этого сайта?
    Или Макс завтра бросит разработку MS CMS и куда вынуждены будут деваться те, кто организовал полноценный блог на его системе?

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

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

    Поясню, почему я не приводил примеры определенных систем — любая из них (за исключением совсем мертвых) развивается и потому завтра может выйти из-под тени этого списка и перестать быть «самопиской», а превратиться в полноценную и серьезную систему.
    А мониторить состояние каждой и редактировать постоянно пост — я просто замучаюсь :)

    ОтветитьОтветить
  16. @© Yaroslav.Ch: позволю себе с Вами не согласиться, кроме описанных Вами минусов есть и свои большие плюс:

    — абсолютная гибкость системы (все под один проект и все только под тебя, что хочешь — то и получаешь)
    — скорость работы самописных кмс как правило гараздо выше (если учесть что ты не заказал самопись за 200 баксов под гиганский портал)
    — Есть моменты которые возможно сделать только на самописи — возьмем к примеру интернет портал где идет работа менеджеров с прямыми рекламодателями — дак вот менеджерам нужна своя админка где будут выводится их контакты основанные на регистрации пользователей с поправками менеджера, плюс будет выводится время до снятие баннера, время когда он был снят и многое другое….

    Ну ИМХО этих трех причин достаточно чтобы связываться с самописью ;-)
    P.S. также хотел сказать на счет поддержки и привязки к одному программисту, в принципе почти вся компетентная поддержка платная — консультации на нубские вопросы на форумах не в счет, так что Вы можете спокойно обратиться к другому программисту и он в принципе сможет разгрести тот код и поправить его — PHP оно везде ПХП))))

    ОтветитьОтветить
  17. @Deimos: то, что описываете Вы — это уже совсем другая сторона вопроса. Это не «самописная CMS», а уникальное программирование — разработка, которая создается под одного-единственного заказчика.
    А я в статье никоим образом не постулировал, что для любых целей необходимо использовать только массовые разработки и более того, даже не касался вопроса подбора решений для проектов — это тематика одной из будущих статей :)

    также хотел сказать на счет поддержки и привязки к одному программисту, в принципе почти вся компетентная поддержка платная

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

    так что Вы можете спокойно обратиться к другому программисту и он в принципе сможет разгрести тот код и поправить его — PHP оно везде ПХП))))

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

    ОтветитьОтветить
  18. Спасибо за ответ. Действительно, не учел одного момента — вы пишете касательно коммерческих проектов. Тут вообще подошел-бы еще жеще — отбросил-бы даже движки под GPL, за небольшим исключением. Поскольку платит заказчик, то и делать ему, имхо, надо на коммерческих продуктах, ИМХО конечно.
    Хотя, не исключаю возможных преимуществ GPL-проектов перед коммерческими.
    Один серьезный проект на Максайт-таки назову: rybalka.tv. Хотя с вами полностью согласен — походу автор того проекта очень много чего доделал / переделал.
    С другой стороны — достаточно старый проект Nucleus CMS, явно не попадающий под ваш расклад. Только вот уступает он нынешним «молодым» самописам. И тоже не возьмусь на нем поднимать даже собственный блог, хотя сама КМС мне очень нравится — админка там поудобнее многих, и другие многие вещи. Но будучи старым, он так и остался, походу, полуфабрикатом…
    Кстати, возникает вопрос: а может, типа готовые КМС — это уже вчера. Может, будущее, или даже сегодня — за CMF (фреймворками или конструкторами)?

    ОтветитьОтветить
  19. @Ацкий сисОдмин:

    Спасибо за ответ.

    Спасибо Вам за интересные комментарии :)

    Тут вообще подошел-бы еще жеще — отбросил-бы даже движки под GPL, за небольшим исключением. Поскольку платит заказчик, то и делать ему, имхо, надо на коммерческих продуктах, ИМХО конечно.

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

    В качестве примера можем сравнить объем усилий и затрат для создания сайта из десятка станиц на Битрикс (Неткат, Юми) или на WordPress. При этом не требуется никакой особый функционал — разве что простенькая форма обратной связи. Есть смысл покупать проприетарную CMS?

    Кроме того, платность CMS далеко не всегда означает ее безопасность, дружественность и удобность. Опять же — посмотрите на тот же Битрикс, который стоит в максимальной редакции как крыло от истребителя, но удобством не отличается в принципе.

    Один серьезный проект на Максайт-таки назову: rybalka.tv. Хотя с вами полностью согласен — походу автор того проекта очень много чего доделал / переделал.

    Было бы интересно узнать у автора — по какой причине он выбрал в качестве основы именно MaxSite CMS.

    С другой стороны — достаточно старый проект Nucleus CMS, явно не попадающий под ваш расклад. Только вот уступает он нынешним «молодым» самописам.

    Честно скажу, я думал включить 13-м пунктом возраст проекта, но отказался от этой идеи по причине того, что возраст никоим образом не означает качество. Многие «динозавры» до сих пор работают на старой архитектуре, которая очень сильно ограничивает их развитие — плюшек и свистелок разработано уже много за столько лет, а вот что касается нагрузки и удобства — проблема, поскольку менять архитектуру крайне тяжело.

    Кстати, возникает вопрос: а может, типа готовые КМС — это уже вчера. Может, будущее, или даже сегодня — за CMF (фреймворками или конструкторами)?

    Скажу так — на мой взгляд, тут не «вчера» и «сегодня». Все, как и в случае с выбором — проприетарная/OpenSource система, зависит по большей части от поставленной задачи. Опять же, долго и упорно собирать из конструктора то, что уже готово — изобретение велосипеда. Но вот там, где требуются какие-то оригинальные, нестандартные и «самописные» решения — хороший CMF незаменим, поскольку точно так же позволят не собирать все тот же велосипед, а воспользоваться готовыми «кирпичиками».

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

    ОтветитьОтветить
  20. В принципе я поддерживаю точку зрения автора. Хотя бывают и исключения. Я некогда работал в аутсорс конторке, там был свой framework написанный на пхп (на сорсфорже одно время он неплохо смотрелся). Ну были конечно минусы, но и плюсы тоже присутствовали. Мы все-таки попытались привести пхп к нормальному ООП (на сколько смогли) :)
    Но по большому счету — для малых и средних проектов писать что-то свое ИМХО смысла не имеет.

    ОтветитьОтветить
  21. @SibNext:

    Ну были конечно минусы, но и плюсы тоже присутствовали. Мы все-таки попытались привести пхп к нормальному ООП (на сколько смогли) :)

    Это напоминает старую фразу «хоть и плохонький, но мой» :) Опять же, для каких-то личных целей — можно и использовать в качестве тестового полигона, средства повышения квалификации и прочего. Но вот для клиентов — все-таки не стоит.

    ОтветитьОтветить
  22. @© Yaroslav.Ch:
    На самом деле каждую ситуацию нужно рассматривать в отдельности. Просто бывает, что есть небольшая нестандартная задача, и решить ее проще именно на чем-то маленьком и своем :).
    В большинстве случаев я согласен с темой… но хочу заметить, что исключения тоже бывают.

    Ну и естественно крупные проекты … скажем а-ля одноклассники — врятли бы хорошо смотрелись на той же Джумле.

    ОтветитьОтветить
  23. @SibNext:

    Просто бывает, что есть небольшая нестандартная задача, и решить ее проще именно на чем-то маленьком и своем :).

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

    А под понятием «самописная CMS» я имею ввиду именно массовый продукт, на основе которого создаются типовые клиентские сайты.

    ОтветитьОтветить
  24. @© Yaroslav.Ch:
    Да это все очевидно. Просто немножко в определениях не сошлись. :)

    Кстати ковырял на днях аццкую поделку из вышеописанной серии. (Оч. сильно попросили помочь восстановить работоспособность). Придумал пару-тройку новых выражений великого и могучего — пока ковырял. :)

    ОтветитьОтветить
  25. @SibNext: ну, скорее это мой недосмотр — думаю, стоило в определении сверху дописать момент, связанный с массовостью :)

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

    ОтветитьОтветить
  26. Чувствую нашли общий больной мозоль :)
    Хотя… уровень и опыт человека, создающего тот или иной проект тоже играют определенную роль. Я видел как недо-вебстудии такие «шедевры» выдают даже на топовых CMS — страшно становится. Да к тому же еще и деньги за это запрашивают немалые.
    Недавно со мной консультировались… типа стоит заказывать или нет…

    Вебстудия запросила за работу 15К рублей. (работы на 1 день) Дизайн в артистире + джумла (без каких-либо настроек и какой-либо оптимизации).

    ОтветитьОтветить
  27. @SibNext: думаю, и Вами и мне на этот «мозоль» регулярно отдавливают :)

    Возможно, руководству студии срочно понадобился новый Лексус, а может на мечту всей своей жизни — Бентли не хватает, а экономия на завтраках уже не помогает… как знать :)
    С другой стороны — сделанный не руками горе-верстальщика дизайн и базовая Джумла для того, кто будет заниматься этим сайтом особой подлянки не подложат — в отличие от очередного «убийцы Вордпресс».

    ОтветитьОтветить
  28. Аха, добавим сюда же прогон по базе из 20к каталогов (нашу неоптимизированную джумлу) — все что они предлагают в качестве раскрутки — получаем тот еще коктейльчик:)
    Как то плавно на оффтоп скатились:)

    ОтветитьОтветить
  29. @SibNext: ну а что, нормально — сделали и сразу в бан :) Чтоб не мучился.

    Все равно тема близкая — качество работы.

    ОтветитьОтветить
  30. Согласен с автором статьи, со стороны заказчиков выбирать для своего сайта чужой самописный CMS, это почти обрекает их подписать по жизненный (пока живет сайт;) контракт с разработчиком этого CMS. Некоторые в каментах и говорят о том что многие великие проекты когда-то были самописными (самопалами) и это верно, и такие самоделкины двигают индустрию благодаря своим идеям, но сколько тысяч самописных проектов не получили никакого распространения? И это как раз и делает их слишком не благоприятными для заказчиков.

    ОтветитьОтветить
  31. Пишут новый CMS программисты быдло и самоучки, настоящий профессионал, разберется в короткий срок с API CMS, и на следующий день приступит писать плагины и шаблоны к ней, если этого требует ТЗ.

    ОтветитьОтветить
  32. И по моему не корректно называть в рекламе свои будущих пользователей быдлом… Хоть и не всех но все же..

    ОтветитьОтветить
  33. С минусами согласен. Но в этом вопросе, как и во многих других, есть две стороны медали. В самописных CMS наряду с минусами есть и плюсы. И использовать или нет самописную CMS зависит от целей, задач и требований выставляемых создаваемому проекту.

    ОтветитьОтветить
  34. @disappear: на мой взгляд, ее стоит использовать только в том случае, если ее функционал включает в себя какие-либо возможности, которых нет в других системах. То есть это уже вопрос «уникального программирования» (он уже обсуждался в комментариях).

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

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

    ОтветитьОтветить
  36. @disappear: — ну собственно от чего ушли — к тому пришли. :)
    Тут мнения как раз и разделяются на 2. А пост (как писал автор выше) подразумевает под собой промышленное внедрение самописных CMS

    ОтветитьОтветить
  37. @disappear: в сущности, количество подобных проектов, под которые требуется написание совершенно отдельной системы, на общем фоне не так велико.

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

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

    ОтветитьОтветить
  38. Это я и имел ввиду, что смысл использовать самописную CMS есть только для нестандартных проектов и решений.

    ОтветитьОтветить
  39. @disappear: а, кстати, интересна Ваша точка зрения — какие проекты можно назвать настолько оригинальными, чтобы под них требовалось создание отдельного решения? (исключая Одноклассников и Вконтакте, конечно :) )

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

    Вот такое ТЗ врятли можно натянуть на существующие системы.

    ОтветитьОтветить
  41. Нет там именно проект был (тема авто). Мне ТЗ скинули, я просто описал один из пунктов. У нас одна конторка схватила проект, и почитав ТЗ поняли, что половины слов не знают :) Я отказался, ибо там команду нужно было собирать, а на тот бюждет который они предлагали в субподряд — можно было найти либо узбеков, либо индусов. :)

    ОтветитьОтветить
  42. Именно такие большие проекты и ещё некоторые с совершенно нестандартным дизайном что подчёркивает имидж, статус, в общем каким-то образом действительно обосновано.

    ОтветитьОтветить
  43. @SibNext: я так понимаю, должно было получиться нечто вроде обширной доски объявлений?

    По своему опыту рекомендовал бы все же индусов ;) Пишут они по-узбекски, конечно, но зато иногда понимают английский :)

    ОтветитьОтветить
  44. @disappear:
    Ну насчет дизайна — не согласен. Дизайн можно притянуть за уши. И AJAX, и прочие навороты.

    ОтветитьОтветить
  45. Незнаю, когда работал во фриланс конторе — доставались проекты, которые велись разными исполнителями. Единственный адекватный код — только у русскоговорящего населения. Не хочу показаться расистом, но практика показала что именно так.
    ЗЫ, снова ушли в оффтоп ;)

    ОтветитьОтветить
  46. @SibNext: а я работал с индусами — ты знаешь, самое интересное, что как программеры они были очень даже неплохи, а вот наши тестеры оказались просто отвратными. Но тут нельзя говорить — «все их программеры» или «все наши тестеры» — кому как повезло.

    З.Ы. Да уже как-то чуть ли не по привычке :)

    ОтветитьОтветить
  47. @Vitaliy:
    Соглашусь по сути, что из-за стремления написать свое, пусть в расчете «лучше и лучше», загибается много перспективных проектов. Развиваются ДЖПЛ-проекты только те, где собрался коллектив. Если автор тянет один, то это рано или поздно приводит к смерти его самописа. Получается,стОит возникнуть сообществу, т.е. появиться заинтересованным в нем профессионалам, и проект становится «на крыло»?

    Автор статьи — НА ВОРДПРЕССЕ СВЕТ КЛИНОМ НЕ СОШЕЛСЯ!
    Ну почему талантливые отеч. профессионалы-светлые мозги, не видят очевидных вещей? Этот монстр себя изживает, его ждет та же судьба, что и ПХП-Нюке.
    Впрочем, это конечно, оффтоп.

    ОтветитьОтветить
  48. @Ацкий сисОдмин:

    Получается, стОит возникнуть сообществу, т.е. появиться заинтересованным в нем профессионалам, и проект становится «на крыло»?

    Как показывает практика — в основном, да.

    Автор статьи — НА ВОРДПРЕССЕ СВЕТ КЛИНОМ НЕ СОШЕЛСЯ!

    А я разве где-либо говорил, что нужно использовать только WordPress? То, что на нем работает этот блог — лишь дань удобству и не более того. Я совершенно сознательно не упоминал в статье какие-либо конкретные системы, чтобы не разводить holy wars по поводу и без :)

    Этот монстр себя изживает, его ждет та же судьба, что и ПХП-Нюке.

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

    ОтветитьОтветить
  49. Не упоминал, но любовь к нему лезет из всех щелей.
    ПХП-Нюке — так уж и по этой причине? Или по причине того, что тупиковой оказалась сама его парадигма — вместо блоков универсального типа там конкретно жесткие блоки. Даже сейчас в более новых разработках заметно «наследие»(php-fusion, danneo, small-nuke — все тоже самое. Тогда как в 2_z project-e(весьма жаль, что умирает:-((() и NGCMS уже все более гибко. Не агитирую. И аз не программер, может профаню?).
    «Удобство» блин! У вас глюк в комментах. Курсор по строке стрелочками не двигается, и еще что-то. Может виноват мой брауз(Макстон),но в других блогах все ок.
    Но самое что меня напрягло: даже не последняя версия, а 2.9.1-поставил на денвер на локали, так ни в ИЕ ни в макстоне даже в админку не пускает(только в опере). Хорошо удобство…

    ОтветитьОтветить
  50. А это ИМХО уже проблема совместимости. Если Макстон или ИЕ 6 — не мудрено, что будут глюки.

    ОтветитьОтветить
  51. @Ацкий сисОдмин:

    Не упоминал, но любовь к нему лезет из всех щелей.

    Хм, ошибочное, на мой взгляд, мнение. Я вообще еще использую и другие CMS. Просто для блога WordPress действительно проще.

    ПХП-Нюке — так уж и по этой причине? Или по причине того, что тупиковой оказалась сама его парадигма — вместо блоков универсального типа там конкретно жесткие блоки.

    То, о чем говорил я — внешняя причина, то о чем Вы — внутренняя :) Но обе действительно присутствуют.

    «Удобство» блин! У вас глюк в комментах. Курсор по строке стрелочками не двигается, и еще что-то. Может виноват мой брауз(Макстон),но в других блогах все ок.

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

    а 2.9.1-поставил на денвер на локали, так ни в ИЕ ни в макстоне даже в админку не пускает(только в опере). Хорошо удобство…
    Ответить

    Это проблема не WordPress, а как правильно отметил коллега SibNext — совместимости. Макстон в принципе не стоит рассматривать как отдельный браузер — это просто надстройка на ИЕ, использующая его движок.

    ОтветитьОтветить
  52. Спасибо автору за полезную статью. Абсолютно согласен со всеми пунктами,но особое удовольствие доставило прочтение комментариев. Всегда интересно какими словами тебя называют ))).
    Да, я пишу собственную CMS, но в последнее время использую её исключительно для своих проектов.
    Никогда не запускал сайтов на WordPress, Joomla и прочих. Просто перестал делать сайты на заказ. Для этого сейчас достаточно школоты и прочих умельцев. Без обид, но запустить блог или визитку на современных публичных CMS может любой, знакомый с компьютером.
    Более серьёзные проекты считаю лучше делать не для дяди, а для себя. Пусть они приносят денежку мне. Именно для таких целей нет лучше собственной CMS`ки, которую знаешь вдоль и поперёк.

    ОтветитьОтветить
  53. @bm:
    Собственная CMS разрабатывается 1-2-3 людьми. И тут 2 стороны медали. С одной стороны уязвимости (даже если они и есть) не будут никем использоваться в следствие не распространенности данного продукта. А с другой стороны они обязательно будут. И в гораздо большем количестве, нежели в CMS, над которыми работают сотни людей.
    Естественно я не имею ввиду уникальные проекты. Т.к. Вы говорите про систему для своего сайта или блога — то тут речь о масштабности я так подозреваю не идет.

    ОтветитьОтветить
  54. @bm: спасибо за комментарий.

    Да, я пишу собственную CMS, но в последнее время использую её исключительно для своих проектов.

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

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

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

    ОтветитьОтветить
  55. Добрый день, Ярослав.
    Недавно нашел ваш сайт. В первую очередь заинтересовала статья 12 причин не использовать самописные CMS. В первую очередь хотелось бы отметить высокую полезность для меня (да и наверное для всех остальных посетителей) этой стати непосредственно и самого блога вообще.

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

    Но для нового сайта почти все студии предлагают сайты со своей «не шаблонной» CMS которая полностью, по их словах, удовлетворит ВСЕ мои потребности. В этих студий очень впечатляющее портфолио как по брендам, так и по дизайну и функционалу. Насчет готовых CMS они говорят, что их под мое ТЗ не очень подходят и их надо будет сильно «выкручивать», что скажется на адекватной работоспособности системы.
    И небольшое количество студий предлагают платные системы 1С-Битрикс (были также предложения NetCat) и бесплатные Joomla и TYPO3 и говорят что мое ТЗ легко реализуется на этих системах. Но работы этих студий (функционал) мне как раз и не очень нравятся и не очень им доверяю.
    И мне, как и другим заказчикам сайтов, которые сами не могут дописать сайт на основе CMS, остается вариант купить сайт с самописной CMS. И соответсвенно еще раз «наступить на теже грабли». Чего б сильно не хотелось.
    На сайт мною написано детальное ТЗ на 100страницах и боюсь что самописная CMS может не подойти под него. И прочитав вашу публикацию, совсем растерялся.

    ОтветитьОтветить
  56. @Павел: добрый день и спасибо за комментарий и оценку.

    В сущности, все зависит от того — какие требования к функционалу Вы предъявляете изначально.

    Если в основе лежит стандартный функционал большинства CMS — например, новости, статьи, рассылка, галереи, доски и прочее (см. описание любой крупной CMS) — можно не морочить себе голову и реализовать сайт на основе готовой системы.

    Если функционал, скажем так, «относительно нестандартный» — есть смысл взять готовую CMS и модифицировать ее до нужного Вам уровня. Например, Вам нужно сделать социальную сеть — Вы берете или Drupal или Joomla и дорабатываете готовые модули.
    В этом случае уже необходимо выбирать ту систему, возможности которой наиболее близки к тому, что Вам необходимо — будет быстрее и дешевле.

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

    Если же функционал является чем-то настолько уникальным, что вариантов нет вообще никаких — это означает, что CMS ему попросту не нужна. Ни готовая, ни самописная. Это будет отдельное standalone решение, которое разрабатывается уже по другой модели.

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

    ОтветитьОтветить
  57. @© Yaroslav.CH:
    Спасибо за Ваш ответ.
    По своей сути наш сайт это электронный каталог электроизмерительной техники (фотографии, технические описания, цены). Сайт должен продавать (но это не интернет магазин, конечный договор делает менеджер по телефону). Коммерция через сайт не ведется. Сейчас на старом сайте около 9000 товаров.

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

    Также на сайте есть стандартные опции типа Наши Услуги, Вакансии, О нас.

    Сейчас функционал простой не чем не сложнее обычного интернет магазина. Каких-то сложных алгоритмов и нестандартных задач не прогнозируется. На будущее планируется дописывание отдельных не сложных модулей, но это развитие — так должно быть.

    Основной упор ставиться на очень хорошее автоматизированное SEO о чем вы уже написали в своей статье «10 обязательных SEO-пунктов любого Технического Задания на разработку сайта» с чем я полностью согласен.
    Основное сейчас для меня это подобрать наиболее подходящее CMS.

    ОтветитьОтветить
  58. @Павел:

    сайт это электронный каталог электроизмерительной техники (фотографии, технические описания, цены).

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

    До каждого отдельного товара каталога или подрубрики должна быть возможность прикрепить отдельных : ответственного менеджера

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

    файлы

    Значит магазин должен поддерживать функцию электронных товаров.

    FAQ, опросы, глоссарий

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

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

    две цены (грн руб)

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

    товаров на распродажу или на покупку

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

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

    Эти моменты входят в саму CMS, но сложного обычно нет ничего, поскольку для title берется название товара, а для description — его описание. Но в этом случае нужно очень серьезно работать с описаниями.

    возможность добавления к товару новостей, акций, статьи и другое.

    Зависит от того, как Вы себе видите эту реализацию — можно вручную, а можно — автоматически.

    Экспорт и импорт товаров всех и из отдельных рубрик.

    Нужна поддержка XML со стороны CMS или модуля каталога.

    Основной упор ставиться на очень хорошее автоматизированное SEO

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

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

    Реализовать все это можно и на бесплатных CMS и на проприетарных — но смотреть нужно в первую тройку. Drupal, TYPO3, Joomla/Virtuemart и Bitrix, UMI.CMS, Amiro.CMS.

    На Open Source CMS собрать такой каталог полностью на бесплатных модулях не получится (как минимум, я не помню подобных) — нужно будет докупить некоторое количество платных, а на платных CMS — некоторый функционал нужно будет дописать.

    Насчет готовых CMS они говорят, что их под мое ТЗ не очень подходят и их надо будет сильно «выкручивать», что скажется на адекватной работоспособности системы.

    Это обычный ход на тему — «как продать свою систему и подсадить заказчика на обновления у нас». Основываясь на том, что Вы написали, ничего особо выкручивать не надо — все это довольно стандартный функционал, просто часть из которого надо взаимосвязать друг с другом.

    Основное сейчас для меня это подобрать наиболее подходящее CMS.

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

    Например, на сайте Битрикса, Амиро или Юми есть возможность разослать заявку на разработку сайта, всем официально зарегистрированным разработчикам на этих CMS.

    Для Битрикс можно прямо приложить ТЗ, для UMI — хуже, указывается только тип сайта и бюджет, а у Amiro — нужно заполнить бриф.

    Для этих CMS воспользуйтесь этими сервисами, а для бесплатных — попробуйте биржи фрилансеров. Там, само собой, присутствуют не только студии, но и одиночки.

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

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

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

    ОтветитьОтветить
  59. Ярослав помогите мне определится с CMS.
    Я никоем образом не буду расценивать это как рекламу, а просто как результат вашего опита работы в данной сфере.
    Брать самописную CMS я точно не буду.

    Не могу выбрать между Bitrix, Drupal и Joomla. «Бесплатность» системы роли не играет основное здесь:
    — большой, но понятный функционал, подходящий под мои потребности;
    — возможность легкой доработки после сдачи мне сайта разработчиком;

    ОтветитьОтветить
  60. @Павел: для того, чтобы однозначно сказать — «берите вот это, а вот это — не берите» нужно внимательно читать ТЗ, прикидывать функционал и подбирать систему.

    Иначе — это не вариант и дело даже не в рекламе, а в том, что применить опыт при оценке «на пальцах» толком не получится. Поэтому, я могу только рекомендовать «в общих чертах».

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

    Вся проблема заключается в том, что Битрикс и Друпал — это не CMS в принципе, а практически CMF. Да, на обеих системах есть готовые модули для интернет-коммерции, но они изначально рассчитаны на то, что их их частей будут собирать то, что нужно.
    Joomla\Vitruemart — готовое решение для среднего интернет-магазина, но под Ваши нужды нужно будет дописывать или докупать платные модули уже непосредственно под магазин.

    То есть, в любом случае, Вам нужен нормальный и толковый разработчик, варианты поиска которого я изложил в предыдущем комментарии. На мой взгляд, Вы не совсем с той стороны подходите — Вы пытаетесь, не зная преимуществ и недостатков систем, выбрать CMS, а уже под нее брать разработчика. Оптимальнее, как я уже говорил — разослать свое предложение и ТЗ разработчикам на разных системах, а после выбрать, допустим, 3-х наиболее толковых, встретиться с ними и обговорить их предложения.
    Кстати, именно поэтому я в самой статье и не приводил в пример ни одну CMS — в ней изложена лишь моя точка зрения на общий принцип выбора.

    И есть еще один момент — исходя из логики CMF, порекомендовать ту или иную систему можно тоже с большой натяжкой. Все зависит от того, кто будет Вам на ней разрабатывать сайт. Например, на том же Bitrix есть масса хорошо работающих проектов, а масса — просто ковыляющих и еле-еле сделанных. С Drupal — ситуация аналогичная. С Joomla\Vitruemart — все несколько по-другому, поскольку магазин обычно все берут уже готовый и дописывают/докупают к нему определенные функциональные ячейки.

    Но, опять же, 100% сказать — «Вам нужен готовый магазин» или «Вам нужен CMF» без детального ознакомления с ТЗ — не получится. Даже те моменты, которые Вы изложили в комментарии, при разработке могут пониматься двояко — может быть Вам достаточно просто «полуавтоматического» решения, а может быть — нужно строить отдельную автоматизированную систему. Все зависит от ТЗ и Ваших пожеланий.

    ОтветитьОтветить
  61. Лично мой выбор Joomla ( но только потому что я очень люблю GNU и вообще свободно распространяемый софт) . P.S. а что такое ТЗ? чтото там Задачи?

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

    Почему?

    Да потому, что — удобно!

    Удобно нажать несколько кнопок, что-то куда-то перетащить, натянуть на шаблон и сайт готов…

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

    ОтветитьОтветить
  63. @Zares: спасибо за комментарий.

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

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

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

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

    Вот тут, честно говоря, не совсем понял Вашу мысль — что имеется ввиду «вручную»? Вернуться к временам pure HTML и использовать только его для создания сайтов или применять логику генерации скриптами готовых страниц и отдавать уже именно их пользователю?

    P.S. Понравились статьи (и, конечно, мысли в них) на Вашем блоге — подписался, буду читать.

    ОтветитьОтветить
  64. если разработкая занимается профи который шарит и в продвижении, хорошо умеет кодить, не боится ООП, имеет понятие о сокрытии данных и работе с БД то лучше самописная цмска чем популярная в котрой известны все дыры

    ОтветитьОтветить
  65. @BOLVERIN: спасибо за комментарий.

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

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

    ОтветитьОтветить
  66. @© Yaroslav.CH:
    CMSку можно писать модульно и расширяемую) или даже в виде такого себе фреймворка — установил, поклацал на нужные пункты и пользуйся, а если шаришь в программировании то можно специально для своего акка поставить расширенные права для тонкой настройки и разработки плагинов на базе CMS.
    с фреймворком даже удобней — можно сделать как саттелит, так и лендинг или еще что-то буквально в пару кликов.
    ну это мечта)) для начала надо накорябать серьезный класс обработки ошибок и основу)

    ОтветитьОтветить
  67. Я все таки считаю что считаю что самописная CMS это хорошо, и тому есть ряд причин….ну во-первых существенно меньше спама, во-вторых индивидуальный интерфейс, в-третьих надо еще и мозг заставлять работать…а то совсем забудет что такое php))))

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

    ОтветитьОтветить
  69. Как-то использовал cms одной местной веб-студии для сайта предприятия, но вскоре плюнул и перенес все на joomla и вполне доволен (и заказчик тоже)

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

    ОтветитьОтветить
  71. Если сайт создается своими руками для себя же, то самописная CMS — однозначно. Ибо я хочу полностью знать, как он устроен. Когда я решу что-то поменять, мне не придется полдня рыться в чужом коде.

    ОтветитьОтветить
  72. Считаю велосипеды двигателем прогресса. WYSIWYG-редакторы и комбайны считаю адским злом, которые убивают качественные сайты. Клиент (или его подчинённый) должен иметь хотя бы минимальные познания в вёрстке, например. А сайтом должен заниматься не обязательно программист, но хотя бы опытный пользователь уровня «сделать по примеру». Вордпрессы и Джумлы способствуют как раз понижению качества сайтов, но повышению удобства и скорости разработки.

    Многое в проекте должно быть довольно жёстко настроено, а не зависеть от настроения заказчика.

    Во всяком случае, о дырах самописной CMS-ки нельзя прочитать на популярных форумах и рассылках. Нельзя и получить удар поддых при массовом взломе (вспомним ситуацию, когда сотни тысяч форумов SMF оказались взломаны на автомате). Чтобы сломать самопис, нужно серьёзно потрудиться над конкретным сайтом, не зная внутренностей — а это дорогой труд. За те же деньги сломать опен сорс можно несколько раз. К тому же защита от взлома может быть довольно нестандартной.

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

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

    ОтветитьОтветить
  73. Давно задумывался над продолжением работы над своим первым сайтом написанном на php. Но из-за разных заморочек и недостатка времени начал использовать Joomla и WordPress. Если есть желание можно что угодно заточить под себя. Лично я считаю, что использовать собственную CMS можно лишь если у вас достаточно времени на постоянное ее обслуживание и модернизацию. В противном случае, если у вас мало времени и нужен полноценный сайт, то лучше воспользоваться бесплатными популярными движками для сайтов.
    Это лично мое мнение.

    ОтветитьОтветить
  74. С CMS, допустим, понятно что это хорошо, а что Вы скажете насчет Famework?

    Если мои «самописные» сайты работают на распространенном Frameworkе? Это хорошо?

    ОтветитьОтветить
  75. @ don-site:Framework — это просто набор гаечек и винтиков, а вот что вы из него соберете и какой дополнительный функционал навесите — зависит только от Вас.

    ОтветитьОтветить
  76. Yaroslav.CH написал(а):

    @ don-site:Framework — это просто набор гаечек и винтиков, а вот что вы из него соберете и какой дополнительный функционал навесите — зависит только от Вас.

    Открыли америку… вопрос ведь был в другом хорошо/плохо, ну да ладно CMS пишутся для определенных целей, например блог, форум итд.. выходит правильно поставленная задача подскажет правильное решение, а будет это CMS, Framework или «самоделка» — если это соответствует стандартам, то качественному специалисту не составит труда разобраться в коде. Следовательно, какой будет функционал — никак не повлияет на «хорошо/плохо». Мое личное мнение. Может не совпадать с чужим.

    ОтветитьОтветить
  77. @ don-site: если Вы хотите получать конкретный ответ, то стоит сначала задавать конкретный вопрос. Ваш же звучал по принципу: «я езжу на велосипеде, который сам собрал из болтиков и гаечек, а раму взял на разборке — скажите, это хорошо или плохо?»

    На «хорошо/плохо» влияет не функционал решения как таковой, а то — как он написан, кем и с каким уровнем квалификации. Соответственно, качественный специалист может быстро разобраться только в том коде, который написан не менее качественным специалистом.

    ОтветитьОтветить
  78. Соглашусь с автором. Вообще иногда удивляешься насколько люди считают себя самыми умными и делают все с нуля, убивая кучу времени на придумывания велосипеда. Ведь ещё Адам Смит подметил что специализация правильно влияет на общее балгосостояние. Ведь никто же из нас не придумавает велосипед или тем более автомобиль для себя лично чтобы на работу ездить :-) Так и с сайтами и блогами — пишите интересные материалы и статьи, а программированием пусть занимаются профессионалы :-)

    З.Ы. не в обиду доморощенным гениям :-)

    ОтветитьОтветить
  79. Ярослав, спасибо, очень интересная и познавательная информация. Тоже склоняюсь к выбору какой-либо из популярных CMS, не хочется последующих возможных проблем с единственным разработчиком и его продуктом.
    Не могли бы вы подсказать, а как бесплатные CMS (например Joomla) в плане производительности? Ну вот, если под проект взят выделенный сервер (dedicated), включено кеширование сайта и всех модулей, проведена базовая оптимизация графики и шаблона, — сколько посетителей/хитов сможет выдержить Joomla? Ведь наверняка в этом отношении с платными CMS Joomla не сравнится?

    ОтветитьОтветить
  80. @ Maximus: спасибо за комментарий.

    Не могли бы вы подсказать, а как бесплатные CMS (например Joomla) в плане производительности?
    Ведь наверняка в этом отношении с платными CMS Joomla не сравнится?

    К сожалению, это очень теоретический вопрос. Тут дело не в сайте как таковом, а в том — какие функциональные решения у Вас используются, как и кем они написаны.

    Если хотите для примера, то есть сайт на Joomla, состоящий из набора страниц и большого количества графики, который летает даже на простеньком VDS при среднем посещении около 7-9К в день, а есть аналогичный сайт на Bitrix, который при наличии nginx в качестве фронт-сервера и двух серверов (один под сайт, другой под БД), ложился наглухо под одновременной нагрузкой в 2-3К человек — много разных компонентов, много запросов, много выборок. Исправили методом включения внутреннего кеширования Bitrix и распараллеливания апача. Сейчас уже все ок и проблем нет — нормально держит ~25К в день. Вроде бы красиво, но не забудьте посчитать затраты.

    Вы должны понимать, что Joomla это CMS, которая в чистом виде позволяет просто создавать страницы и не более того. Любой дополнительный функционал нужно либо дописывать, либо брать готовые компоненты — а вот за качество и скорость их работы ответственен уже только их разработчик, но не сама Joomla. Следовательно, сравнение уже строится не по принципу Joomla или Bitrix, а Joomla+[название компонента] и Bitrix.

    C другой стороны, Bitrix — это огромная цельная (хотя и монструозная) система с кучей функционала, который внутренне связан между собой. С точки зрения разработки он страшноват, но есть определенные плюсы, отсутствующие в других системах. Но поставить его на shared хостинг даже в чистом виде, практически нереально — он не сможет там нормально жить и ляжет даже под минимальной нагрузкой.

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

    Также добавлю еще один момент — зачастую делается так: берется бесплатная система и дешевый фрилансер-программист, который пишет под эту систему определенный модуль с тысячей бессмысленных обращений к базе, петлями, ненужными рекурсиями, кучей лишнего кода т.д. Также берется криворукий админ, который настраивает сервер через известное место. Зато все очень дешево. После этого работа принимается, сайт запускается, но бешено тормозит. Кто виноват с точки зрения заказчика — правильно, бесплатная CMS.
    Альтернативно — берется тяжелая платная система и заказывается разработка у адекватного профессионала, а настройку выполняет адекватный же админ. И все ок.
    Отсюда и рождается тема «Платное круче бесплатного», хотя привязки-то нет никакой. Это абсолютно реальные ситуации, я достаточное количество раз наблюдал их «в живую», причем в разных ипостасях — и как мучаются с бесплатными системами, и как рвут волосы на голове с использованием платной.

    Исходя из этого, чистое сравнение «Joomla или [название CMS]» — не подходит. Все зависит от того — что именно Вам требуется, какой функционал будет использоваться, кто его напишет и т.д.

    ОтветитьОтветить
  81. @ Yaroslav.CH:
    Спасибо огромное, Ярослав, такого подробного и развернутого ответа даже не ожидал!
    Благодаря ему принял решение — буду работать с Joomla, до и после установки любого дополнительного компонента буду проверять количество запросов в базу, постараюсь найти хорошего админа для настройки сервера.
    Еще раз спасибо, теперь я ваш постоянный посетитель!

    ОтветитьОтветить
  82. @ Maximus: не за что — главное, чтобы информация была полезной :)

    Благодаря ему принял решение — буду работать с Joomla,

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

    Еще раз спасибо, теперь я ваш постоянный посетитель!

    Спасибо, постараюсь и дальше радовать Вас ценными статьями :)

    ОтветитьОтветить
  83. Прочитал статью, и плеваться захотелось. Сравнивать коммерческие системы, OpenSourse и «самописные» одно и тоже что сравнивать Боинг, танк и велосипед.

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

    ОтветитьОтветить
  84. Александр написал(а):

    Сравнивать коммерческие системы, OpenSourse и «самописные» одно и тоже что сравнивать Боинг, танк и велосипед.

    Судя по реакции, Вы как раз относитесь к категории «самописных разработчиков». Боюсь, масса программистов с Вами не согласится ;)

    В самописных cms есть один большой плюс — быстрое и сравнительно дешевое развитие проекта.

    Быстрое за счет чего, простите? Просто потому, что Вам так хочется думать? ;) А сравнительно дешевое — вопрос крайне спорный.

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

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

    Даже о смене разработчика.

    О том — как поменять разработчика (если возникнет необходимость), нужно думать сначала, а не потом — когда проект заработает. Потом уже будет поздно.

    ОтветитьОтветить
  85. Судя по реакции, Вы как раз относитесь к категории «самописных разработчиков». Боюсь, масса программистов с Вами не согласится ;)

    И да и нет. Разумеется начинал со своих движков, делал сайты и на oscommerce, юзал и джумлу и друпал, правда последние две не в коммерческом проекте, чему собственно сейчас рад. Сейчас я больше склонен делать сайты на фреймворках, чем на таких cms как скажем джумла. Один из проектов выполнял на CodeIgniter. Последнее время только свой фреймворк, хотя изучаю и другие.

    Быстрое за счет чего, простите? Просто потому, что Вам так хочется думать? ;) А сравнительно дешевое — вопрос крайне спорный.

    Я где-то полгода назад выполнял работу по верстки+jquery+эффекты с тем чтобы натянуть это на joomla. Мои клиенты запустили сайт на этой cms и решили сделать навороченный дизайн. Так вот денег которые они мне заплатили за изготовление всего главной страницы, хватило бы на то, чтобы полностью сверстать и натянуть дизайн на все страницы. Да мне пришлось больше времени уделить этому т.к. я эту джумлу полностью изнутри не знаю, но в этом вся и соль: клиенты «знающих» не нашли. А страницу главную им хотелось, т.к. нарисовала дизайнер. И стандартные плагины с формой обратной связи (она была на главной) их не устраивали. Им нужно было свое оригинальное. Не знаю как вам, но когда я писал обработчики этой формы, я не нашел, что джумлу можно понять за один день. Вот вам и быстрота и дешевизна на лицо.

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

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

    Ну и что. Сделал я им сайт — есно сделал дешево, да и на первых порах умом шибко не отличался. И работают эти сайты уже не один год. А почему работают? Да потому, что владельцу сайта некогда им заниматься. Т.е. он добавил на него десяток статей, и сотню объявлений и все. И какой ему резон было вкладывать в стоимость сайта тестирование на безопасность, если этот сайт у бабушки на куличках.

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

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

    Но в конце концов сами подумайте: выбрал один чувак мерседес 600, а другой москвич 412. Когда сломаются машины, кому легче и дешевле будет найти автомеханика. Вот вам и ответы на вопросы.

    ОтветитьОтветить
  86. @ Александр:

    Последнее время только свой фреймворк, хотя изучаю и другие.

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

    Да мне пришлось больше времени уделить этому т.к. я эту джумлу полностью изнутри не знаю, но в этом вся и соль: клиенты «знающих» не нашли.

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

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

    Опять же — исключительно субъективная точка зрения, которая звучит так: «лично я не смог разобраться с системой, поэтому заказчику эта работа обошлась втридорога.» И причем тут Joomla?

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

    «Работают» означает лишь их техническое функционирование и не более того. Сильно сомневаюсь, что не развивающийся сайт приносит достаточную прибыль. А что касается вообще «проектов-пустышек» — Вы правы, их можно делать хоть на голом HTML, разницы не будет никакой. Я же, говоря «сайт», все же подразумеваю прибыльные решения, а не «сделано для галочки».

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

    Честно? В этом случае я даже не смогу Вам ответить на вопрос: «зачем ему нужен был сайт»? :)

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

    Вы путаете безопасность и нагрузочное тестирование.

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

    Абсолютно не обязательно наличие реальных денег на сайте — есть еще абсолютно известная причина ломать: конкуренция. Особенно в узких нишах. Кроме того, ломать еще можно и ради базы данных клиентов — многие магазины ее хранят для рассылок и для ведения взаимоотношений с клиентами. Собственно говоря, даже банальная база «живых» email-адресов — это уже отличный профит для взлома, в особенности простенькой системы.

    Но в конце концов сами подумайте: выбрал один чувак мерседес 600, а другой москвич 412. Когда сломаются машины, кому легче и дешевле будет найти автомеханика.

    Отличный пример, который зачеркивает все, что Вы же сами высказали выше :) Много сейчас по дорогам ездит 412 москвичей? Много СТО знакомы с тем, как собрана эта машина? Много запчастей под нее можно достать?
    А под Мерседес, как это не удивительно, есть официальные СТО, сайты типа Экзиста, куча людей, которые занимаются запчастям и т.д.
    Так что Вы правы — вот и ответ на Ваши вопросы :)

    ОтветитьОтветить
  87. Не убедительно. Особенно насчет москвича, у нас почти все водители имеющие москвичи сами их ремонтируют.

    Так что не убедили.

    ОтветитьОтветить
  88. @ Александр: хе, ну такой ответ меня, знаете, тоже явно не убеждает :)

    Особенно насчет москвича, у нас почти все водители имеющие москвичи сами их ремонтируют.

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

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

    ОтветитьОтветить
  89. Очень оценил в статьях подсказки по различного рода терминам. Но зачем такие большие статьи? Честно вам скажу, что я и до середины не дочитал, да и думаю мало кто прочитал вообще все, а если и прочитали, то инфы получили для себя мало, потому что при чтении на копме мозги утомляются очень быстро и информацию не усвавивают.

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

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

    ОтветитьОтветить
  91. Здесь есть проблема в определениях. Ни один вменяемый программист писать с нуля CMS не будет. Есть куча разных фреймворков разработчика — например Django, Symphony или Dot.net. и так далее. Это самописный движок?

    Собственная разработка на базе надежного фреймворка может быть сильно полезна проекту. Особенно если
    1) Проект предполагает огромное количество нестандартных решений, реализация которых в других CMS будет требовать кучи ресурсов.
    2) Создается действительно уникальный проект и есть шансы получить патент на всю разработку или ее части.
    3) Вам требуется 100% контролируемость процесса и самого продукта.
    4) Проекту требуется мастшабируемость, которая не обеспечивается существующими решениями.
    5) Ну и с точки зрения стратапа вложения в собственную разработку (если они не дублируют существующие) + правильная документация могут повысить капитализацию.

    При этом конечно собственная разработка — это более высокие риски и более высокие затраты (как правило, тоже, кстати, не всегда)

    P.S. При этом очевидно что 99% всех начинающих предпринимателей необходимы стандартные функции с некоторыми вариациями, которые позволяют делать практически все популярные CMF и СMS. Выбор движка полностью зависит от задач, которые стоят перед проектом. Задачи, для которых нужна собственная разработка редки, но бывают.

    ОтветитьОтветить
  92. @Петр:

    Это самописный движок?

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

    1, 2, 4 — согласен, это именно то, что я и называю индивидуальным проектом.

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

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

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

    ОтветитьОтветить
  93. Полностью с вами согласен самописная CMS куда лучше, чем готовые платформы, но лень матушка мешает писать самому собственную CMS, вот и приходится пользоваться готовыми.(

    ОтветитьОтветить
  94. А вы не допускаете такой вариант: CMS пишется ТОЛЬКО для себя и под один конкретный проект? И сразу бывают решены практически все вопросы из 12 поставленных. Причем, как в моем случае, это, иногда, бывает вынужденное решение – по мере создания сайта возникала необходимость улучшить «эту» функцию, либо убрать «ту», либо не нравилось их взаимодействие. В результате я получил именно то, что хотел. И, самое главное, я больше, чем уверен, войти ко мне «без приглашения» — это задача не для дилетанта, а «профи» там ловить нечего. Судите сами: каждый начинающий «хакер» (а хоть и ХАКЕР), хочет доказать всему миру свою «крутость», победив Вордпрес, Джумлу или любой другой движок, из этой серии. А кого может заинтересовать моя скромная персона?! И, если честно, перепробовал кучу «движков». Об этом, если хозяин не против, расскажу в комментах к « Не WordPress-ом единым»

    ОтветитьОтветить
  95. @Sorokin Vladimir:
    Нет, не рассматриваю :) Именно поэтому в самом начале статьи я указал:

    Под понятием «самописная CMS» подразумевается массовый продукт. Уникальные разработки, предназначенные для решения «одноразовых» нестандартных задач — в этой статье не рассматриваются.

    Однако сказать, что снимаются все вопросы — это неверно, как и:

    я больше, чем уверен, войти ко мне «без приглашения» — это задача не для дилетанта, а «профи» там ловить нечего.

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

    ОтветитьОтветить
  96. Ну, если с такой колокольни, то наверно я соглашусь с вами. Вот только в моих htaccess будет сложно что-то подправить. На сайте, о котором я говорю, там только одна команда, на счёт WWW и всё! Да и я, в общем, имел ввиду только то, что бывают ситуации, когда самописка – это наиболее простое решение, в каком то ОТДЕЛЬНОМ случае.

    ОтветитьОтветить
  97. Я все таки отдаю предпочтение команде спецов, при работе в интернете перечисленным выше вопросам времени уделять просто нет, пользуюсь ВП и вполне доволен.

    ОтветитьОтветить
  98. А Блоголёт от Владимира Юшко , у меня, 4 сайта на этом движке, даже если дальше будет платно, на старой версии все что надо есть.

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

    ОтветитьОтветить
  100. «Конечно хочется выделяться самописной CMS»
    Может кто-то и пишет для понтов, выделиться, но далеко не все.

    Это первый блог где я спалил свои сайты. Кто то — когда то решил, что мои сайты на Джумле, я скромно промолчал (приятно, согласитесь) с тех пор так и считалось.

    В посте выше я написал, как появляются «самописки», у некоторых во всяком случае. Справедливости для, хочу сказать, я не являюсь заклятым противником «фирменных» движков!

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

    Правда, пришлось капитально протестировать три движка: Вордпресс, Джумла, МАКсайт, плюс десятка полтора тех, что без «баз данных», на Денвере гонял их в хвост и гриву. Какой выбрал, не скажу, что б не посчитали за пиар.

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

    Теперь на счёт поддержки – у меня остался очень неприятный осадок от первого обращения в Вордпрессовскую….. Кто работал с этим движком знает, что при загрузке картинки, у вас в спец-папочку откладывается эта картинка в 3-х экземплярах! Но разных размеров.

    Я спросил, для чего это задумано? Ведь через 2-3 года даже на простом сайте одна эта папка «перевесит» всё, что на сервере! А если у вас фото галерея?!

    Так вот что мне посоветовали: лишнее можете смело удалить. Гениально!

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

    ОтветитьОтветить
  101. Бывают такие ситуации, когда заказчик еще не представляет как будет развиваться его сайт и в процессе развития будут меняться правила, по которым он строится…

    Искать готовую систему — почти наверняка она покроет лишь небольшую часть функционала.

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

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

    ОтветитьОтветить
  102. если честно меня все CMS (кроме wordpress потому-что он не для профессиональных сайтов а для блогов,а это совсем другое) бесят. Сколько с ними я работал, Что бы сделать все как нужно для себя, нужно устанавливать кучу модулей, плагинов, темы писать, они много весят, их поисковики не любят, и пускай кто то возразит сейчас что типа разницы нет, какой сайт показывать поисковикам. Например joomlu поисковики не очень любят. Так как на таком движке много делают вареза. Кстати сейчас движки и по большей мере используются для вареза, и из за этого их не любят ПС.
    Я же предлагаю если писать CMS то для своего использования, я конечно CMS не писал, но сайты пишу сам. Сейчас кстати решил переводить сайт с движка на самописный, жалко проиндексированные страницы, но нервы дороже, люди учите веб мастеринг и нервы будут в порядке.=)

    ОтветитьОтветить
  103. Абсолютно согласна с автором. Сама работала и Joomla. Самописки считаю изобретением велосипеда. Как вообще можно сравнивать системы, которые разрабатывались тысячами разработчиков с писулькой одного нерадивого студента. Всегда отказываюсь от работ на самописках.

    ОтветитьОтветить
  104. @Оксана: «писулькой одного нерадивого студента» — ну, такой врядли что-то вообще напишет!

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

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

    А много ли чести «ковырнуть» движок какого-то-там Васи Пупкина – «нерадивого студента»?! Тем более, что это на порядок сложней…..

    Любой желающий, из инструкции к Вордпрессу, например, узнает, где лежит файлик wp-config.php в котором все ваши пароли и данные админки и базы. А у Васи и админки то нет!

    ОтветитьОтветить
  105. @Sorokin Vladimir:

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

    А Вы, следует полагать, считаете, что это плохо? ;)

    Тем более, что это на порядок сложней…… Любой желающий, из инструкции к Вордпрессу, например, узнает, где лежит файлик wp-config.php в котором все ваши пароли и данные админки и базы.

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

    А у Васи и админки то нет!

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

    А кроме того, поверьте, наличие или отсутствие админ-части не решает вопрос взлома. Зато для «Васи» легко применяется любой эксплоит или SQL enjection. И, вуаля — все готово. И да, никто не знал, где у Васи лежит конфигурационный файл.

    ОтветитьОтветить
  106. @Sorokin Vladimir:
    Владимир, к нам на работе, когда мы искали программера, приходили на собеседование люди со своей самописной CMS. В ней даже не было ООП. За две минуты мы нашли сразу несколько багов. Поэтому, если программист напишет хорошую, качественную CMS, Бог ему в помощь, но только, если это так.
    Касательно защиты: можна применить виды взлома, независящие от движка, ту же SQL-инъекцию, например.

    ОтветитьОтветить
  107. Вы правы, теорию взлома я не знаю. Но знаю другое.

    Если почитать мануал ЛЮБОГО движка, там будет совет, как надёжней защитить админку, часто советуют вообще воспользоваться услугами хостера, значит это и правда самое «ломаемое» место движка.

    А вот откровения «главного конструктора» KandidatCMS приведу дословно:

    «Вообще то не хотел говорить, но скажу так: Вы когда скрипт примериваете на локальном компьюторе на предмет функционала, то, собстенно, это и есть ваша копия будущего сайта,

    … а значит, по-мне, дак админку иметь на сервере хостинга нет смысла — все файлы страниц (новые или измененые на локалке) из папки articles и конфиг с менюшкой легче заливать напрямую через ftp-клиента с заранее собранного, так сказать, варианта.

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

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

    И последнее, вы наверно думаете, что я какой-то фанат движения «Все на самописные движки»? Вовсе нет, у меня блог на Вордпрессе, два сайта на KandidatCMS, шесть «визиток» на CMS Chainik и пару сайтов «самописных», для души.

    Но я считаю, что самописные (качественные!!!!!) движки имеют право на жизнь. И я больше чем уверен, что если копнуть биографию «именитых» CMS, то окажется, что сначала была очень удачная «самописка», потом команда энтузиастов взяла её в оборот, раскрутила, и получился всемирно известный CMS.

    ОтветитьОтветить
  108. @Sorokin Vladimir:

    Но я считаю, что самописные (качественные!!!!!) движки имеют право на жизнь.

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

    если копнуть биографию «именитых» CMS, то окажется, что сначала была очень удачная «самописка»

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

    ОтветитьОтветить
  109. @Rostislav.: Абсолютно согласен с Вами! Лучше довериться специалистам нежели написать вручную и быть взломаным в один прекрасный день…

    ОтветитьОтветить
  110. Я не программист, но по роду занятий тесно связан со всеми этими делами. Несколько раз приходилось заниматься оптимизацией сайтов написанных «на кухне». Это было ужасно, особенно, когда обращаешься к «разработчику» с просьбой изменить или добавить что либо. Общаться с такими вообще не возможно, на каждый вопрос или просьбу ответ один, при заказе сайта такой задачи не стояло, поэтому платите, будем делать. Ну ты же хочешь показать, что ты профи, так и работу делай как профи, а не как урод моральный. Нужно делать работу так, что бы заказчик к тебе еще обращался не за исправлением недоделок, а с новыми проектами и рекомендовал тебя, а не искал кого нибудь, для исправления косяков. Всегда возникает желание удавить такого товарища.
    Поэтому всем рекомендую работать с известными CMS. После прочтения статьи, еще больше стал уверен в правильности своей позиции. Полностью поддерживаю автора.

    ОтветитьОтветить
  111. Да, че там говорить, над известными CMS работают десятки, а то и сотни людей, постоянно поддерживая и обновляя свой продукт.
    Если вы чувствуете в себе силы, для создания своего движка, примените их на базе уже существующей CMC, допилите ее под себя, добавьте нужный функционал. А писать новый движок… зачем? не понимаю!

    ОтветитьОтветить
  112. @NiL:
    Приведу пример двухнедельной давности. Использоание готового движка — например, joomla или wordpress было возможно и демонстрировалось заказчику, но рядом сидел его знакомый и сказал:
    — «Нет это неудобно будет использовать, мы хотим как у меня сейчас..»

    А у него сейчас самописный движок на основе фреймворка Yii. Да, клиент понимает, что это обойдется ему дороже, чем допилить Джумлу, но в результате будет именно так, как он хотел.

    Знакомой я поставил WordPress в надежде, что ей для кадрового агенства будет достаточно. Но через три-четыре месяца оказалось, что недостаточно. Хочется свой функционал. И вот здесь МОРАЛЬ!!!! Хватит ли у вас ДУХА идти до конца новой дорогой. Придется либо нанять «переводчика» на язык программистов, либо самому разобраться во многом. Если стартап и денег нет, то может закончиться еще и терпение. Подумайте об этом как следует. ТЗ должно быть для любой системы — на готовой CMS или на самописной. И программист должен четко понимать свою задачу. Тогда и результат будет.

    В чем преимущества распространенных CMS — под них проще купить шаблон, если есть подходящий.

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

    ОтветитьОтветить
  113. @Александр:
    честно говоря, я абсолютно не понял проблемы. Ну хочется интерфейс как в предыдущей разработке? Ок, тот же WordPress позволяет перепилить админку до неузнаваемости. Да и Joomla тоже.

    Не хватило каких-то функций в WP? Ок, а в чем проблема написать свой плагин с «го и гейшами»?

    Проще говоря — какая взаимосвязь между «голой» системой и индивидуальным функционалом? :)

    ОтветитьОтветить
  114. Часто встречал информацию, что лучше не пользоваться всякими СМS, а использовать самописную, потому что будет уникальная, и поисковые системы благосклонно к такой относятся. Кому верить?

    ОтветитьОтветить
  115. @Сергей: и на каком основании будет проявляться благосклонность? Просто потому, что это не массовая система? Как-то это очень наивно звучит :)

    ОтветитьОтветить
  116. Перечитал ленту и обратил внимание на существенный момент:

    Автор считает, что для МАССОВОГО продукта самописная CMS не годится.
    Многие комментаторы приводили контраргументы попросту не заметив выделенного слова, иначе несогласных было бы меньше.

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

    Небольшой оффтопик: полгода назад ставил Magento — как она нереально тормозит сервак! Есть специальные услуги по допиливанию ее до рабочего состояния. При этом это суперпопулярный продукт с огромным тиражом.
    К чему я это написал — не всегда массовость продукта означает полное соответствие задаче. Продукт нужно тщательно подбирать под задачу. Кстати, WordPress воспринимается пользователями очень положительно как интерфейс. Немного сумбурный получился комментарий, но думаю, Вы разберетесь! Всем удачи!

    ОтветитьОтветить
  117. Целиком и полностью согласен с автором материала, гораздо лучше использовать старые добрые Вордпресс и Джумлу, они и быстрее и понятнее

    ОтветитьОтветить
  118. Я вообще не понимаю,зачем кому-то эти самописные CSM,когда есть уже готовый вариант.Допустим я пользуюсь wordpress и всем доволен,все нужные плагины в свободном доступе в интернете,удобный редактор,много шаблонов,вообщем я без wordpress никуда!

    ОтветитьОтветить
  119. А если самописный проект имеет тестирование? Имеет ряд разработчиков? OpenSource? Документирован? Имеет чёткую политику монетизации (GPL)?
    На каком этапе система перестанет быть «самописной CMS» и станет фреймворком (таким, как Laravel)?

    Где та грань, перейдя которую проект перестаёт быть самописным?

    ОтветитьОтветить
  120. @ainu: в начале статьи есть расшифровка этого понятия: «Самописная система управления сайтом — платная или бесплатная CMS, написанная и поддерживаемая исключительно одним автором-разработчиком. Чаще всего такие системы предлагаются студиями веб-дизайна в качестве платформы для заказываемого сайта.»

    ОтветитьОтветить
  121. Достаточно интересная заметка. Мы в студии тоже продвигали сайт на «самописном» движке. Итог печальный, плохо выводился в топ, решено было переделать на wordpress и все встало на свои места. Если уже делать самописный движок, то качественный и для своих собственных проектов.

    ОтветитьОтветить
  122. Мне так думается, что практически каждый разработчик, если он любит программировать искренне — он обязательно пройдет через написание собственного движка (CMS ли или CMF — не суть важно). Но затем он все равно поймет, что использовать сторонние разработки лучше даже для него самого.

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

    ОтветитьОтветить
  124. @Игорь:

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

    Даже боюсь предположить откуда такая информация :) Логика нам подсказывает, что все как раз наоборот — с популярными open source системами любой ПС работать куда проще и удобнее, чем с любой самопиской, формирующей структуру, меню и УРЛ по своему собственному разумению.

    ОтветитьОтветить
  125. А у самописной cms разве нельзя настроить урл? Хотя урлы как говорят профисиональные программисты для поисковых систем уже не играет большой роли в продвижении. Ну желательно их настроить.
    И я с вам не согласен, что самописные сайты сложно вывести в топ.
    Тут как раз всё наоборот. Я всегда своим клиентам пишу сайты визитки в ручную, и в Гугол главная страница в индекс попадает через 2-3 часа. А остальные страницы уже на следующий день. Яндекс конечно медленный индексирует.
    Если взять сайт созданный на WordPress то главная страница в индекс попадает через неделю, а остальные страницы через неделю.
    Самописные cms как я заметил в индекс Гугола попадают через 2-3 дня. и также остальные страницы быстрей попадают в индекс. И они не создают дубли страниц.
    Поэтому можно быстрей самописные сайты продвинуть

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

    ОтветитьОтветить
  127. Вы не совсем правы. Каждая система управления начиналась с одного разработчика, в т.ч и WP (в котором кстати нашли критическую уязвимость до версии 3.6. И многим заказчикам взломали сайт, по таким вот советам как у Вас) Так, как не каждый заказчик обновляет скрипт, а некоторым фрилансеры отключают обновления целенаправленно). Просто дальше все зависит от простоты работы с CMS и её функциональностью, если CMS находит воодушевление у масс, дополнительные разработчики находятся быстро и пролукт выходит на новый уровень!

    И по поводу «качества кода» — в WP он мягко сказать не очень :) Об этом много сказано, ровно как и в Joomla которая грузит туеву кучу ненужных классов и библиотек))

    ОтветитьОтветить
  128. @Станислав:

    И многим заказчикам взломали сайт, по таким вот советам как у Вас)

    Честно говоря, не уловил сути — как мой совет аккуратно относиться к выбору системы, влияет на взламывемость сайтов? Или Вы хотите сказать, мол, WP ломают все кому не лень, а самописку не взломает даже гуру? ;)

    Так, как не каждый заказчик обновляет скрипт, а некоторым фрилансеры отключают обновления целенаправленно).

    Сорри, причем тут целенаправленное отключение обновления или забывчивость — к самой системе? Это все равно, что обвинять автопроизводителя в том, что в машине закончился бензин.

    если CMS находит воодушевление у масс, дополнительные разработчики находятся быстро и пролукт выходит на новый уровень!

    Ключевое слово тут «если». Кроме того, речь в статье идет не только об open source, а скорее даже о проприетарных продуктах одной студии. И там никаких дополнительных разработчиков не может найтись просто априори.

    И по поводу «качества кода»

    В большей степени речь идет не о качестве кода, а о его безопасности и мониторинге этой безопасности. Тот факт, что в WP уязвимость была найдена и оперативно устранена, говорит не о «невзламываемости» системы (такого не бывает в принципе), а о скорости реакции.

    ОтветитьОтветить
  129. @Станислав:

    Приведу пример — небезызвестный smashingmagazine работает на движке WordPress — у них таки были время, знания и возможности для написать свое, но в результате выбрали WordPress.

    По Joomla — у всех из моего круга, кто использовал — были взломы с последствиями. С WP не было, причем у одного и того же человека, например.
    Уточню, что он не девелопер а просто пользователь.

    У меня есть один старенький самописный проект — очень лаконичный, все что нужно делает, но я заглянул в коды и понял что нужно переписывать. Человек со стороны, в принципе, поймет. Но проще будет на WordPress.
    Так что, Станислав, на мой взгляд WP далеко не худший выбор!

    ОтветитьОтветить
  130. Как по мне, так зачем мелким и средним проектам писать CMS с нуля, ведь есть уже готовые решения с множеством разработчиков и плагинов, например тот же WordPress, на котором можно создавать проекты от блога до новостного сайта и даже портала.

    ОтветитьОтветить
  131. А какие способы есть для проверки CMS сайта? Я вот пользуюсь 2ip.ru, itrack и через xtoolza.info .

    Первые два как-то вообще не о чем. А вот второй неплохо тащит даже редкие CMS.

    Также пробовала всякие плагины к браузеру типа wappalyzer, RDS, w3tech.

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

    ОтветитьОтветить
  133. @Awilum: да вы правы.
    Автор стать о много забывает.

    Я в корне не согласен c автором. Может на 2010 год да, но уже 2016.
    Я бы сказал что это + и — для начинающего.
    Сайт coca-cola думаете на WP работает? Нет. Самописный движок студии.
    Любой крупный проект, это самопистный движок. Да есть минусы как политика, ты не знаешь что как, но и плюсов много. гибкость чисто под вас, скорость итд.

    Так что надо было рассматривать конкретные задачи. Магазин на WP встретить можно только начального ур. Но тут вопрос, а стоит ли ? Ведь все равно придется запатить 30баксов ии заплатить студии 100 + уникальный дизайн.

    ОтветитьОтветить
  134. @Дима: во-первых, в статье речь не идет о WP и абсолютно не только о бесплатных системах. Сайт Coca-Cola может (честно, мне лень сейчас проверять), работать на платном коробочном движке — я не знаю, почему Вы решили, что это обязательно студийная самописка.
    И далеко не «любой крупный проект» — это самописный движок. С таким же успехом, это может быть «коробка» + доработка. Нормальные «коробки» уже давно не являются движками в классическом понимании — это скорее CMF, который можно «собирать» под свои нужды.
    Потому и суть статьи в том, что нужно подбирать движок в зависимости от своих задач, а не слепо соглашаться на то, что предлагает студия. Причины расписывать еще раз не буду, они все есть в статье.
    А возраст статьи значения не имеет — кардинально ситуация на рынке услуг с 2010 года не поменялась.

    ОтветитьОтветить
  135. А у меня такое мнение, что если нет особых вариантов, то лучше сделать продукт низкого качества, чем вообще ничего не сделать. Недавно я взял заказ на интернет магазин и парралельно с этим пишу диплом. Собственно как-то 2 недели пыхтел над джумлой с крякнутым компонентом интернет магазина. Процесс разработки был мучителен (куча крякнутого кода с малым количеством объяснений в документации), результат меня не устраивал (недостаточно гибкая система, чтобы сделать конкретно то, что я хочу). Так что помня о том случае, я решил написать свою систему, использовать ее для интернет-магазина, чтобы получить устраивающую меня функцональность и внешний вид, повысить свой уровень, использовать этот проект еще и для диплома и при этом сэкономить время. Живу я в семье не очень обеспеченной, поэтому для меня этот способ заработать деньги еще реален с совмещением диплома.
    И вот читаю я твою статью и думаю, мысли то правильные в целом, но только вот не получается так поступать пока что. Нужно чтобы и времени и сил и денег хватало для добросовестной разработки.

    ОтветитьОтветить
  136. @pen: то есть я правильно понял — Вы взяли ворованный продукт и не смогли его доработать. И по этой причине теперь считаете, что правильным является написать свои костыли, чтобы потом продавать их страждущим? :)

    ОтветитьОтветить
  137. @Yaroslav.CH: Ага, я никогда не плачу за софт и цифровой контент, либо пользуюсь ворованным, либо opensource. Так что в моем случае проще написать свою CMS, когда нет возможности взять подходящую бесплатно. :^]

    ОтветитьОтветить
  138. @pen:
    Ага, я никогда не плачу за софт и цифровой контент, либо пользуюсь ворованным
    сомнительное достижение и не менее сомнительный повод для гордости, честно говоря. К тому же, интересно — как к этому относятся заказчики? Или Вы им не сообщаете о том, что движок ворованный/нуленный?
    либо opensource. Так что в моем случае проще написать свою CMS, когда нет возможности взять подходящую бесплатно
    Любой популярный opensource на голову перекроет самописку, тем более — из одного человека.

    ОтветитьОтветить
  139. @Yaroslav.CH: Заказчикам по барабану, чем я пользуюсь, им главное результат (готовый сайт, отвечающий всем требованиям). В случае, когда я использовал ворованный движок, я сообщил об этом заказчику и тот предпочел, чтобы я делал на нем, вместо того, чтобы купить лицензионный.
    Я не горжусь тем, что не плачу за софт, просто говорю, как факт. Если заказчик хочет, чтобы его сайт был на лицензионном решении, пусть покупает лицензию, я буду писать на ней.
    Готовые opensourse решения не всегда лучше для решения конкретных задач с точки зрения разработчика. Например нет решения для интернет-магазина, либо оно не устраивает и хочется другого, а другого нет. Или хочется ввести какую-нибудь фишку, а возможности системы не позволяют. Или большие сложности с освоением и разработкой из-за недостаточно подробной документации и поддержки и сети.
    Понятное дело, что в любом случае можно найти что-нибудь более-менее устраивающее, но у меня нет ни времени, ни желания на это. Потому что в таком случае я не не успею доделать диплом и не сделаю сайт заказчику в срок.

    ОтветитьОтветить
  140. @pen:
    Заказчикам по барабану, чем я пользуюсь, им главное результат (готовый сайт, отвечающий всем требованиям).
    Да-да, я знаю таких заказчиков, которые потом получают «письма счастья» от владельцев движка, бан от хостера и отсутствие выбора нормальных разработчиков — потому как никто не хочет браться за нуленное. Сталкивался лично и не единожды. Впрочем, я не порицаю — у каждого свой путь.

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

    Готовые opensourse решения не всегда лучше для решения конкретных задач с точки зрения разработчика.
    Да, поэтому для сложных проектов берутся CMF. А для простых — как показала практика, таких ситуаций одна на миллион. Но это при условии, что мы говорим именно о разработчике.

    Или хочется ввести какую-нибудь фишку, а возможности системы не позволяют.
    Что значит — «не позволяют возможности системы»? В смысле — нет готового плагина/решения, позволяющего более-менее «на колене» собрать сайт?

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

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

    ОтветитьОтветить
  141. Тут можно много трепать языком как в положительную сторону так и в отрицательную! Делаем простой тест! Вбиваем в поисковик к примеру три разных запроса: Авторынок, Недвижимость и Бесплатная доска объявлений. Берем пять первых (исключая платные рекламные ссылки). Проверяем на платформу. О боже! Не определяет! Там нет ни Вордпресс, ни Джумла.

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

    ОтветитьОтветить
  142. @Андрей: учимся читать статьи целиком — не только заголовки:
    Под понятием «самописная CMS» подразумевается массовый продукт. Уникальные разработки, предназначенные для решения «одноразовых» нестандартных задач — в этой статье не рассматриваются.

    ОтветитьОтветить
  143. @Yaroslav.CH:
    Я случайно забрел на данный сайт и меня заинтересовало 12 причин. Прочитал коменты.
    Сугубо лично мое мнение (на примере одного комментария)!
    Цитата из комента: «Приведу живой пример на себе: я не являюсь программистом, но примерно осенью 2003 года захотел сделать свою интернет-страничку. В которой хочу публиковать фотографии и небольшие рассказики, плюс дать возможность посетителям оставлять комментарии (ничего не напоминает? :-) ).»
    Видно у человека полно времени и ему совсем не чем заняться! Ни когда ни понимал как можно торчать 24часа в Однокласниках, выставлять фото своей кошечки и ждать позитивных ответов. При этом личное фото пользователя с трудом вмещается 19-ти дюймовый монитор из-за лишнего веса. Лучше бы он или она пошла в спортзал и потратила(л) три часа на спорт.
    А теперь по теме! Если делать не х… , берем любую бесплатную CMS и шлепаем там фотки своей кошечки и ждем комментариев. Если вы решили зарабатывать на интернет – ресурсе или за счет него, заказываем «гавно самописный движок» и вкладываем приличную сумму денег.

    ОтветитьОтветить
  144. Болшенство сайтов парталов,больших блогов . интернет магазинов написаны на Рукописных CMS, Серёзные проэкты руками, осnальные на CMS, если нагрузить WP он будет медленно работать, а Drupal только на выделенном сервере

    ОтветитьОтветить
  145. с 2006 года пишет на самописке — ни одного взлома за 11 лет!!!
    с тем-де WP — взломы один за другим… задолбплись уже перезаливать бэкапы.
    И самописка-самописке — огромная разница! У нас в студии самописка заточена под решение нестандартных задач, а у нас таковых 90%. Переделывать чей-то код под нестандарт сложнее, чем с нуля написать его самому.
    + за эти 11 лет накопилась база огромная для разнообразных нестандартных задач.
    даже аддаптивный дизайн на нашей самописке нам теперь удобнее делать, чем на том-же bootstrap’e
    * пробовали многие популярные CMS, но всё это «не то пальто».

    ОтветитьОтветить
  146. с тем-де WP — взломы один за другим… задолбплись уже перезаливать бэкапы.

    Ну если вы решаете проблему со взломами — перезаливкой бекапов… :)

    У нас в студии самописка заточена под решение нестандартных задач, а у нас таковых 90%.

    Дисклеймер в самом начале статьи как раз и предназначен для таких случаев.

    ОтветитьОтветить
  147. А я категорически не согласен со статьей!

    Автор, вот глянь на те же украинские проекты: Розетка, Хотлайн, ПромЮа, ОлИкс, Приват24 и бывший ЭксЮа.

    Все эти проекты приносят(-ли) огромную прибыль, имеют хорошее API, высокий уровень безопастности и очень популярны спустя время своей работы.

    А ведь они были написаны с нуля и не на CMS!

    ОтветитьОтветить
  148. @N1site:

    Автор, вот глянь на те же украинские проекты:

    Вот для кого дисклеймер в начале статьи написан? :) «Под понятием «самописная CMS» подразумевается массовый продукт». Много известно магазинов на базе CMS, на которой работает Розетка? Хотя бы пару тысяч наберется? ;) Ну тогда о какой «массовости» может идти речь? Это индивидуальные продукты, написанные под индивидуальные решения.

    имеют хорошее API

    API к CMS не имеет никакого отношения.

    высокий уровень безопастности

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

    очень популярны спустя время своей работы

    А где взаимосвязь между популярностью магазина/сервиса и CMS, на которой он работает?

    ОтветитьОтветить
  149. Великолепная статья! Но мне она принесла скорее боль. Потому что читая ее, я на каждом следующем пункте вздрагивал как от удара плети по плечам. Настолько точно все описано. Сам я полный дилетант и профан, но как раз пытаюсь (или уже пытался) сделать полностью собственную CMS. Надеясь если и не мир улучшить, то уже самую лучшую систему управления создать — это план минимум. Ну а если серьезно, то было моей мечтой сделать надежную, шуструю, и предельно простую в управлении систему. Совершенно без ошибок валидации, интуитивно понятную для обычного человека (и действительно как точно подмечено в статье совершенно бесплатную… пока), а там было бы видно. Но Вы, Ярослав, все мои планы как-то разом, если и не разрушили совсем, то покачнули весьма основательно. Конечно нечто подобное у меня в сознании смутно мелькало… Но теперь и не знаю стоит ли продолжать свою работу по созданию собственной самописной системы управления. Времени, сил, трудов затрачено очень много. Обидно-то как. Но ведь в Вашей статье описано все абсолютно точно, как будто сквозь меня прямо в душу в сознание заглянули. Сам то я такие мысли не осознано отгонял дабы не мешались, но теперь, что делать-то?

    ОтветитьОтветить
  150. @Сергей: на мой взгляд, свою систему стоит писать только в двух случаях: первый — как личный проект, позволяющий себе развиваться. У многих не получается учиться «по книгам» — нужна какая-то реальная точка приложения усилий. И такой точкой может стать и своя CMS. Но для этого нужно быть хорошо подкованным в теории. И второе — это если практический опыт в кодинге, UI/UX уже действительно настолько велик, что позволяет рассмотреть и исправить в своей системе те ошибки, которые есть в популярных CMS. И плюс — знание, понимание и разработка каких-то фишек, которые смогут выделить новую систему. В остальных случаях, как мне кажется, такая разработка будет просто тратой времени.

    ОтветитьОтветить

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *


Срок проверки reCAPTCHA истек. Перезагрузите страницу.