85авторских статей
Восстановлены отдельным этапом миграции; сохранился содержательный слой проекта.
Автор текстов — Светлана Ареповская.
КЕЙС
E-COMMERCE / DIGITAL
Цветочная коллекция Светланы Ареповской
Пересборка e-commerce без обнуления каталога, авторского контента и поисковой истории.
НАПРАВЛЕНИЕ · 01
Каталог и миграция данных
Проект нельзя было пересобрать как новый пустой магазин. Товары, категории, изображения, заказы, статьи, меню, YOOtheme-страницы и URL требовали отдельного ownership и отдельного контроля.
Поэтому работа начиналась не с интерфейса: сначала нужно было спроектировать контур сохранения данных и связей, а уже затем собирать новую витрину поверх сохранённой основы.
Порядок работы: сначала сохранение и контроль — затем интерфейс.
НАПРАВЛЕНИЕ · 01 · КЕЙС · 011 003 карточки и 6 466 изображений: как сохранить товарную систему при пересборкеСверка исходной базы, тестового импорта и актуального каталога: товары, фотографии, категории, авторский контент и SEO-поля без потери исходных идентификаторов.
01 / Задача пересборки
Перенести каталог — значит сохранить связи внутри товарной системы
Нужно было сохранить не только количество карточек, но и фотографии растений, категории, авторские описания, SEO-поля и идентичность исходных записей.
В ходе пересборки я работал с архитектурой переноса товарных данных и их проверкой. Авторские тексты и фотографии принадлежат Светлане Ареповской: моя задача состояла в том, чтобы не потерять эти материалы и сохранить их корректные связи с карточками.
1 003товарные карточкисвязи с контентом и SEO-полями
6 466изображенийфотографии, привязанные к товарам
6категорийтоварная структура JoomShopping
Главный принцип: товарная карточка, её ID, фото, категория и содержание должны оставаться одной связанной записью. Равные итоговые количества сами по себе не доказывают сохранность каждой связи — идентификаторы проверяются отдельно.
02 / Контроль целостности
Три состояния базы — один состав критических сущностей
В рабочем реестре миграции сопоставлены исходная база, тестовый импорт и актуальное состояние. Это проверка сохранности товарных данных, а не показатель продаж.
| Сущность | Исходная база | Тестовый импорт | Актуальная база |
|---|---|---|---|
| Товарные карточки | 1 003 | 1 003 | 1 003 |
| Изображения товаров | 6 466 | 6 466 | 6 466 |
| Категории JoomShopping | 6 | 6 | 6 |
Контрольная книга отдельно фиксирует отсутствие потери исходных ID товаров, изображений и категорий при тестовом переносе. Совпадение количества строк не подменяет проверку этих идентификаторов.
03 / Логика работы
Сначала определить, что можно менять, а что нужно сохранить
Этапы миграции не должны переписывать соседние критические сущности. Для этого данные сопоставлялись и проверялись как связанный набор.
01 / СопоставитьКарточка и ID
Сверить исходные идентификаторы и названия товаров между состояниями базы.
02 / СохранитьСвязанные материалы
Удержать изображения, категории, авторские тексты и SEO-поля.
03 / ОграничитьГраницы изменения
Не затрагивать соседние сущности при переносе отдельной части данных.
04 / ПроверитьРезультат переноса
Сопоставить количество, исходные ID и заполнение карточек.
Моя зона
Архитектура пересборки, работа с данными и миграцией, контроль связей между карточками и качество полученного состояния.
Авторский контент
Фотографии растений и авторские описания Светланы Ареповской сохранены в товарном массиве. Их создание я не приписываю себе.
04 / Проверка актуального каталога
Сохранить число записей мало — важно проверить наполнение карточек
В актуальной базе отдельно проверены изображения, описания, SEO-поля и статус публикации. Эти показатели говорят о состоянии данных, но не о заказах или выручке.
Главное изображение1 003 / 1 003
SEO title и meta description1 003 / 1 003
Краткое описание998 / 1 003
Полное описание1 000 / 1 003
973 / 1 003ОпубликованоСтатус карточки в актуальной базе, не подтверждение наличия товара.
372 / 1 003Положительный остатокОтдельный показатель данных об остатке, не подтверждение фактических продаж.
576 / 1 003Положительная ценаНаличие цены не равно доступности товара к заказу.
Число опубликованных карточек, положительных остатков и заполненных цен нельзя складывать или интерпретировать как продажи и количество гарантированно доступных товаров.
05 / Доказательная база
Контрольная книга и SQL-экран — два разных формата проверки
Рабочая книга составлена из первичных SQL-дампов и README этапов. Экран SQL — реконструкция по данным актуальной базы; он не является оригинальным историческим скриншотом.
E4 / Рабочий документ из первичных источников
Открыть Excel ↗Контроль миграции товарной базы
Три состояния базы, проверка количеств и исходных ID; заполнение критических полей и границы переноса.
SQL-сверка актуальной базыE3 / Реконструкция · Нажмите для увеличения
НАПРАВЛЕНИЕ · 01 · КЕЙС · 02Backup → staging → QA → rollback: миграция с ограниченным рискомРезервная копия, отдельная тестовая среда и проверка каждого пакета изменений — без необходимости пересобирать весь магазин из-за ошибки одного слоя.
01 / Принцип миграции
Ошибка одного слоя не должна требовать пересборки всего магазина
Работу разбивали на контролируемые шаги. Сначала сохраняли исходное состояние, затем проверяли изменения отдельно — с возможностью вернуться назад при ошибке.
01 / BackupСохранить базу
Резервная копия оставляет контрольную точку до внесения изменений.
02 / StagingОтдельная проверка
Тестовое состояние позволяет проверить пакет без немедленного изменения рабочего магазина.
03 / ПакетОдин слой за раз
Изменения ограничиваются своей зоной, не переписывая соседние сущности.
04 / QAСверить результат
После изменения проверяются затронутые данные и то, что соседние пакеты остались целыми.
Rollback — маршрут возврата при сбое, а не показатель результата. Контрольная точка нужна, чтобы ошибочную итерацию можно было изолировать и исправить без повторного запуска всей миграции.
02 / Сохранность заказов
Старые заказы сохранены; новые записи не переписали историю
Состояния заказов сверялись отдельно от работы с каталогом и интерфейсом. Числа показывают целостность данных, а не рост продаж.
Исходная база225Заказы до миграции
Тестовый импорт225Старые записи сохранены
Актуальная база229Четыре записи появились позже
Исходные ID старых заказов сохранены. Разница 225 → 229 отражает четыре более поздние записи, а не четыре заказа, полученные благодаря миграции.
03 / Проверка и возврат
Ошибочная тестовая итерация ссылок осталась локальной проблемой
Rollback-подход понадобился на практике: неверный тестовый вариант ссылок был локализован и исправлен, без превращения ошибки в повод пересобирать весь магазин.
Тестовая итерация
Ссылки потребовали исправления
Во время отдельной проверки один вариант изменения ссылок оказался ошибочным. Это была проблема конкретного пакета, а не свидетельство потери товарной базы или заказов.
Rollback-подход
Вернуться к контрольному состоянию
Наличие точки возврата позволило локализовать проблемную итерацию и исправить её. Соседние части системы не требовалось собирать повторно вместе со ссылками.
Граница утверждения: речь о контроле технического риска во время миграции. Здесь не заявляются прирост позиций, поискового трафика или измеренный коммерческий эффект исправления ссылок.
04 / Изолированные пакеты
YOOtheme восстанавливали отдельно — товары, цены и заказы не трогали
Восстановление интерфейсного слоя не объединяли с переносом товарных данных. Это сохраняло понятную границу проверки: что меняется в конкретном пакете, а что должно остаться прежним.
Отдельный пакетВосстановление YOOtheme
Интерфейсные изменения выполнялись как отдельная задача со своей проверкой, без смешения с переносом товарной базы.
Не затрагивалось пакетомТовары · заказы · цены
Эти сущности не переписывались в рамках восстановления YOOtheme. Их целостность проверялась отдельно от интерфейсного результата.
Моя работа в этом контуре: архитектура пересборки, разделение изменений по зонам, работа с данными и контроль качества полученного состояния. Результат кейса — ограниченный и проверяемый технический риск, не обещание его полного отсутствия.
НАПРАВЛЕНИЕ · 03
Интерфейс, e-commerce и измеримые сценарии
После стабилизации данных интерфейс интернет-магазина строился на Joomla 6.1.0, YOOtheme Pro и JoomShopping 5.9.2. YOOtheme отвечает за оболочку и композицию страниц; JoomShopping — за товарную модель, категории, корзину и заказы.
Я связывал интерфейсные решения с устройством каталога и пользовательскими переходами. Аналитика здесь — карта поведения: она помогает рассматривать движение по сайту и отдельные действия, не подменяя их неподтверждёнными показателями продаж.
Принцип направления: оболочка сайта, товарная логика и измерение действий должны описывать один пользовательский сценарий, а не три разрозненных инструмента.
НАПРАВЛЕНИЕ · 03 · КЕЙС · 01YOOtheme как оболочка, JoomShopping как владелец товарной логикиКак развести оформление сайта и работу интернет-магазина, сохранив точность товарной карточки и фотографий сортов.
01 / Разделение ответственности
Дизайн сайта и товарная логика — два связанных слоя с разными задачами
Пересборка велась на Joomla 6.1.0, YOOtheme Pro и JoomShopping 5.9.2. Важно было не подменить магазин набором декоративных HTML-блоков: у каждого слоя остаётся собственная ответственность.
Joomla + YOOtheme Pro
Структура стандартных страниц и визуальная система сайта.
- Шапка и подвал
- Типографика
- Контейнеры и сетки
- Обычные страницы и списки блога
Граница: визуальные контейнеры не берут на себя обработку цены, остатка или заказа.
JoomShopping
Карточки, категории и действия покупателя остаются в контуре магазина.
- Список товаров
- Карточка и категории
- Цена и доступность
- Корзина и оформление заказа
Граница: представление товара связано с его данными и поведением магазина, а не с отдельной вручную собранной витриной.
Принцип пересборки: единый визуальный язык сайта соединяется с действующей товарной системой; интерфейс не должен нарушать связь карточки с категорией, ценой, доступностью, корзиной и оформлением заказа.
02 / Точность товарной карточки
Карточка сорта — часть товарной идентификации, а не декоративная плитка
В цветочном каталоге реальная фотография конкретного сорта помогает понять, какой товар представлен. Поэтому визуальное оформление не должно разрывать связь фотографии, названия и данных магазина.
- 01 / ИдентификацияРеальная фотография сорта
Фото и авторский контент Светланы Ареповской остаются частью исходной товарной системы.
- 02 / КонтекстНазвание и категория
Карточка должна сохранять понятную связь растения с соответствующим товарным разделом.
- 03 / СостояниеЦена и доступность
Товарные значения принадлежат JoomShopping; публикация карточки сама по себе не подтверждает наличие.
- 04 / ДействиеКорзина и заказ
Покупатель продолжает сценарий в магазине, а не в независимой от товара HTML-имитации.
Авторство и моя роль разделены: реальные фотографии и авторские материалы принадлежат Светлане Ареповской. Моя задача в этой части проекта — архитектура и интерфейсные решения при пересборке, сохраняющие работу товарного контура и связность контента.
03 / Правила реализации
Настройка интерфейса без глобальных побочных эффектов
Нестандартные элементы дорабатываются только там, где обычной композиции не хватает; штатные возможности Joomla, YOOtheme и JoomShopping сохраняют свои задачи.
Локальные классы и CSS
Дополнительные блоки используют классы с префиксом koflower- и локальные стили. Без глобальных сбросов, способных изменить соседние страницы.
Стили привязаны к своему блокуНе добавлять лишние зависимости
Если задачу решают CSS или штатные возможности UIkit, нет причины вводить тяжёлый JavaScript или случайные внешние библиотеки.
Сначала штатная механикаМагазин остаётся магазином
Кастомный HTML/CSS дополняет визуальную композицию, но не подменяет карточку товара, обработку цены, наличия и оформления заказа.
Данные и покупка — в JoomShopping04 / Доказательная база
Реальный интерфейс и актуальный масштаб — разные типы подтверждения
Первичный рабочий экран JoomShopping показывает устройство товарного контура. Отдельная реконструкция по актуальным данным демонстрирует структуру каталога в более позднем состоянии. Эти материалы не подменяют друг друга.
JoomShopping в реальной административной среде
Список товаров, названия, фотографии, артикулы, категории, цены, количество, статус публикации и фильтры.
Внизу экрана показано «Всего: 156». Это число относится только к показанному рабочему срезу; оно не описывает актуальные 1 003 карточки. Точная дата исходного экрана отдельно не подтверждена.
Открыть первичный экран ↗Рабочая схема текущего товарного каталога
Состав и интерфейс JoomShopping показаны в подготовленном по данным проекта экране; это не фотография исходной исторической админки.
Актуальная база: 1 003 карточки, 6 466 изображений и 6 категорий. Эти значения характеризуют структуру каталога; они не доказывают продажи или наличие каждого опубликованного товара.
Открыть реконструкцию ↗Граница доказательства: изображения подтверждают вид интерфейса и иллюстрируют организацию товарных данных. Они не доказывают рост продаж, выручки или поисковых позиций. Первичный файл имеет отмеченное в реестре несовпадение SHA с хостинговым листингом — байтовое тождество не заявляется.
НАПРАВЛЕНИЕ · 03 · КЕЙС · 02«Уточнить наличие» и Метрика: конверсионный сценарий без выдуманных продажОт отдельного запроса о растении — к защищённой форме, уведомлению и раздельному учёту действий на сайте.
01 / Сценарий обращения
«Уточнить наличие» — отдельное действие, а не обещание готового заказа
У товарной карточки есть состояние публикации, цена и остаток, но ни один из этих признаков сам по себе не подтверждает возможность покупки конкретного растения. Для уточнения предусмотрен самостоятельный контактный маршрут.
- 01 / Точка входаЗапрос о растении
Якорный призыв к действию ведёт к форме «Уточнить наличие растения».
- 02 / КонтактПередать вопрос
Поля контакта, вопрос и согласие на обработку персональных данных позволяют оформить обращение.
- 03 / ОбработкаСохранить отправку
Конфигурация предусматривает сохранение отправок и email-уведомления. Сам факт отправки ещё не равен продаже.
Граница сценария: уточнение наличия, заполнение формы, добавление в корзину и оформление заказа — разные действия. Не подменяю их одним показателем коммерческого результата.
02 / Логика формы
Форма должна принять запрос и сохранить управляемость обработки
Поведение формы дорабатывалось итерациями: от базового контакта до обязательности полей, согласия, уведомлений и компактной вертикальной версии. Состав показан по конфигурации, без выдуманных цифр обращений.
Для посетителя
Понятный вопрос и контакт
Форма «Уточнить наличие растения» сохраняет отдельную точку входа и необходимые сведения для ответа.
- Имя
- Телефон
- Что уточнить?
Для обработки и защиты
Не только внешний вид
Конфигурация описывает поведение после отправки и меры против автоматических обращений.
- Сохранение отправок
- Email-уведомления
- Honeypot
- Минимальное время заполнения
- Управление обязательностью полей
- Reset / hide после отправки
- Компактная вертикальная версия
- Адаптивные локальные стили
03 / Аналитика событий
Метрика показывает несколько уровней действий, а не количество продаж
Для оценки сценария разделяются действия, относящиеся к магазину, контакту и навигации. Целевые визиты и достижения целей — показатели событий, которые нельзя суммировать в число покупателей или заказов.
01
Действия в магазине
Добавление товара в корзину, работа с корзиной и начало оформления заказа. Начало оформления не подтверждает завершённую покупку.
02
Контактные действия
Автоцель отправки формы, контакты, заполнение и отправка контактных данных. Даже достижения одной цели не равны числу уникальных заявок.
03
Навигационные действия
Переходы в социальные сети и контентные точки взаимодействия помогают видеть путь по сайту, но не являются коммерческим итогом.
Пример значения цели: автоцель «отправка формы» — 286 целевых визитов / 1 184 достижения в сводке целей. Это разные метрики, а не 1 184 лида.
Исторический срез отдельно: на первичном экране за январь 2021 — 19 238 посетителей и доля поиска 58,1%. Эти цифры относятся только к указанному месяцу; не выдаю их за текущую посещаемость или эффект пересборки 2026 года.
04 / Доказательная база
Первичный экран и две реконструкции — три разных уровня подтверждения
Историческая сводка Яндекс.Метрики показывает конкретный период. Отдельные рабочие экраны систематизируют настройки целей и конфигурацию формы. Реконструкции не являются исходными историческими скриншотами.
Реальная сводка Яндекс.Метрики
Посетители, источники трафика, глубина, время на сайте и конверсионные блоки — только за 1–31 января 2021 года.
Граница: один календарный месяц, не динамика всего проекта. Для этого PNG отмечено несовпадение SHA с хостинговым листингом: байтовое тождество не заявляется.
Открыть первичный экран ↗События и цели Метрики
Рабочая композиция со значениями разных типов действий: форма, корзина, контакты и начало оформления заказа.
Граница: значения целей не означают число лидов или продаж. Мини-графики на реконструкции не являются исторической помесячной выгрузкой.
Открыть рабочий экран ↗Форма «Уточнить наличие»
Поля и согласие, сохранение отправок, email-уведомления, защита от спама и адаптивное представление.
Граница: экран подготовлен по реальной конфигурации и локальным стилям; он показывает реализацию сценария, но не доказывает рост конверсии.
Открыть конфигурацию ↗Область подтверждения: наличие сценария уточнения, учёт событий и исторический срез посещаемости. По этим материалам нельзя устанавливать число оплаченных заказов, выручку или эффект пересборки. Данные разных периодов и типы экранов не объединяются в одну статистику.