Современная альтернатива Wordpress. Интервью с разработчиком MaxSite CMS
Сегодня гостем моего блога стал Максим - разработчик классной альтернативы wordpress под названием MaxSite CMS. Проект развивается несколько лет и за эти года успел обрасти всеми необходимыми инструментами для профессионального ведения блога. Если вы не слышали ни разу про MaxSite CMS, то скорей всего просто не интересовались. Например, мой блог уже год работает на этом движке и я рад, что отдал предпочтение именной этой системе.
Мне давно хотелось задать несколько вопросов автору проекта и вот представился шанс. Огромное спасибо Максиму за развернутые ответы!
Игорь Антонов: Максим, не буду скрывать, это самое «долгоиграющее» у меня интервью. Постоянно хочу с вами поговорить, но различные обстоятельства этому мешают. Уже даже начинаю подозревать мистические силы.
Максим, первым делом хотел бы тебя поприветствовать и выразить благодарность за согласие на интервью, а также за замечательный проект “MaxSite CMS”. Надеюсь, он будет постоянно развиваться и потеснит популярность WordPress.
Максим: Спасибо, Игорь! Буду рад ответить на вопросы. :)
Игорь Антонов: Максим, проект развивается не первый год. Расскажи, как все начиналось. Что послужило отправной точкой к столь амбициозному и напрямую не приносящему финансовой выгоды проекту?
Максим: Ну да, денег MaxSite CMS не приносит. :) С чего начиналось... Наверное из-за плохой кармы WordPress — там постоянные скандалы, дрязги. Поэтому ушёл из русского WordPress и ради спортивного интереса решил попробовать сделать похожую по функционалу CMS.
WordPress очень старый «движок», с гигантским количеством «быдло-кода» и устаревшей архитектурой. Стоит ли говорить, что даже текущая 4-я версия базируется на коде 1.5, вышедшего в 2005 году. То есть я пробовал сделать примерно такой же функционал, только уже по нормальному. За несколько месяцев это и вылилось в MaxSite CMS.
Игорь Антонов: О! Расскажи подробней про "русский Wordpress". Это сообщество, специализирующееся на переводах? Или речь идет о подготовке полноценных сборок с каким-то особенным функционалом?
Максим: Там был и русский перевод, и адаптация под наши условия. WordPress — чисто англоязычная система, никто из его разработчиков не задумывался, что будут пользователи другого языка. Это сейчас UTF8 повсеместно, а раньше все сидели на своей кодировке. Всё это приводило к совершенно чудовищным вещам: текст в юникоде, а база работала в win1251. Файлы тоже «гуляли» как хотели. В Автоматик этими вопросами вообще не озадачивались. Им была интересна только админка. Код WordPress ужасный, он где-то уровня 2001 года, когда ещё назывался B2. На тот момент это было действительно круто и ново, но за столько лет они принципиально ничего не изменили, только ухудшили. И с проблемами приходилось сталкиваться постоянно.
Механизм перевода WordPress реализован очень плохо и сильно грузит сервер — для каждого посетителя подгружается большой файл, который ещё и нужно обработать и найти переводимую фразу. Я тогда выпускал свои версии, где русский перевод был сделан прямо в файлах. С БД сделал механизм с конвертацией кодировки «на лету». А потом придумал как разделить перевод на две части: lite и full и мы смогли полноценно использовать «родной» механизм перевода WordPress и не создавать повышенную нагрузку. Сейчас эту идею и код своровали и выложили на офсайте WordPress под другим авторством. :-) Ну а когда Автоматик наконец-то озадачился различными локализациями, то русскую группу отдали человеку, который вообще никогда не участвовал в реальной русской поддержке. Он просто своровал перевод Ивана Калинина (http://lecactus.ru/) и выдал за свой... Про тот период даже не хочется вспоминать. Я сделал свою последнюю сборку 2.3.3 и на этом с WordPress больше не работаю. Не хочу портить карму. :-)
Игорь Антонов: Это твой первый подобный проект? Или попытки создать собственную систему управления контентом уже были?
Максим: Системы были. Первая CMS была написана в 2001 году как тестовый вариант проверки себя — «смогу ли?». Тогда даже хостинги с MySQL были экзотикой. Помню, ещё делал свой форум. Довольно интересный: там сообщения выводились не все списком, как сейчас принято, а иерархически (родитель - потомок).
Поскольку доступа на моем бесплатном хостинге к базе не было, данные хранились в отдельном текстовом файле. Когда он увеличился до 500Кб, хостер сжалился и выделил мне бесплатный доступ к MySQL. Пришлось срочно переписывать часть ядра форума. Была даже такая экзотическая система, через которую отправлялись СМС родителям школьников-двоечников. :-) Но, конечно MaxSite CMS в этом плане всех их превосходит по сложности.
Игорь Антонов: А что стало с проектом форум в итоге? Забросил? Подобный плагин не помешал бы для MaxSite CMS. Может я преувеличиваю, но сейчас с форумами вообще беда. В живых осталась только часть старых проектов, а вот новеньких не видать на горизонте. А ведь развиваться есть куда!
Максим: Тот форум морально устарел. :) Главная проблема с форумами — сложная система управления пользователями и группами. Там же всё на модерацию завязано. Сделать вывод сообщений не проблема. Проблема всем этим управлять: одним можно одно, другим — другое.
Игорь Антонов: MaxSite CMS создан на базе когда-то сильно популярного фреймворка CodeIgniter. Можешь рассказать о причинах выбора и как смотришь на нынешнюю заброшенность этого проекта (CodeIgniter)? Не возникало желания перенести на что-то более современное? Не мешает ли старый «каркас» развитию продукта?
Максим: Чего такого не хватает в CodeIgniter, что его нужно менять? Ведь CodeIgniter тем и хорош, что не создает искусственных рамок. Может быть CodeIgniter и не настолько функционален, как некоторые другие фреймворки, но если взять основные потребности разработчиков, то получится, ну пусть с десяток основных модулей. Основная потребность в любой CMS — это база данных. ActiveRecord в CodeIgniter реализован на очень хорошем уровне. Остальные модули принципиально ничем не отличаются от других фреймворков.
Возьмем для примера расспиаренный Yii. В CodeIgniter (v.2.2.1) всего 147 php-файлов. Суммарный объем фреймворка 1,3Мб. В Yii (v.1.1.16) размер 25Мб, а php-файлов более 1700. Файловая структура Yii вообще не поддаётся пониманию, а в CodeIgniter «примитивные» libraries, helpers, database. Понять как работает CodeIgniter тысячекратно проще, чем Yii и настолько же проще его использовать в рабочем проекте.
Я не против новых фреймворков, как раз наоборот: чем больше, тем лучше, но не нужно стрелять из пушки по воробьям.
Игорь Антонов: Иногда складывается впечатление, что фреймворки пытаются повторить судьбу коробочных систем. Это уже не просто набор функций, а настоящие монстры на все случаи жизни. С одной стороны это хорошо, но с другой: "На фига куча лишнего барахла в проекте?". Как считаешь, несут ли современные фреймфорки проблемы? Ведь многие начинающие разработчики даже не пытаются понять теорию, а сразу юзают фреймворки. Не задумываются как оно все работает изнутри.
Максим: Конечно несут проблемы. Особенно, если учитывать развитие фреймворка. Пока освоишь одну версию, выйдет другая, а там всё уже по-другому. Мне иногда кажется, что разработчики многих фреймворков чистые теоретики, не занимающиеся реальным созданием сайтов. Ну взять тот же Yii — он вообще был изначально попыткой перенести какой-то там фреймворк ASP.NET под PHP. То есть это вообще непонятно откуда идущие корни. Сравним с CodeIgniter — это ядро ExpressionEngine. То есть люди делали CMS, на ней рабочие сайты, ядро и вылилось в CodeIgniter. С ним работать гораздо удобней, даже если у него «какой-то неконцептуальный» MVC, singleton и он не использует синтаксис PHP 5.5. :-)
Кстати, проблемы не только с PHP-фреймворками.
Игорь Антонов: А если по подробней? О каких проблемах идет речь?
Максим: Для примера. Недавно обнаружил, что популярный Bootsrap не позволяет нормально работать с единицами REM. Там забавная вещь получается: для тэга HTML установлен один размер шрифта (непонятно зачем), а базовый размер (который можно изменить в less-переменной) указывается для BODY (это уже правильно). Теперь хоть тресни, но работать с REM не получается: он должен считаться от базового размера (который устанавливается только для BODY), а не от абстрактного размера в HTML.
Я написал на гитхабе, но ответ простой — Bootsrap v.3 REM не поддерживает. Это говорит о том, что тот говно-код, который там накопился, уже лезет наружу. И если они его подчистят (я надеюсь), то 4-я версия гарантированно не будет совместима с предыдущими. Зря получается изучали. А если не подправят, то пойдет новомодная волна, дескать REM это ерунда и они не нужны. Хотя это просто ребята накосячили. :-)
Изучать, конечно же, нужно основы. Они не меняются и всегда работают.
Игорь Антонов: Максим, поделись опытом создания и удержания людей в сообществе. Вокруг твоего проекта «тусит» много народа, как получается удержать аудиторию, и приносит ли сообщество помощь в виде кода (например, модули, темы оформления и т.д.), баг репортов и т.д.?
Максим: Да собственно делиться нечем. Я не знаю сколько реально людей работают с системой. Постоянно я контактирую с Юрой (Cuprum) и в последнее время с Ильёй Земсковым, который присылает разные исправления. Илья, кстати, ведёт MaxHub — там много интересного публикуется. Но вообще код и пожелания разные люди присылают постоянно.
Игорь Антонов: Ваш проект хостится на GitHub’е, пул-реквесты принимаются от всех желающих? Максим, не рассматривался вариант создания полноценной команды разработчиков? Так и система быстрей развивалась и себе время смог бы высвободить.
Максим: Чтобы полноценно «вытянуть» MaxSite CMS до «суперовского» уровня, где будут подтянуты все «хвосты», реализован полноценный дизайн и админ-панель требуются деньги и время. Невозможно сделать по другому, потому-то такие вещи полноценно реализуются только в команде на постоянной основе (фактически нужно платить зарплату). Если делать разово и по желанию, то получается хоть и бесплатно, но сильно уж в разнобой. Я с этим уже несколько раз сталкивался. Например присылает человек готовый код. Потратил кучу времени и вроде работает, но архитектурно выполнено неверно, где не учтены многие факторы, начиная от точки подключения, до игнорирования фильтрации данных.
Поэтому сейчас MaxSite CMS развивается по мере возможностей.
Принципиально я принял решение, что вся разработка пойдет на GitHub’е. Это Issuses в первую очередь. Что касается Pull requests, то их можно отправлять, но я их принимать буду только через свои правки. То есть я вручную скачаю измененный файл, посмотрю разницу, проверю сам код, проверю как он работает на сервере и только после этого отправлю в репозиторий. Я привык проверять полностью весь код.
Игорь Антонов: Не могу не спросить о тестировании. Как тестируешь код? По старинке или примкнул к новомодному течению любителей unit-тестов? Сегодня их пиарят везде и порицают тех, кто их не использует.
Максим: Никакие unit-тесты не использую. Для отладки php-кода в основном применяю свою функцию pr(). Это «умная» оболочка для стандартной print_r(). Через неё видно всё что нужно. Если нужно прерывание по die(), то использую _pr(). Вот и все секреты. Используется в любом месте с любыми переменными.
Игорь Антонов: Может вопрос немного странный (обычно все требуют халявы), но не возникала ли идея перевести движок на коммерческие рельсы? За доступную цену продукт однозначно покупали бы, а небольшое вознаграждение для такого проекта – сильный мотиватор для развития.
Максим: Никогда об этом не думал. Даже не знаю, что сказать. :)
Игорь Антонов: Не подумай, что навязываю идеи, но почему бы не сделать платный репозиторий тем оформления? Всегда есть люди, которым просто нужен блог. Им не хочется вдаваться в нюансы программирования и верстки. Почему бы таким не предлагать готовые премиум шаблоны? Насколько мне известно, сейчас доступны только бесплатные шаблоны и то, пока их не сильно много.
Максим: Тут сложность в том, что невозможно охватить все запросы клиентов. На том же http://themeforest.net/ их 18 тысяч на любой вкус. Цены более чем демократические — 5-60$. Угадать вкус клиента невозможно. Ну нравится ему сочетание коричневого и зелёного — что тут поделаешь? Я не думаю, что какой-то платный каталог шаблонов будет вообще востребован. Как показывает опыт, платят те клиенты, которым нужны какие-то особые возможности от сайта. Вебмастеру проще выставить ценник на верстку в 20$ и сделать шаблон по готовому дизайну, чем делать его заранее, не зная угадает ли он потребность гипотетического клиента.
Игорь Антонов: Немного отойдем в сторону от MaxSite CMS и поговорим о глобальных вопросах. Максим, отрасль web-разработки постоянно развивается и сегодня успешный web-разработчик != такому же 10 лет назад. Посоветуй оптимальный путь восхождения на олимп web-мастерства. На какие технологии стоит обратить внимание? Стоит ли вообще пытаться стать универсалом (верстка, back-end, front-end)?
Максим: Все этапы, возникающие в процессе создания сайта, нужно хорошо понимать. То есть php-программист должен уметь открывать фотошоп и поправить какие-то детали. Или верстальщику нужно понимать php-код в шаблоне. Другое дело, что постепенно происходит специализация на программистов, верстальщиков и дизайнеров.
В мировом тренде web-разработки сейчас происходят очень интересные вещи. Рунет традиционно будет спать ещё года два, но кто думает о будущем нужно уже сейчас ориентироваться на западных разработчиков. Общий тренд — быстрая разработка. За последник два года произошёл прорыв в двух направлениях.
В первую очередь — это отказ от старых браузеров. Доля IE снижается и сейчас стандарт это поддержка IE10+.
Второй прорыв — новое понимание что такое сайт. Если есть какой-то товар или услуга, то раньше ставилась CMS, генерировалась куча страниц более-менее по тематике, всё это превращалось в типовой блог с жуткой навигацией. Теперь же — делаем единственную страницу landing page. Происходит переход от многотематического сайта/блога к отдельным «точечным» проектам.
Как следствие происходит рост популярности css-фреймворков и одиночных html-страниц. По статистике того же themeforest количество WordPress-шаблонов уже меньше, чем простых html-страниц.
Само по себе ускорение разработки происходит за счёт нескольких вещей.
Постепенно наметился тренд переноса верстки на уровень html-кода с использованием готовых css-классов. Это тоже сильно упрощает разработку сайтов.
Игорь Антонов: Максим, не могу не спросить о твоем рабочем окружении. Какую ОС используешь для разработки, твоя любимая IDE и как относишься к продуктам от компании JetBrains (например, phpStorm).
Максим: У меня Windows 7. Особых попыток перейти на линукс не было, хотя на втором компе стоит Linux Mint. Windows особых проблем не доставляет, но от перехода на Линукс удерживает отстутствие фотошопа, fireworks и webmoney-кипер. Ну и плюс раздражает в линуксе требование постоянно вводить рутовский пароль по любому чиху. Дабы не разводить холивар, сразу скажу, что останусь на винде, поскольку она меня устраивает по всем параметрам. :)
В работе я использую Notepad++. Пробовал разные IDE, но как-то с ними не сложилось. В основном работа с отдельными файлами и постоянно прыгаешь по каталогам. Мне удобней открыть файл, посмотреть, внести правку и закрыть. Когда один-два проекта, то можно в IDE их «оформить», а когда одновременно работаешь с десятком, то Total Commander более оптимальное решение. :-)
Игорь Антонов: Как ты относишься к другим CMS? Можешь назвать свои любимые CMS и чем именно они заслужили оказаться в списке твоих фаворитов?
Максим: С техническим интересом и не более того. Работаю только с MaxSite CMS и LPF. Некоторые клиенты ещё «сидят» на WordPress, приходится и с ним возиться. У других CMS смотрю только код. Если там «бардак», то даже не ставлю. По большому счёту все CMS различаются только админкой. Хорошую админку сделать сложно (много тонких нюансов), поэтому с WordPress никто и не может конкурировать.
Игорь Антонов: Максим, долгое время php считался стандартом для разработки web-приложений. Сейчас ситуация меняется и теперь на back-end’е все чаще встречаются экзотичные для этого вещи – python, JavaScript. Что ты думаешь по этому поводу? На твой взгляд, сможет ли тот же JavaScript вытеснить php?
Максим: Есть модные штучки, а есть проверенные временем решения. Что-то я сомневаюсь, что PHP может хоть кто-то потеснить. Хотя, я думаю, что PHP, начиная с будущей 7-й версии, будет уже не тем PHP, который мы знаем. Отсутствие совместимости уже на уровне 5.3 делает сложным поддержку проектов. Когда выйдет семёрка, боюсь совместимости вообще не останется. Тогда, действительно, будет проще перейти на питон, чем ожидать очередной «пакости» от разработчиков PHP. :)
Игорь Антонов: Если бы тебе сегодня задали вопрос: «Какой язык программирования стоит выучить?»
Максим: Если с перспективой найти хорошую работу, то однозначно Java. Если для веб-программирования, то PHP и JavaScript. Если для десктопов, то даже не знаю... Я «застрял» на Delphi 7, хотя начинал с МК61 и Фокала на БК-0010. Может сейчас что и изменилось, но после Turbo Vision и Borland Pascal for Windows, переход на Delphi был настоящей революцией. А как-то поставил Microsoft Visual Studio и понял, что нужно было полноценно изучать С++. :)
Игорь Антонов: В свое время беседовал с руководителями компаний «1С-Битрикс», «NetCat». Все их проекты начинались с банальных web-студий. Делали сайты и разрабатывали собственную CMS. Максим, на твой взгляд, сегодня реально создать новую CMS, влезть с ней на рынок и успешно продавать? Не было желания сфокусироваться в этом направлении?
Максим: Наверное реально, если у компании есть достаточные ресурсы, чтобы потратиться на разработку. Так с ходу никто полноценную CMS не напишет. Тут играет временной фактор. Если бы я знал, что lessphp перестанет развиваться, включал бы я его в комплект? Или использование reset.css вместо normalize.css (хотя его тогда еще не было)? То есть CMS не достаточно только сделать — нужно еще с ней поработать на реальных сайтах с реальными клиентами.
Изначально невозможно предусмотреть всё, поэтому через какое-то время придется или лепить «костыли» или выпускать версию без обратной совместимости. То есть CMS можно сделать, через год раскрутить, еще через год понять, что её нужно переделывать, еще год потратить на переделку, всё это еще раз попиарить и втюхивать доверчивым клиентам, чтобы хоть как-то окупить зарплату програмистам. :-)
Игорь Антонов: Максим, а помимо MaxSite CMS ты работаешь над какими-нибудь другими проектами? Под проектами подразумеваю решения для разработчиков, а не для заказчиков?
Максим: Да, помимо MaxSite CMS активно работаю над собственным less/css фреймворком UniCSS (http://unicss.maxsite.com.ua/) и Landing Page Framework (http://lpf.maxsite.com.ua/). Уверен тебя интересуют подробности, начну с UniCSS.
Начальная идея фреймворка — придумать систему именования css-классов. При верстке всегда приходится создавать массу «технических» блоков (DIV, SPAN), которые содержат 1-2 правила, но при этом имя класса нужно делать уникальным. Давно существуют css-хелперы (предопределенные классы), вроде .clearfix или .bold, но какой-то универсальной системы нет.
Тогда я и решил придумать систему именований, которую можно применить на любом сайте и которая не требует затрат на изучение. Классы UniCSS семантичны и строятся по единым правилам. То есть достаточно один раз посмотреть на префиксы и сразу понятно, за что отвечает какой класс. Например .bor — это border, .mar — margin , .pad — padding и т.п. Чтобы узнать какие именно классы нужны при верстке, я верстал страницы с inline-style. И тогда каждое правило вылилось в отдельный класс. Так получилось наполнить фреймворк конкретным содержимым.
Игорь Антонов: Получается, UniCSS - это полноценный CSS-фрейворк вроде Bootstrap?
Максим: UniCSS использует туже идеологию, что и все современные css-фреймворки: перенос вёрстки на уровень html-кода. Такой подход позволяет значительно ускорить работу и оставить в css-файле только те классы, которые уникальны для страницы или шаблона. Поскольку имена унифицированы и семантичны, то нет сложности ни с использованием, ни с редактированием, ни с дальнейшей поддержкой.
Поскольку UniCSS, хоть и предоставляет в распоряжение вебмастера готовый базовый набор классов с типографикой, grid-сеткой, иконками и т.д., но его также можно использовать по раздельным файлам-хелперам. Строго говоря, можно вообще сделать свою реализацию классов, главное сохранять унификацию и правила именования. Если все перейдут на UniCSS, то наступит эра вебмастерского счастья. :-)
Игорь Антонов: "Наступит эра вебмастерского счастья" - звучит заманчиво. Хочется верить, что проект найдет своих пользователей. Я лично обязательно попробую его в деле. Максим, ну а теперь хотелось бы услышать про LPF. Что это за зверь такой?
Максим: LPF я написал из-за лени. В общем классический для программиста вариант. :-) Очень много вещей можно автоматизировать и LPF как раз и упрощает создание и поддержку страниц. Например автоподключение файлов избавляет вебмастера от кучи «обезьяньей» работы. Фреймворк настолько гибкий и легко управляемый, что на нем можно сделать абсолютно любые вебсайты. Если бы я решил делать новую CMS, то за основу однозначно брал бы Landing Page Framework. :-)
К особенностям LPF я бы отнёс возможность его настройки через отдельные опции. Фактически там можно поменять всё, начиная от расположения файлов, до less-компилятора и генератора статичных страниц. LPF использует кэширование так, что с его производительностью может сравниться разве что обычный html-файл. Скорость просто реактивная при мизернейшем потреблении памяти сервера.
Игорь Антонов: А с MaxSite CMS он как-то связан? Или LPF уже часть проекта MaxSite CMS?
Максим: В какой-то мере Landing Page Framework является и тестовой рабочей площадкой для новых возможностей MaxSite CMS.
Игорь Антонов: Столько всего интересного рассказал, что не верится как этим всем успевает тянуть один человек. UniCSS, LPF - безусловно интересные проекты, но какие планы по развитию MaxSite CMS? Обновлений не было давненько, чего ожидать в ближайшем будем?
Максим: Сейчас вся разработка MaxSite CMS перенесена на GitHub. Ветка dev — это будущая версия. Её, конечно, не стоит ставить на рабочие сайты. Принципиально было решено, что все накопленные «хвосты» будут подчищены. Поэтому для перехода на новую версию придется переделывать шаблон в части подключаемых файлов. Это нужно будет скопировать в свой шаблон общие (shared) стили, функции и т.п.
Зато такой подход, позволяет создавать шаблоны, без привязки к «особенностям» системы. Кроме того, появятся новые возможности по кастомизации сложных программных участков, которые раньше были жестко завязаны на систему, например форма авторизации, регистрации, поиска. Раньше приходилось подстраиваться под предопределенные классы и html-структуру, теперь это можно будет делать произвольно. Много изменений произошло с модульной сеткой (main). В main-файле был довольно сложный php-код, который отпугивал вебмастеров, поэтому все старались использовать default-вариант. Теперь же в main-файле оставлена по сути только html-разметка, которую гораздо проще поменять и настроить под себя.
Концепция default-шаблона полностью меняется. Раньше это был универсальный шаблон-каркас. Теперь это уходит в прошлое. Default будет обычным рядовым шаблоном, рассчитанным на типовой блог. В планах сделать и другие шаблоны под типовые задачи. Пока думаю о фотоблоге и landing page.
Игорь Антонов: Т.е. большая часть изменений коснется пересмотра механизма создания шаблонов?
Максим: Глобальная задача — сделать так, чтобы на MaxSite CMS можно было перенести любой html-шаблон. В идеале это будет примерно так: взяли готовый html-шаблон, скопировали его файлы (css, js, изображения и т.п.), разметили main-структуру (где выводится контент, сайдбар, подвал, шапка), если нужно вынесли компоненты шапки и подвала отдельно. При необходимости отдельными файлами формируем формы и какие-то плагины.
Таково сейчас общее направление развития MaxSite CMS.
Игорь Антонов: В заключении, хотел попросить дать совет читателям и порекомендовать несколько книг, которые оказали на тебя влияние.
Максим: Если вы хотите стать хорошим веб-разработчиком, то лучший путь — придумать свой проект и попытаться сделать его собственноручно. Нужно постоянно изучать чужие разработки и черпать из них идеи для своего вдохновения.
