Баланс функциональности между CMS и отдельными модулями

Категория: Технические советы

– Автор: Игорь (Администратор)

В рамках данной заметки, будут рассмотрены несколько мыслей по теме "баланс функциональности между CMS и отдельными модулями", а так же некоторые нюансы.

Каждый хоть раз задумывался о том, почему бесплатные CMS по умолчанию включают в себя только самые базовые механизмы. Например, тот же WordPress мог бы включать ряд давно известных модулей, таких как WP Super Cache (кэширование), WP-Optimize (базовые механизмы оптимизации) или TinyMCE Advanced (более удобный и мощный редактор текстов).

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

Так почему же подобные включения весьма редки? Этот вопрос и рассмотрим далее.

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

Количество таких модулей по умолчанию?

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

Установить десяток известных или сотню? А какой размер будет у такого движка? Как быстро все будет в нем запускаться? Сложно ли будет такой движок настраивать под задачи отдельного сайта? А как выбирать между разными модулями, каким отдавать предпочтения, а какие оставлять без внимания?

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

Время для поддержки и развития CMS?

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

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

Знания в соответствующих сферах?

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

А что будет если модуль окажется непопулярным?

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

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

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

Разберется ли обычный человек в такой CMS?

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

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

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

Интерес у авторов модулей?

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

Это приведет к тому, что такую CMS обгонит даже самая простая системка, но имеющая большое количество модулей в своем запасе. Может казаться парадоксом, но тут логика проста - от простого к сложному. Даже начинающий может из отдельных модулей собрать что-то специфическое и относительно уникальное. Из универсальной же коробки с минимумом дополнительных модулей сделать подобное сложнее (как минимум, нужно разобраться в CMS; понять как этот весь функционал настроить, если вообще такое можно сделать; плюс может сказаться нехватка дополнительных модулей; и так далее).

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