Велосипед-CMS. Как я увлекательно провел шесть дней из-за комментария на Хабре



    Эта история началась с комментария к моей статье на Хабре. Точнее, с части этого комментария:

    «Попробуйте постройте приложение уровня и функционала WordPress — и оно точно так же будет задыхаться от наплыва пользователей»

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

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

    Вот так сошлись звезды. А результаты этого моего эксперимента — в статье.



    Расстановка акцентов


    Почему CMS. Потому, что CMS — это одна из первых вещей, которые встречает начинающий сайтостроитель, сразу после того, как изучает основы HTML, CSS и JS. А иногда даже до. Во-вторых, потому, что все, кто имеет дело с CMS достаточно регулярно, получают объективный или субъективный повод их ненавидеть. И у многих из них рождается мысль, что он мог бы сделать лучше. Это как детская мечта «вырасту и стану пожарным». Я к таким вещам отношусь довольно трепетно.

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

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

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

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

    Маленькое лирическое отступление


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

    Размышления


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

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

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

    Простота и интуитивность для конечного пользователя. Некоторое время назад я провел небольшой эксперимент. Группе из шести человек я предложил попробовать себя в роли контент-менеджера двух сайтов: интернет-магазина на базе «Битрикс» и блога на WordPress. В группе были довольно разные люди: моя мама, геолог, танцовщица, гитарный мастер, журналист и таксист. Каждому было предложено простое задание: добавить товар в интернет-магазине и статью в блоге. Сначала это нужно было попытаться сделать самостоятельно (после краткого общего инструктажа), а потом — по подробной инструкции. Результат был такой: самостоятельно абсолютно правильный результат достичь не смог никто; с инструкцией ошибок стало меньше, но они все равно были. В плане «дружественности» с точки зрения группы победил WordPress. В общем, «интуитивность», «понятность» и «дружелюбность» для конечных пользователей — это, по большей части, мечты маркетологов и идеологов того или иного решения. В реальности эти параметры находятся на довольно среднем уровне, а для осознанного использования все-таки требуется определенная подготовка. По крайней мере, это относится к CMS, которые я видел или активно использовал. Где-то с этим лучше, где-то хуже.

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

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

    Отсутствие привязанности к конкретной команде разработчиков и относительно низкие требования к квалификации разработчиков. Это, наверное, одно из главных преимуществ популярных решений: первый разработчик решил стать менеджером, ушел в запой или женился? Нет проблем, найдем другого! В реальности, все, конечно, не так просто. Несколько месяцев назад я наблюдал такую картину: на одном проекте решили сменить команду разработчиков на запущенном проекте. Один «золотой партнер» заменил другого. Думаете, все прошло гладко? Нет. Три недели проект штормило: сроки запланированных работ срывались, постоянно что-то отваливалось или работало не так, как надо. Часто CMS столь огромны, монструозны и необъятны, что даже в очень средний по сложности проект невозможно быстро вникнуть и продолжить чужую работу без особых потерь времени и нервов. Справедливости ради, надо отметить, что в примере выше виноват в ситуации был менеджмент, его амбиции и крайне слабое понимание технической части.

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

    Если резюмировать, то я считаю, что все те CMS с которыми мне приходилось иметь дело, сами по себе неоправданно сложны по сравнению со сложностью решаемых ими задач. И мне это не нравится. Я хотел бы более простое решение, желательно без потери универсальности и с максимальным контролем над происходящим внутри. Конечно, пока это просто мечты, которые подобны разновидности салфеток. Пора переходить к каким-то решениям.

    Решения


    Вначале — еще одно небольшое лирическое отступление. О том, что меня раздражает. Это, скорее, чистая «вкусовщина», но она повлияла на конечный вид решения. Итак, меня раздражают дистрибутивы по 40 000 файлов и каталогов, некоторые из которых имеют уровень вложенности больше 10. Я чувствую тошноту, когда вижу 2 000 строчек шаблона, представляющего из себя месиво HTML и PHP, которые занимаются выводом относительно небольшой части страницы. У меня неприятные ощущения, когда HTML-тег открывается в одном файле с таким месивом, а закрывается где-то в другом. И когда таких файлов больше трех, мне становится хуже. Не меньший дискомфорт доставляют PHP-файлы, которые содержат в себе (без явной на то необходимости) HTML-разметку или ничего, кроме списка include’ов.

    А теперь к, собственно, решениям. Напомню, что я решил поднять флаг максимальной простоты. Первое решение — разделить разработчиков и конечных пользователей. Разработчик — это тот, кто более-менее владеет основным стеком веб-технологий: PHP, HTML, CSS, JavaScript, MySQL. Конечный пользователь — это тот, кто будет пользоваться уже готовым продуктом и чье владение вышеупомянутым стеком может быть любым, начиная с нуля.

    Многие CMS продолжают заигрывать с конечными пользователями фразами вроде «вам не понадобится программист, чтобы создать сайт!». Да, иногда, для некоторой категории пользователей, это очень полезно. Но сайты становятся сложнее, требования к ним повышаются. И если речь идет о проекте с хоть какими-то амбициями, то на каком-то этапе программист обязательно появится. Для всех остальных есть, например, Wix (гадость). У такого заигрывания есть обратная сторона: в системе появляется масса кнопок, настроек и т.п. Все это должно где-то храниться и как-то работать, что означает новые таблицы в БД, файлы в дистрибутиве и общее усложнение системы. А общее усложнение системы приближает ее к состоянию «черного ящика», и т.д. Поэтому в RushCMS (так я назвал свой эксперимент) всего этого просто не будет.

    Следующий удар будет нанесен по предопределенным конструкциям. Большинство популярных готовых CMS используют все тот же вышеупомянутый стек технологий. На базе которого и реализуется большинство предопределенных конструкций. Когда я смотрю в руководство разработчика Битрикс, то у меня создается впечатление, что методов, классов и функций там больше, чем в самом PHP. Конечно, без предопределенных конструкций обойтись не удастся. Иначе просто произойдет полный возврат к «самописной CMS на чистом PHP». Но их количество необходимо минимизировать: оставляем несколько служебных функций (авторизация и некоторые другие) и фиксированную структуру файлов и каталогов — разработчик всегда должен точно знать, где что искать. PHP и HTML должны быть разделены. От всех предопределенных функций вывода отказываемся. Никаких больше get_posts().

    Как же тогда выводить данные? Давайте предположим, что вам за 20 минут объяснят, как хранятся данные в БД и в файловой системе. Так, чтобы у вас не было сомнений, что, где, как и для чего хранится. Сколько времени у вас уйдет на составление SQL-запроса и написание PHP-кода, которые вернут вам все записи типа «Статья блога» начинающиеся на букву «А», в названии которых нет слова «Вася» и отсортированные по дате добавления? Наверное, немного. Выводить результаты будем с помощью простого шаблонизатора. И да, пусть шаблоном вывода будет один файл. Нет, конечно, можно разделить его на несколько. Но разве кого-то испугает длинный, но «читабельный» файл, после «простыней» из смеси HTML и PHP? Тем более, что, например, шаблон сайта-примера (включен в дистрибутив) не такой и длинный: если убрать все пустые строки, он умещается примерно в 200 строк. Логика для его обработки умещается примерно в 220 строк (с пустыми строками). При этом, сайт-пример — это очень маленький, но почти настоящий интернет-магазин. Добавим сюда очень простую (хотя, конечно, не идеальную) систему кэширования «из коробки», механизм действия которой объясняется за 15 минут и которую можно отключать.

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

    Потому как однажды я так и сделал. Задача была очень простая: изредка менять значение одного поля с 1 на 0 и наоборот, что обычно делал я (это было временное решение, честно). Но в какой-то момент мне нужно было срочно уехать. Я оставил простую инструкцию секретарю босса и улетел в ночь. Когда я вернулся, меня ждал сюрприз: были случайно изменены значения совершенно других полей этой таблицы. Рука секретаря дрогнула!

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

    Во-первых, пользователя пугает и заставляет делать ошибки обилие лишней информации. Пусть наш воображаемый редактор БД получит возможность устанавливать права на просмотр и редактирование полей в таблицах. И, заодно, научится устанавливать такие же права на сами записи в таблицах БД. Теперь бы секретарь из моего примера выше смог бы редактировать только один тип поля и только для нужных записей. Скрываем от него все поля, кроме, например, поля с названием записи и поля, в которое он должен вносить значения. Редактировать он может только последнее. Идем чуть дальше и добавляем возможность проверки введенных данных. Чтобы он не мог случайно записать «2» или «Ы» вместо положенных 1 или 0. Теперь шанс на ошибку минимален. Переносим наш редактор БД в браузер. Как известно, среднестатистический пользователь не любит представление данных в виде таблиц и не понимает его. Вводим в структуру таблиц служебные поля для хранения данных об иерархии записей. Заставляем редактор выводить записи таблиц в виде привычных всем «файлов» и «папок», а значение полей — как их «свойства». Добавляем возможность присваивать нашим «свойствам» человекопонятные псевдонимы. Например, «Наличие на складе» вместо непонятного data_available. Конечно, пользователь предпочитает ставить галочки вместо ввода нулей и единиц в текстовые поля. А работа в духе «загрузи файл по FTP в этот каталог и введи название файла в это поле» — это совсем плохо. Поэтому добавляем в наш редактор возможность назначать «свойствам» js-обработчик, которые выведут данные так, как это нравится пользователю. Добавляем возможность назначать разные обработчики на одно и то же поле разным группам пользователей и возможность назначать права на добавление/удаление «файлов» и «папок». Т.е. записей. Конечно, некоторые данные необходимо обрабатывать на стороне сервера: расшифровывать зашифрованное или, например, осуществлять некоторую дополнительную логику, скрытую от пользователя. Например, пользователь поставил свою галочку «нет в наличии», а в таблице изменилось не только значение соответствующего поля, но и еще какое-нибудь связанное логикой значение. Или на почту нач.склада ушло гневное письмо. Что угодно. Для всего этого добавляем возможность реализации логики обработки событий на стороне сервера.

    Именно таким сильно упрощенным и настраиваемым редактором таблиц БД и является RushCMS. Точнее, ее главный (и единственный функциональный) «модуль». Задача разработчика — настроить логику, назначить полям псевдонимы и обработчики, определить права и отдать конечному пользователю. Все относительно немногочисленные настройки хранятся в служебных файлах. В БД оригинального дистрибутива — только данные относящиеся непосредственно к сайту. У сайта-примера (тот самый мини-магазин) в БД три таблицы: для хранения данных страниц сайта, пользователей и заказов. Все три имеют простую и однотипную структуру.

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



    Запутаться, как мне кажется, довольно сложно. Мне не удалось протестировать этот прототип на той же контрольной группе о которой писал выше. Только на четырех из шести. С тем же заданием. Все справились лучше, ошибок было меньше. Это, конечно, не слишком научный эксперимент, но все-таки.

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

    Мои 5 копеек про Open Source


    А тут я немного погрущу и поною. Простите меня. До этого момента мое участие в Open Source заключалось в пожертвованиях десятку проектов без известных мне серьезных спонсоров, результатами работы которых я регулярно пользуюсь. Я «заносил» им в среднем по 2$ в месяц. Кроме того, изредка я писал баг-репорты и еще реже пытался что-то предложить авторам на GitHub.

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

    Многие мои знакомые (чаще всего те, кто лишь косвенно имеет отношение к IT, но при этом так или иначе используют OS-проекты) ставят знак равенства между Open Source и такими понятиями как «бесплатный» и «не нацеленный на получение выгоды». Что, конечно, в корне не верно. Однако это достаточно широко распространенное заблуждение играет против Open Source. Значительная часть аудитории считает их авторов чудаками, готовыми жертвовать материальными благами во имя идеалов человечества. Такие, несомненно, есть. Но их не так много. Большинство OS-проектов, как мне кажется, похожи на стартапы и делаются в ожидании некоторой выгоды. Если даже и не прямой, то хотя бы косвенной: поддержка пользователей, спонсорство, платная поддержка, рост репутации и т.п. Оба эти явления мне кажутся похожими: все начинается с приступа энтузиазма, когда все делается просто из желания реализовать идею и посмотреть, что получится и продолжается уже рутинными процессами: доработка, поддержка, обработка фидбэка и т.д. Но рутина всегда подтачивает любую мотивацию. Если мотивация не подпитывается какой-то отдачей, то проект постепенно погибает. Как только мотивация иссякает полностью, проект оказывается на кладбище. Даже если он при этом остается полезным и востребованным. Есть такие «зомби-проекты», которые мертвы, но все еще ходят.

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

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

    И ладно мое развлечение. Но сколько действительно классных проектов погибает. По моему, в мире Open Source пока все существует по принципу «лучше, чем ничего».

    Заключение


    Несмотря на минорный предыдущий раздел, я, конечно, еще какое-то время поиграюсь со своей моделью. Думаю, у многих была эта навязчивая мысль: «хочу написать свою CMS». Практически детская мечта. Я теперь могу сказать себе: «о да, я попробовал ее осуществить. Так, как мог, но попробовал». И мне чертовски приятно где-то внутри. Я все равно буду улыбаться. Всем добра и отличной весны, друзья.

    Ссылка на проект на GitHub, там все есть.
    Поделиться публикацией

    Комментарии 35

      –1

      Вы создали систему, ориентированную на быстрое наращивание технического долга и создание уникальных решений.
      Второй вопрос, зачем вас CMS для обрзначенной задачи про удобстро пользования? Можно сделать новый шаблон админки для существующей. Нет ли того, что или задача поставленна некорректно вами или средство решения было выбрано без рассмотрения альтернативных подходов?
      Тестирование на 6 пользователях, а затем на 4х… Без комментариев.

        0
        Честно говоря, не очень понял некоторые ваши вопросы. Но попробую ответить.

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

        2) «Сделать новый шаблон админки для существующей» — это получается уникальное решение, против которых вы выступаете в п.1, если я вас правильно понял.

        3) Про некорректность, боюсь, не понял. Про альтернативные подходы — поделитесь, пожалуйста.

        4) Тестирование на 6 и 4 пользователях это, как я сам в статье и написал, плохой и ненаучный подход. С другой стороны, в статье я написал и предупредил, что это всего лишь модель. Если у вс есть возможности для бесплатного тестирования на большой аудитории перед публикацией — это отлично. У меня, к сожалению, такой возможности нет. Кроме того, я достаточно часто и много наблюдал за контент-менеджерами и прочими конечными пользователями CMS, так что смело можете вместо «6» читать «106», например
          0
          Смотрите, вы видвинули несколько тезисов. В частности про удобство работы с сайтом, которое считаете возможным проверять добавлением статьи и товара.
          Но почему-то сразу переходите к тому, что коль у современных CMS проблемы с указанной вами метрикой (удачное добавление статьи и товара с инструкцией и без), то разумно сделать свой велосипед MVP, чтобы показать, что в этом направлении можно развивать CMS.
          Однако почему-то не рассматриваются другие возможные подходы к улучшение обозначенной метрики. Например сделать более качественный шаблон для админки, который можно даже портировать среди разных CMS и обеспечивать пользователям одинаковый опыт на разных движках, а бизнес избавлять от необходимости миграции с системы на систему.

          Про технический долг. Для каждого сайта эти решения будут уникальны, то, что вы называете «обработчики». И программист, знакомый с вашей CMS на примере одного сайта, окажется мало подготовленным к работе с этой же CMS но на другом сайте.
          Ну и чисто архитектурно, ваш подход ведет к увеличению технического долга. Это классическая CMS с синглтоном DB и дерганием данных где ни попадя.

          Ну и до кучи: процедурный код, отсутствие автозагрузчика, не следование никаким PSR. Это все тоже приведет к быстрому наращиванию технического долга.
            0
            Такая метрика была добавлена просто для примера. Никто не говорит, что она единственная, которая учитывалась. Качественный шаблон для админки — это опять уникальное решение. Которое, по вашей же логике, ведет к увеличению тех. долга. Мне был интересен сам подход «упрощенный редактор БД в качестве панели управления сайтом», его реальная жизнеспособность, универсальность, возможность использования.

            Про «обработчики». Когда вам нужно, допустим, кэширование в WP вы каждый раз пишите новый собственный плагин? Не думаю. Относитесь к «обработчикам» как к плагинам. Предполагается, что они будут появляться как стандартные решения по мере развития самой системы.

            Про «классическая CMS с синглтоном DB и дерганием данных где ни попадя». Просто не соглашусь, можно? Лень спорить. Почти любую универсальную CMS можно свести к этому определению.

            Про автозагрузчик, PSR и отсутствие ООП. Не думаю, что их отсутствие приведет к сильному росту тех. долга на тех (по масштабу, назначению) проектах, для которых это предназначено. Плюс это введет некоторую дополнительную сложность, как мне кажется. В любом случае да, об этом стоит подумать и я подумаю. Спасибо. Не забывайте, что это только довольно общая и быстро сделанная модель.
              0
              То есть задача только «упрощенный редактор БД в качестве панели управления сайтом»?
              А как проверяется «жизнеспособность»?

              Про синглтон DB и раскиданные по коду проверки «а есть ли соединение? попробовать вновь» хотелось бы развернуть. Невооруженным глазом видно много дублирования кода и перемешивание ответственности в функциях. Что и есть техдолг. Если вы так не считаете, то хотелось бы услышать, почему такой код будет легко поддерживать и расширять.

              Про PSR и так далее. Они не от хорошей жизни появились. А в попытке сделать растущий код более управляемым и внести стандарты, чтобы новому программисту на проекте не было нужды учить «уникальную систему, полную удивительных возможностей». И чтобы сделать-таки код переносимым между проектами. На мой взгляд, каждого из этих достоинств предлагаемый вами подход лишен.
        0
        Мне кажется Вы изобрели MODX или Evolution CMS. Всё, о чём Вы писали в нём давно есть.
          0
          Да, не скрою, MODX мне всегда нравился. Он ближе многих к моему представлению об идеальной CMS. Но все-таки, идея была в крайнем упрощении. MODX не так и прост, плюс там все-таки есть вещи, которые мне не нравятся. Про Evolution CMS, если честно, ничего практически не знаю.
            0

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

          0
          «Попробуйте постройте приложение уровня и функционала WordPress — и оно точно так же будет задыхаться от наплыва пользователей»

          Ожидал увидеть в статье также результаты бенчарков под нагрузкой — получилось ли эффективнее, чем WP, или нет :)
            0
            Бенчмарки добавить я не догадался, хотя, конечно стоило. И да, если сравнивать с чистым WP без плагинов кэширования, то будет эффективнее. Если сравнивать с WP + плагины кэширования — примерно то же самое. Но я делал некоторый упор еще и на понятность механизма кэширования и сознательность его использования.
            0
            Не сочтите за рекламу, но…
            Реально стоит посмотреть на UMI.CMS. Как на «админку», так и на шаблоны с API. Как минимум, для расширения кругозора, а то и в работе какие-нибудь идеи будут полезными.
              +1
              UMI — платная и, честно говоря, все попытки с ней «познакомиться» кончались одинаковым унынием от того, что я там видел
                0
                Да, платная, но данном случае это не так важно. Тем более, в статье упоминается Битрикс :)

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

                  Битрикс упоминаю просто к слову и потому, что довольно часто его встречаю у кого-то еще. UMI «в бою» не встречал.
                    0

                    А какие преимущества в вашей цмс чтобы тратить времч на ек обучение ;)

                      0
                      Тут уже на вкус и цвет, конечно, но какими должны быть преимущества CMS перед другими, ради которых был бы смысл её изучать?

                      Лично мне UMI очень понравилась удобной админкой, архитектурой и XSLT-шаблонизатором. Не без проблем, конечно, но они есть у любого ПО.

                      Вообще, хотелось бы найти для себя ещё какую-нибудь CMS, с которой бы я работал, но пока всё, что смотрел, вызывало неприятные чувства. То админка перегружена и неудобна, то шаблонизатор Smarty-подобный, то поддержка продукта нулевая, то ещё что-нибудь.
                +1

                Совершенно непонятно, почему Вы решили не следовать никаким стандартам, не использовать единую возможную точку входа для запросов, не использовать ООП, не использовать автозагрузчик, объявлять функции в глобальной области видимости, не использовать пространства имён, не использовать ничего из новых возможностей языка.
                Как вообще Вы себе видите поддержку этого всего кем-то, кроме Вас? В статье пишите про лапшу из инклюдов, в Вашем коде я вижу ровно ту же лапшу и необходимость скакать по файлам в поисках того, что же где подключается и что там содержится. Для чего Вы даете очередной повод зубоскалам попинать ногами PHP со словами, что это недоязык и на нем пишут недопрограммисты?


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

                  0
                  Если коротко: для максимального упрощения + это модель, написанная за несколько дней.

                  Чуть подробнее:

                  Меня, в первую очередь, интересовала жизнеспособность идеи «упрощенный редактор БД в качестве панели управления сайтом». Про качество моего кода я написал в статье. Признаю, некоторые вещи, которые вы сказали — правда. Но:

                  1) ООП — могу я его просто не любить и не хотеть использовать? Хотя, конечно, это ожидаемая претензия. Я обязательно еще раз подумаю над этим.

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

                  3) По поводу необходимости «скакать по файлам». Вам необходимо делать это везде, в любой системе. Здесь была попытка свести это к минимуму. У вас есть несколько файлов, в которых вы можете писать код. В документации (да, она не очень) объяснено, что в этих файлах должно содержаться и что к ним такое подключается. Вы часто исследуете ядро WP или Битрикса? Если да, то вряд ли это так уж гладко у вас получается: без исследований, заморочек и, опять-таки «скачки по файлам».

                  4) Единая точка входа — index.php. В отдельный файл router.php я вынес пользовательскую логику обработки запросов. Чтобы не приходилось исследовать и «скакать».

                  5) По поводу глобального объявления и пространства имен — соглашусь. Наверное, моя лень тут заслуженно порицаема

                  6) Автозагрузчик — смотря, что именно вы имеете в виду. Поясните, пожалуйста.

                  7) Дайте, пожалуйста, ссылки на ваши демонстрирующие правильное программирование на PHP работы/статьи, достойные публикации на Хабре. Если их нет, то, извините, я вам на слово не поверю, что вы такой уж Лев Толстой.

                  8) Про поддержку и развитие — могу спорить, но не буду. Я действительно слабо представляю, что нужно делать, чтобы проект было удобно поддерживать и развивать кому-то кроме меня. Если у кого-то будет такое желание я помогу, отвечу, объясню. Многие системы развиваются поддерживаемы исключительно собственными разработчиками и вполне живут. Думаю, вы сами такие знаете.
                    0

                    7 — пошли доводы "а ты добейся"?

                      0
                      Так от вас же пошли. Вы (местами более чем обоснованно, признаю) судите код и (вот это и вызвало п. 7) выносите мнение что статье «не место на Хабре, нам профессионалам глаз мозолит». Мне кажется, что это более проявление снобизма, чем объективная критика. Понимаете? Не будь последнего абзаца в вашем предыдущем комментарии, не было бы и этого пункта.

                      Ладно, давайте не будем ссорится и кидать друг в друга что-то нехорошее. Признаю, был резковат. Мир?
                        0
                        Вы ничего не перепутали? Например приписали мне чужие слова?
                          0
                          Упс. И правда перепутал. Не обратил внимание на ник, думал это продолжил автор стартового комментария в ветке. Тогда двойной пардон, а объяснение п. 7. остается в силе.
                  +1
                  Вот так всегда, «я решил поиграться тут с php, ребят зацените», а потом все про php со скептической улыбкой вспоминают. Собственный опыт это все конечно круто, но думаю, все не устанут повторять, не надо велосипеды увековечивать в статьи.
                  • Во-первых — они не нужны.
                  • Во-вторых — они все еще не нужны! как правило, отсутствие вменяемой документации, расхождение с общепринятыми принципами, магия внутри.
                  • В-третьих — они субъективны, и в большинстве случаев работают там, и так, где и как хочется их автору.
                  • В-четвертых — как было упомянуто: стайлгайд непонятный, код в процедурном стиле, простыни кода в 1 файле, нет тестов.
                  • В-пятых — наткнутся джуны на такую статью, и подумают «блин, неплохо!», и будут лепить также. А это на самом деле плохо и неправильно. Это сложно поддерживать, это сложно развивать.

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

                    Можете, конечно. Вы вообще всё можете, даже стоять на голове. Надо ли об этом всем рассказывать и хвалиться кодом в процедурном стиле в 2018 году — не уверен. Возможно, следовало хотя бы привести аргументацию, почему именно так и в чем преимущества процедурного стиля относительно ООП или стиля функционального. Аргументация вида "мне лень, я тут набыдлокодил" — это прекрасно. Но вопрос — для чего это на Хабре — остается.


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

                    Почитайте здесь (http://php.net/manual/en/function.spl-autoload-register.php) и здесь (https://getcomposer.org).


                    4) Единая точка входа — index.php.

                    Это Вам только так кажется. У Вас там лежит .htaccess, который редиректит на index.php. Это работает только, если использовать Apache. У меня уже давно все проекты на PHP обрабатываются Nginx + php-fpm. Кроме того, у вас в публичном доступе находится вообще весь код проекта и при желании я могу вызвать любой php-файл в обход index.php. Вы этого не ждете и рано или поздно допустите ошибку (или уже, код я не инспектировал), которая приведет к возможности загрузки шелл-скрипта путем вызова не index.php, а любого другого php-файла. Гораздо более правильным подходом является размещение единой точки входа (того же index.php), а так же всех статических ресурсов, отдаваемых клиенту, в отдельной публичной директории, которая в настройках веб-сервера указывается как корневая для сайта. А весь остальной код выносится на уровень выше и доступа к нему напрямую у клиента нет. Это и называется единая точка входа.


                    5) По поводу глобального объявления и пространства имен — соглашусь. Наверное, моя лень тут заслуженно порицаема

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


                    6) Автозагрузчик — смотря, что именно вы имеете в виду. Поясните, пожалуйста.

                    Ответил выше.


                    7) Дайте, пожалуйста, ссылки на ваши демонстрирующие правильное программирование на PHP работы/статьи, достойные публикации на Хабре.

                    Я вот это даже комментировать сначала не хотел. Переход на личности, конечно, характеризует Вас самым определенным образом. Но все же приведу статью про php, которая, на мой взгляд, была интересной и достойной публикации, хотя и описывала при этом некое самописное решение а-ля велосипед (аналогия с Вашим случаем) — https://habrahabr.ru/post/169525/
                    Моих статей на Хабре нет как раз потому, что я не считаю возможным для себя выкладывать свои поделки, как бы дороги они лично мне не были. В любом случае, я бы сначала постарался изучить последние тенденции в технологии, о которой собрался писать на Хабр. Вы же не удосужились, похоже, выяснить, что со времен версии 4 PHP стал совершенно другим языком.


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

                    Прежде всего — следовать выработанным сообществом PHP стандартам, с которыми можно ознакомиться вот тут — https://www.php-fig.org
                    Это снимет огромное количество вопросов к Вашему коду. Не менее важно — писать к коду тесты. Написание тестов в программировании столь же необходимо и не подлежит обсуждению, как чистка зубов в повседневной жизни.


                    Надеюсь на Ваше конструктивное восприятие критики и работу над ошибками.

                      0

                      Я извиняюсь, не там нажал "ответить". Но, полагаю, Вы поймете, на что именно я отвечал.

                        0
                        Да, конечно понял. У нас тут вообще путаница в комментариях пошла: я за вас принял другого человека и т.д.

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

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

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

                          +1
                          видите, сколько полезного я от вас узнал за невероятно короткий промежуток времени

                          Рад, что был полезен. И, тем не менее, для уточнения новой информации, для обсуждения экспериментов с кодом есть другие площадки, тот же toster.ru, stackoverflow.com и многие другие. Полагаю, многие со мной согласятся, что на Хабре хотелось бы видеть более профессиональные статьи, с описанием продуманных законченных решений, а не статьи про использование подходов, устаревших с десяток лет назад. Не потому устаревших, что мода прошла, а потому, что набили себе шишек и пошли развиваться дальше. От автора, пишущего на Хабре мы, читатели, ждем более профессионального подхода. Хотя бы хорошего знания технологий, использование которых он описывает. Ну и хотелось бы, чтобы труд, изложенный в статье, был полезен, мог быть кем-то из читателей применим. Ваша статья, на мой взгляд (а если почитать комментарии, то не только на мой), этим критериям совершенно не соответствует. О чем я и пишу, начиная с первого комментария в этой теме.

                            0
                            Ну а я вам с первого ответа (и даже с самой статьи) отвечаю, что статья не совсем (и даже совсем не) про код. Который мы с вами практически исключительно и обсуждаем. За комментарии по коду — да, большое спасибо. Возможно, я не совсем правильно изложил идею, да. Тогда это уже мой личный промах.
                      0
                      Предлагаю перед публикации статей такого рода с таким исходным кодом проводить код ревью и нормальную модерацию компетентными php разработчиками. Это же ужас! Товарищи так нельзя! Это травмирует мою детскую психику.
                        +1
                        Спасибо, эта статья мотивирует на создание собственной CMS!
                          0
                          Своя CMS на php-лапше с .htaccess, index.php и запросами конкатенацией в 2018м, спасибо!
                            +1

                            А index.php чем не угодил? Нет, не тот, что в этой заметке, а вообще, в целом?:))

                            0

                            Отправить бы автора в удивительный мир JavaScript, там такие самородки нужнее

                              0

                              Посмотрел ваш код, ощущение будто в 2007-ом оказался. В 2018 есть много крутых и полезных штук, не каких-то сложных и заумных, а вполне простых и доступных.


                              • Неймспейсы есть, это просто и удобно
                              • Парни из PSR (PHP Standards Recommendations) уже целых 11 стандартов приняли, есть куча проектов, их поддерживающих
                              • У нас тут в 2018 есть крутейшая штука, называется composer, это пакетный менеджер и автолоад строит чотко
                              • В публичном каталоге только точка входа типа index.php, из соображения безопасности и простоты поддержки.
                              • Не забываем и про старые истины, SOLID, почитайте на досуге будет полезно.

                              Если в двух словах: "это ужасно".


                              • Не портабелен. Вы кругом используете глобальные переменные и динамические инклуды.
                              • Не тестируем. Ваши функции приколочены к состоянию глобальных переменных, даже если покрыть ваш код тестами — они не будут работать корректно.
                              • Не расширяем. Ваш код невероятно связан, каждое добавление с большой вероятностью сломает существующий код.
                              • Не саппортабелен. Сложность поддержки будет расти экспоненциально.
                              • Не безопасен. Множественные точки входа, sql инъекции, повсеместные инклуды / глобальные / суперглобальные переменные / валидации на столько бесполезны, что их считай нет и т.д.
                                Пример:
                                http://example.com/rc/php/ajax/form_handler.php?form_data%5Busername%5D=ABCD&form_data%5Buserphone%5D=123456789&form_data%5Bcart%5D%5B0%5D=%27%3B+DROP+TABLE+col_pages%3B+--+
                                Удаляет таблицу col_pages
                                0
                                Вы проделали огромный труд — написали систему, документацию. Стоит двигаться дальше. Вы в начале пути развития, только не стоит бросаться в крайности при наличии финансовых затруднений. Последние говорят о том, что вы неправильно выбираете стратегию (модель, как вы указали в статье) заработка. С цмски вы планируете на донате «подняться»? Так тут очень много проблем, описанных выше в комментариях. Многие писали свою систему — я дважды. При недостатке знаний первую я писал по схожему с вашим подходу (лет 10 назад, точно), даже еще хуже, разве что точка входа была единой. Тут, кстати, для роутинга parse_str и parse_query посмотрите. Не умеете дизайн — не надо, есть bootstrap. Для работы с БД, причем практически с любой — взгляните хотя бы на redbeanphp. Шаблонизатор smarty — еще со времен php4. Технологий навалом сейчас — composer и namespace — забудете о простынях инклудов, код будет чище и максимально разнесен на логические единицы; для админки — шаблон AdminLTE; для бд — readben (pdo, автоматически поддержка многих драйверов, защита от инъекций); шаблонизатор — twig, smarty. Тут можно бесконечно перечислять, и это все позволяет решать задачи, а не делать инструменты (велосипеды) для того, чтобы начать их решать. Вы же создали систему по-сути только для личного использования, и то спустя какое-то время даже вам будет трудно ее поддерживать. (Кстати, я не смог ее установить из субдиректории — виной этому $_SERVER['DOCUMENT_ROOT'] повсеместный, а создавать отдельный домен — лень). Поизучайте новые технологии и сделайте свою же систему, но с новым подходом, и затем поделитесь с новичками о своих результатах, почему нельзя делать так, как есть сейчас у вас.

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

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

                                Самое читаемое