Зачем писать свою собственную CMS?

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

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

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

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

Я также хотел создать сайт, на котором каждая страница может быть синдицирована либо в виде метаданных JSON , либо в виде HTML -содержимого только для контента, и чтобы все, что пользователь должен сделать для получения этого содержимого API, это добавить ".json"".html"URL страницы. Насколько я знаю, ни одна из существующих систем не может сделать это без масштабной модификации.

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

Я также ненавижу поля редактирования на основе браузера , и даже самые продвинутые из них не могут сравниться с мощью и гибкостью такого текстового редактора, как BBEdit или TextPad. Когда дело доходит до ежедневного обслуживания и обновлений, у меня есть способ работы и инструменты, которые помогают мне быть продуктивным, и почти все инструменты на основе браузера, которые я использовал, мешают этому. Мой опыт работы с WordPress, безусловно, не помог, так как он постоянно расстраивает и раздражает меня, разрушительно разбирая мою разметку , меняя элементы, добавляя разрывы, делая хороший HTML плохим. Я не хочу иметь дело с этим. Мне нужна система, которая работает с обычными текстовыми файлами, которые вообще не анализируются, и их не нужно очищать, поскольку они не хранятся в базе данных.

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

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

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

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

Преимущества написания своего собственного

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

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

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

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