Что входит в экосистему Morlix: CMS, аккаунт, лицензии и обновления

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

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

Из каких частей складывается экосистема Morlix

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

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

CMS: где живут страницы и рабочие процессы

CMS управляет сайтом в установленной конфигурации. На morlix.ru опубликованы страницы и материалы блога; в данных текущего сайта видны активная тема и включённый модуль блога. У публикаций есть содержание, категории и теги, а подготовленный материал может сохраняться как черновик перед выпуском.

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

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

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

Аккаунт Morlix и доступ к администрированию сайта

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

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

Почему важно разделять доступы

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

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

Лицензии: условия нужно проверять для продукта

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

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

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

Какие вопросы задать перед установкой

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

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

Обновления: версия, совместимость и проверка

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

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

Последовательность проверки перед обновлением

1. Зафиксируйте исходное состояние. Запишите версии CMS, темы и важных расширений, а также особенности хостинга.
2. Уточните условия. Проверьте доступность нужного обновления, требования к версии и условия использования для соответствующего компонента.
3. Подготовьте восстановление. Сохраните данные, файлы и настройки по принятому процессу; заранее проверьте, кто и как сможет восстановить сайт.
4. Используйте тестовую среду. В разрешённой копии проверьте тему, дополнительные функции и зависимости до изменения рабочего сайта.
5. Проверьте сценарии. Откройте ключевые страницы, статьи и изображения; проверьте формы и доступы, если они есть в проекте.
6. Согласуйте сопровождение. Назначьте ответственного, время проверки и действия при ошибке до начала работ.

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

Как части экосистемы встречаются в одном проекте

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

До запуска

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

После публикации

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

Такое разделение делает разговор предметным: вместо «у нас есть экосистема» команда может ответить, какой инструмент используется для конкретной задачи, кому он доступен и что произойдёт при ошибке. Практические вопросы о совместимости дополнений раскрыты в статье о расширяемости Morlix CMS.

Что проверить веб-студии сейчас

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

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