Блог

CMS: какую выбрать для студии и почему?

Добрый день, меня зовут Марат, я руководитель одной из казанских студий, которая использует в быту Yupe CMS.

Сегодня я посчитал количество реализованных проектов на Yupe CMS и выяснилось, что за два года работы мы реализовали около 60 проектов.

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

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

Первые сайты. Практика на Joomla и Wordpess

Был год 2006-2008. Мы как и многие в вебе свой путь начали с этих движков. Нас привлекало наличие на тот момент неплохих готовых модулей и шаблонов. На тот момент мы не были очень умными, мы были студентами, нам хотелось быстро сделать и получить пару тысяч за свою работу. На этом и жили.

Плюсы Joomla и Wordpress

  • Бесплатность. Для нас было важно, чтобы движок был бесплатный, и было большое количество бесплатных решений.
  • Гибкость. На тот момент мы понимали это как "большое количество плагинов и модулей".
  • Низкий порог вхождения. Также немаловажная часть была - возможность, не обладая большим умом, что то быстро исправить или наделать

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

Минусы Joomla и Wordpress

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

К этому времени появились существенные проблемы

  • Дырявость - Так уж сложился open source, за качеством кода особо не следили, в том числе архитектура позволяла развлекаться с кишками Джумлы и Вордпреса, как захочется. Этому также способствовали различные настройки хостингов. Каждый хостинг настраивался по своим правилам, какие то куски сайтов не работали, требовались дополнительные усилия;
  • Скорость работы сайта - Данные движки все больше и больше обрастали различным мусором, странными плагинами, и скорость работы сайтов была просто ужасной. Популярные плагины были дырявые. Очень много времени уходило на саппорт;
  • Сложность разработки - т.к. уровень написания кода, стилистика была разной, настраивать и перепиливать модули было сложно, возникали конфликты различных частей сайта.

К этому времени мы уже немного научились программировать, и понимали что данные системы нас не устраивают. Был примерно 2008й год, первая половина.

Как мы делали свой движок.

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

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

Работа модулей была построена на концепции MVC (узнали только потом, когда терминология начала появляться в ИТ сфере простых смертных в году 2010-2011м).

Шаблонизатор был smarty. Почему? Он был молод и пафосен) Был конструктор форм, и первобытный роутинг. Кусок движка, отвечающий за формы мы стабильно переписывали раз в полгода.

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

Попытки поработать с UMI.CMS

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

Знакомство с Фреймворками

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

Так сложилось, но в среде стартапов стали популярны фреймворки, при этом мы плотно работали с ребятами, умеющих работать с Ruby on Rails(ээй ребята, где вы сейчас??)

Узнав слово волшебное "фреймворк", мы начали интересоваться этой темой. К этому времени мы даже написали несколько CRM систем на нашем движке, но тема фреймворков нас сильно завлекала, мы потыкались в рельсы - не очень зашло - разрабатывается быстро, сапортится больно, потыкались в YII и в Laravel.

В году 2013м - 2014м , нам необходимо было реализовать внутреннюю CRM для федеральной компании. Работать с нашей CMS (хз на самом деле что за монстр на тот момент это был) мы уже не хотели, вкус правильных фреймворков уже прочувствовали. Выбирали из чего делать YII или Laravel. И выбрали конечно же Laravel =). По очень простой причине, в yii мы не смогли разобраться с разделением доступов, а может просто не захотели.

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

Что выбрать: October CMS или Yupe CMS?

Вроде был конец 2014го.

Прохавав опыта с CRMками разными мы решили не заниматься больше CRM системами.

Нам очень нравились фреймворки, кроме руби ^_^. Мы продолжили заниматься созданием сайтов. Свой движок мы использовали на "быстросайтах" сайты которые можно реализовать за пару дней, но серьезные проекты мы не хотели делать на самописке. После изучения интернетов, пришли к выводу что плотненько можно поработать с October CMS и Yupe CMS. Изначально мы хотели использовать Октобер, нас зацепил офф сайт с модным дизайном.

Плюсы October CMS

  • Он работает на laravel, а это модно, стильно молодежно;
  • Хороший уровень кода;
  • Ну и все что наследуется из laravel.

Чем нам не понравился October CMS

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

Плюсы Yupe CMS

  • Нам понравилась логика CMS - логичное устройство модулей, вьюх;
  • Адекватно настраиваемый роутинг;
  • Наличие живого форума, где можно было задать тупой вопрос и получить адекватный ответ от тех же Андрея Опейкина или Олега Филлимонова;
  • Большое количество, по сравнению с October CMS модулей;
  • Логика CMS очень хорошо читаема;
  • Документация от yii прекрасно подходит для Yupe CMS.

Минусы Yupe CMS

Да, даже в юпи тоже есть минусы =)

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

На самом деле получилось не совсем то, о чем хотелось написать) Изначально хотелось похвастаться 60+ проектами на Yupe CMS, а получилась история прихода к Yupe CMS. В данном посте я обозначил именно ключевые вехи. Сравнивать в формате "ой там есть такой модуль, а там такой" - тоже достаточно бесполезно, имхо - нет модуля - напиши.

Понятное дело, в процессе работы приходилось работать и с modX, и OpenCart, и Bitrix, но по тем или иным причинам мы либо писали на своем движке, либо на Yupe CMS.

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