Карта версии и модели
Сущности, отношения, сценарии валидации и фактические расширения Yii.
Перенос с Yii на 1С-Битрикс
Переведём данные и согласованные рабочие сценарии Yii-приложения в Битрикс, отдельно проверив модель, правила ввода и доступы пользователей.
Назовите версию Yii, роли и внешние подключения. Определим данные и действия для контрольного переноса.
Узнаёте свою ситуацию?
- В Yii-приложении есть собственные роли и сценарии, которые требуется сохранить при переходе в CMS.
- Редакторам нужна новая модель публикации, а бизнес-правила находятся в коде приложения.
- Миграция затрагивает внешние потребители и формы с разными правилами проверки данных.
Как поможем
Перенос с Yii на 1С-Битрикс — исследование версии и устройства приложения, преобразование данных и новая реализация необходимых функций. Yii не задаёт единую CMS-структуру для всех проектов. Модели, сценарии валидации, связи и обработчики нужно сопоставить с целевым поведением; копирование таблиц не переносит эти правила автоматически.
Что входит в работу
Разбираем модель данных и разрешённые изменения
Изучаем модели, правила, используемые сценарии и связи. Если применяется Active Record, проверяем не только физические поля, но и отношения и поведение классов. Документация Yii 2 ActiveRecord относится к определённой версии; её нельзя механически переносить на другое приложение. Отмечаем вычисляемые атрибуты и значения, которые формируются вне таблиц.
В структуре Битрикс задаём сущности и поля с понятными правилами обновления. Контрольная выборка включает создание, изменение и просмотр одной записи разными ролями. Значения, допустимые для администратора, могут быть запрещены обычному пользователю; перенос данных не должен превращаться в расширение полномочий. Связи и файлы проверяем по таблице соответствия идентификаторов.
Принимаем формы, действия и точки обмена
Составляем список контроллеров, фильтров, собственных модулей и задач, которые участвуют в ключевом процессе. Для каждой функции определяем целевую реализацию или явное исключение. Если внешние потребители обращаются к приложению, согласуем контракт API до смены маршрутов. Новый сайт не должен возвращать похожий экран, но менять смысл ответа для подключённой системы.
Публичные маршруты и ссылки входят в контроль переезда. Перед переключением проверяем повторные отправки, ошибки проверки и изменения после первой выгрузки. Стоимость зависит от версии, модулей, правил и документации. Лицензии, новый дизайн и переписывание независимых сервисов выделяем отдельно. До запуска проверяем выбранный способ авторизации, после переключения контролируем обработку адресов и изменения индексации.
Проверим модель и сценарии вашего Yii-приложения
Назовите версию Yii, роли и внешние подключения. Определим данные и действия для контрольного переноса.
Что вы получите
Сопоставленные данные
Целевые поля, права и контрольные записи с проверенными связями.
Приёмка действий
Формы, роли, внешние интерфейсы и условия финального перехода.
Как проходит работа
-
Уточнить приложение
Определяем версию Yii, структуру и критичные бизнес-правила.
-
Проверить модель
Переносим связанные данные и проверяем операции разных ролей.
-
Принять сценарии
Тестируем действия, ошибки и обмен перед переключением адресов.
Как проверить результат
Соответствие версии
Решения основаны на установленном проекте и его действительных возможностях.
Сохранённые ограничения
Пользователь не получает лишние права после переноса модели.
Совместимый результат
Внешний потребитель и человек получают согласованный итог действия.
Связанные услуги
Вопросы об услуге
Можно использовать один план для Yii 1.1 и Yii 2?
Общая логика обследования похожа, но технические детали и расширения различаются. Сначала определяем фактическую версию и собственные изменения. Нельзя считать документацию одной ветки доказательством поведения другой; приёмка строится на реальных моделях и пользовательских сценариях исходного проекта.
Правила моделей перейдут вместе с данными?
Нет. Данные отражают сохранённые значения, а правила определяют, что можно создать или изменить. В новой системе эти ограничения реализуются отдельно и проверяются на допустимых и ошибочных примерах. Иначе внешне правильная карточка может принимать значения, которые исходный процесс запрещал.
Нужно ли менять адреса всех API-запросов?
Не обязательно, но совместимость должна быть сознательным решением. Можно сохранить контракт, создать согласованный новый интерфейс или оставить часть приложения сервисом. Для каждого потребителя проверяем формат и смысл ответа. Простой редирект страницы не всегда подходит запросу, который создаёт или изменяет данные.
Обсудим задачу вашего проекта
Расскажите о сайте и о том, что хотите изменить. Уточним объём работ, обсудим сроки и подготовим предложение.
- Пришлите ссылку на сайт и опишите задачу
- На обсуждении уточним цели и ограничения
- После — предложение с составом работ и условиями
С чего начнём?
Опишите вашу ситуацию. Если сайт или CRM уже есть — добавьте ссылку и то, что хотите изменить.
На следующем шаге нужен только телефон. Остальное — по желанию.
Или напишите: info@iskariot.ru