Как мы выбираем функции для Morlix CMS и от чего отказываемся

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

В этой статье мы показываем подход к обсуждению функций Morlix CMS на конкретных примерах текущего сайта и редакционной политики. Это не отчёт о закрытых совещаниях и не обещание срока для каждой идеи. Закрытая бета ещё не началась: сейчас собираются заявки веб-студий, доступ предполагается после одобрения. Ориентир публичного релиза — 11 марта 2027 года; дата может измениться.

Как мы выбираем функции для Morlix CMS

Предложение «добавить кнопку» полезно превратить в более точный вопрос: какую проблему она решит и что должно произойти после нажатия? Так проще увидеть и пользу, и последствия. Например, возможность отправить анонс статьи связана не только с текстом кнопки: нужны выбранная сеть, разрешённый доступ, ссылка на публикацию и способ определить результат отправки.

Для обсуждения идеи удобно ответить на пять вопросов:

1. Для кого задача? Владелец сайта, редактор, студия и разработчик могут ожидать от одного инструмента разных результатов.
2. Какое действие нужно выполнить? Описываем конкретный сценарий: например, подготовить статью, проверить её и затем опубликовать.
3. Что произойдёт при ошибке? Важно понять, можно ли безопасно остановиться, исправить данные и избежать повторного действия.
4. С чем функция связана? Проверяем тему, модуль, права, внешние сервисы и обновления в той конфигурации, где она будет работать.
5. Как подтвердить готовность? Нужны доступная версия и проверка сценария; описание идеи на сайте само по себе не доказывает, что она готова для всех.

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

Начинаем с задачи человека, а не с длины списка возможностей

Студии важна передача клиентского сайта: кто сможет менять текст, кто отвечает за обновления и где хранятся доступы. Редактору нужен понятный путь от черновика до публикации. Дизайнеру — согласованное оформление на разных страницах и устройствах. Разработчику — ясные границы между темой, содержанием и расширением.

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

Пример: подготовка публикации

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

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

Что означает «отказаться от функции»

Отказ не всегда означает, что идея бесполезна или запрещена навсегда. Иногда её нельзя безопасно проверить в текущей версии; иногда она зависит от внешнего сервиса или требует уточнить права. В таких случаях честнее не обещать готовое решение до проверки, чем представить направление разработки как доступный продукт.

Можно различать три ситуации:

• Готовый сценарий в конкретной конфигурации. Его можно показать и проверить на действующем сайте или в доступной версии.
• Направление развития. Описывает, к чему стремится проект; состав и условия доступа ещё необходимо подтвердить.
• Идея для обсуждения. Помогает сформулировать задачу, но не является объявленным релизом или сроком.

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

Безопасность и контроль важнее автоматического действия

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

Выбор соцсетей для статьи

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

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

Доступ к управлению

У подключённого инструмента управления Morlix чтение и изменение данных разделены по правам. Для прямого управления требуются разрешение администратора CMS и соответствующее согласие OAuth. Это описание границы доступа конкретного подключения, а не универсальная инструкция по настройке всех ролей в любой версии CMS.

Возможность делегировать действие не означает, что помощнику следует давать полный доступ без необходимости. До включения интеграции стоит определить, какие данные ей действительно нужны, кто подтверждает изменения и что произойдёт при отзыве доступа. Основы подхода к соединению AI и инструментов разобраны в статье об MCP простыми словами.

Совместимость и сопровождение — часть самой функции

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

На morlix.ru связь темы и блога показывает, почему эти вопросы важны: содержание статьи и его внешний вид относятся к разным частям проекта, но посетитель видит единый результат. Поэтому при оценке изменения стоит проверить не только саму новую настройку, но и страницу, которая получится после её применения.

Для студии полезно заранее узнать, кто сопровождает настройки клиента и как проверять совместимость после обновления. Отдельный разбор этих вопросов есть в статье о понятной архитектуре CMS. Структура проекта сама по себе не заменяет резервные копии, тестовую среду и договорённости о поддержке.

Пример оценки идеи: анонс в новой сети

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

Шаг 1. Уточнить результат

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

Шаг 2. Проверить доступ и ограничения

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

Шаг 3. Продумать ошибку

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

Шаг 4. Оценить поддержку

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

От чего мы не обещаем отказаться

Разумно не объявлять целые классы возможностей «лишними» только потому, что они сложны. Визуальный дизайн, автоматизация, интеграции и инструменты для разработчиков могут решать реальные задачи. Но интерес к идее не равен подтверждённой готовности конкретной функции, а одна демонстрация не заменяет проверки полного рабочего процесса.

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

Как предложить полезную идею

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

1. Назовите свою роль и тип проекта: например, студия сопровождает сайт услуг клиента.
2. Опишите текущий процесс и место, где возникает трудность.
3. Сформулируйте ожидаемый результат и объясните, кто будет выполнять действие.
4. Укажите важные ограничения: права, устройства, внешние сервисы или необходимость проверки перед публикацией.
5. Если предлагаете автоматизацию, опишите, как должен выглядеть безопасный исход при ошибке или неизвестном результате.

Веб-студии могут подать заявку на будущее закрытое тестирование через morlix.ru; решение о доступе принимается после рассмотрения. Следить за новостями и обсуждением развития можно в Telegram-канале Morlix. Дата 11 марта 2027 года остаётся ориентиром публичного релиза, а не гарантией.

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