Извечные споры: CMS или своя разработка?

Когда я искал информацию по сайтостроению, то захаживал на различные площадки вопросов и ответов. Меня интересовали вопросы, связанные с начальным проектированием и созданием собственного сайта, однако задавать их не пришлось: подобного рода вопросы отнюдь не не являются вымирающим видом, канувшим в прошлое, – о нет, они возникают регулярно, хоть и нечасто. При этом немалая часть ответов на них сводится, по сути, к одному – поставить CMS и не городить огород, плодя свои собственные велосипеды. "Joomla" – кричат с одной стороны. "WordPress" – негодующе возражают с иной. И комментарии начинают тяготеть к превращению в своеобразный ринг, где изначальный вопрос за ненадобностью отброшен в сторону.

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

У семи нянек дитя без глаза

Иногда я просматриваю логи своего сайта – чисто из любопытства. И неизменно вижу строки, содержащие "wp-content", "wp-login", "wp-admin" или нечто подобное. Боты пытаются взломать сайт, полагая, что он написан на WordPress. Разумеется, боты ошибаются, однако свои попытки не бросают, ведь сайты на этой CMS взламываются регулярно.

Вот, например, история взлома одного WordPress плагина, описанная непосредственно автором дополнения в статье на Habr. Там же можно найти статьи, посвящённые взлому самой CMS, – такие материалы не являются чем-то из ряда вон выходящим, отнюдь. Открытость программного обеспечения вовсе означает безопасность его использования. То, что некий код можно прочесть и найти ошибки (намеренные или случайные), вовсе не означает, что его обязательно прочтут. Сравните: учебники по математике вполне доступны, однако это вовсе не значит, что студенты их прилежно штудируют.

Учитывайте простой факт: в мире открытого программного обеспечения (open source) действует непреложный принцип: никто никому ничего не должен. Да, вы можете поставить и использовать CMS, но бесплатную поддержку никто оказывать не обязан. Могут, конечно, но не обязаны. Более того: система, которая была ранее бесплатной, может внезапно потребовать оплату. Так случилось с October CMS, и люди, которые делали на её основе некий личный проект, были поставлены перед выбором: платить или переносить все данные на новую систему. Разработка CMS вообще может прекратиться. Зайдите, например, в список бесплатных систем управления контентом, любезно предоставленный Википедией, и проведите небольшое исследование – сколько систем не обновлялось уже более пяти лет?

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

И швец, и жнец, и за столом обжора

Сравните два ножа: обычный кухонный нож и швейцарский. Швейцарский массивнее, не так ли? Причина этому довольно банальна: в "многозадачном" ноже скрывается немало возможностей, которые обычному ножу недоступны. Это же касается и CMS – их раздутость является платой за универсальность системы, часть функций которой конкретный пользователь, возможно, никогда использовать и не станет.

Мне попадались на глаза предложения хостинга, ориентированного именно на WordPress: с различными дополнениями, позволяющими ускорить работу неповоротливого движка. Эта массивность относится, конечно же, не только к WordPress. Например, когда я перевёл сайт с MediaWiki на самописный движок, потребление ресурсов упало в разы. По моим оценкам, основанным на предоставляемых хостингом диаграммах, точнее было бы сказать даже не просто в разы, а в десятки раз. И это при том, что посещаемость возросла, так как я соединял воедино материалы с двух своих старых ресурсов.

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

Спасение утопающих – дело рук самих утопающих

Отмечу ещё раз, что я сужу не с позиции программиста, но с позиции пользователя. Я лишь использую готовые информационные системы, и то, что я изучил основы MySQL, PHP, HTML, CSS и JavaScript для создания собственного сайта, не делает меня программистом – лишь, пожалуй, неким "продвинутым" пользователем, не более того.

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

Оказалось, что без этого никак не обойтись. Например, для отрисовки формул на сайте под управлением MediaWiki я использовал MathJax (превосходный скрипт, кстати). А чтобы его внедрить в CMS существовало (и существует поныне) дополнение SimpleMathJax. После его установки я сразу столкнулся с проблемой – дополнение поддерживало отрисовку формул, расположенных внутри строк, однако выключные формулы (те, которые находятся в новой строке) реализованы не были. Пришлось лезть в код и разбираться в нём, чтобы хоть как-то добавить новый тег, предназначенный именно для выключных формул. Закончились ли на этом приключения? Разумеется, нет: ведь теперь нужно было добавить кнопку тега математики на панель редактора, для чего опять-таки пришлось вставлять дополнительный код уже в ином месте.

Впрочем, такой вариант можно считать удачей – когда дополнение удалось доделать. Хуже, если оно просто прекращает работу. Так, например, случилось с дополнением DeletePagesForGood, которое позволяло начисто удалять страницы из базы данных. Без этого дополнения MediaWiki не удаляла страницу навсегда, перемещая её в условный архив. К слову, это ещё одна проблема CMS: рамки, сознательно наложенные разработчиком. Цитата со справки:

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

Вот дополнение DeletePagesForGood и решало эту проблему. Однако после очередного обновления CMS, при попытке удалить страницу дополнение стало выдавать лишь портянку ошибок. Разработчик исправлять ситуацию не стал, и администраторы сайтов вынуждены были распрощаться с возможностью безвозвратного удаления страниц. Отмечу, что по состоянию на момент написания статьи (январь 2025 года) дополнение вновь работает, но как скоро очередное обновление движка опять сломает его – неизвестно.

Одна из радостей жизни – это её непредсказуемость

Цитата из заголовка, приписываемая одному из персонажей сериала "Друзья", полной мерой отражает проблему, с которой мы начали разбираться в предыдущем пункте. Непредсказуемость – извечная проблема любой CMS. Неизвестно, что именно разработчики изменят в очередной версии движка, и не заменят ли они условную переменную a новой переменной b, из-за чего сломается бесперебойная работа налаженного сайта.

Вам понравилась, к примеру, некая готовая тема оформления? Есть риск распрощаться с нею после очередного обновления CMS, если, разумеется, автор темы не внесёт оперативно правки. Меняются также и шаблоны стандартных тем, так что если вам понадобилось в некоем месте добавить вывод своего текста, то в обновлённом шаблоне для этой цели может потребоваться вносить код совсем в иной части скрипта. Пользователь не контролирует CMS. Она для него представляет чёрный ящик, перед которым изредка (или не изредка, как повезёт) нужно призносить своеобразные заклинания, внедряя добытые поиском в интернете куски кода, и надеясь, что теперь-то система заработает так, как хочется. А ведь не обновлять CMS, как мы понимаем, обычному пользователю нельзя.

Неужели всё так плохо?

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

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

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

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

Не торопитесь с выбором. Поищите на профильных сайтах (тот же habr, к примеру) статьи о рейтингах CMS, о достоинствах и недостатках различных систем управления контентом. Почитайте комментарии разработчиков к этим статьям. Предварительно выбрав некую CMS, дайте себе ответы на такие вопросы: как долго существует рассматриваемая система, понятна ли вам её документация, есть ли "из коробки" нужная вам функциональность (или же её нужно добавлять плагинами), отзывчивое ли сообщество у CMS (т.е. сможете ли вы получить помощь при необходимости). Потратьте недельку на тестирование выбранных систем на локальном сервере у себя на компьютере. Разумеется, это существенно повысит порог входа, но зато избавит от возможных проблем в будущем, – хотя бы отчасти.

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