Хорошо, взгляды, время для небольшого перерыва от удара Sql Server, на котором я был в последнее время. В настоящее время я помогаю одной из наших дочерних организаций запустить новый веб-сайт. Сайт, построенный на довольно хорошо продуманной, зрелой CMS с открытым исходным кодом. И они ненавидят значительную часть этого со страстью, даже не затрагивая многие функции, потому что они совершенно не нужны в их применении. Не берите в голову интересный набор проблем прорезывания зубов, которые возникали, когда разработчики объединили изменения из основной части проекта со своими собственными настройками. Их испытание напомнило мне одну вещь, которую я понял несколько лет назад: коробочные CMS-приложения — это кошмары, которых лучше обходить стороной, чем обнимать.
Во-первых, позвольте мне определить «коробочную CMS» для ясности. Это полнофункциональная, многофункциональная система управления контентом в коробке, которая может быть zip-файлом, который вы скачали с sourceforge. Как правило, такие вещи, как меню, статьи, зоны для участников, система безопасности, RSS-каналы, галереи изображений и форумы. В 95% случаев достаточно загрузить файлы на сервер, запустить скрипт базы данных и добавить контент, чтобы получить полнофункциональный веб-сайт. Фактический источник — лицензированное коммерческое приложение или загруженное приложение с открытым исходным кодом — несущественен. В любом случае, он, вероятно, имеет на полдюжины больше функций, чем вам нужно.
Теперь вы, вероятно, говорите: «Вау, Уайетт! Какого черта я хочу построить все эти сантехники, когда я могу просто скачать его и установить его и использовать некоторые параметры конфигурации и шаблоны? »- очень разумный вопрос, заслуживающий некоторых очень разумных ответов.
Первая проблема заключается в том, что сама природа CMS не может быть легко упакована без создания приложения, которое пытается сделать все для всех и не может сделать большинство вещей особенно хорошо. Задачи, требуемые для управления контентом, являются общими, но каждая организация имеет совершенно разную направленность, когда речь идет о том, как управлять этим контентом и как он думает об этом контенте. Я потерял дни встреч, пытаясь помочь экспертам понять, что статья, согласно этой системе, действительно является страницей. Попытка сделать универсальное приложение, чтобы справиться с этим для всех желающих, очень и очень сложная перспектива.
Таким образом, в результате я до сих пор не видел конечного пользователя, который действительно хотел бы работать с готовой CMS / sourceforge. Один из них неизменно реализует более, чем несколько обходных путей, чтобы, например, система публикации блогов работала как система публикации статей. Или используя систему управления рекламными баннерами для обработки содержимого боковой панели. Почти всегда нужно идти на компромисс между хорошей информационной архитектурой и тем, как система хочет что-то делать. И компрометация вашей информационной архитектуры никогда не бывает хорошей.
Другая важная проблема заключается в том, что я никогда не видел «коробочную CMS» в производственной реализации, ограниченную изменением параметров конфигурации и / или шаблонов. Всегда есть некоторые или много требований, которые подталкивают к серьезному расширению и / или модификации кода. И как только вы начинаете заниматься серьезными изменениями системы, вы попадаете в настоящие кошмары.
Во-первых, связывание с основными компонентами может легко сломать другие вещи в самой CMS, когда вы углубляетесь в неизвестную территорию. Но эти проблемы кодирования в большинстве случаев преодолимы. Это очень похоже на большинство случаев погружения в чужую кодовую базу — редко забавно, но обычно выполнимо. К сожалению, это еще не конец.
Для меня самая страшная часть, после того, как кто-то значительно изменил это приложение (квадратный колышек пословицы), чтобы соответствовать требованиям (круглое отверстие пословицы), у вас есть странное гибридное приложение. Устаревший код с некоторыми критически важными пользовательскими битами. Поскольку эти пользовательские биты живут в устаревшей системе, они имеют значительные зависимости от указанной системы. И тогда контролирующая сторона вашей коробочной CMS — будь то поставщик или проект с открытым исходным кодом — выпускает обновление. И чаще всего это обновление ломает ваши изменения, делая вашу реализацию приложения бесполезной.
Для тех из нас, кто отвечает за безопасность блоков, которыми мы управляем, усугубляет этот кошмар тот факт, что многие из этих обновлений содержат критические исправления безопасности, часто с эксплойтами. Это означает, что ваша настроенная версия этой коробочной CMS теперь представляет значительную угрозу безопасности для организации, потому что вы нарушили цикл обновления, чтобы соответствовать требованиям приложения. Это непростое место. Теперь вы вынуждены либо взломать свой сайт, либо срочно выполнить работу по исправлению, чтобы сделать ваши изменения совместимыми с новым режимом, либо просто безнадежно надеяться, что никто не заметит дыру в безопасности.
Мой чистый жизненный урок, после того, как я справился со своей справедливой долей внедрений CMS в штучной упаковке, состоит в том, чтобы их избегать, если только вы не уверены, что на самом деле останетесь внутри коробки.