# Выпуск floratte.by

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

## Проверка перед выпуском

Из корня проекта:

```powershell
& 'C:\OSPanel\modules\php\PHP_8.1\php.exe' tools/release-check.php --json
& 'C:\OSPanel\modules\php\PHP_8.1\php.exe' tools/release-check.php --base-url=http://flowers.local
& 'C:\OSPanel\modules\php\PHP_8.1\php.exe' tools/release-check.php --base-url=http://127.0.0.1:8097
```

На сервере после размещения:

```sh
php tools/release-check.php --json --base-url=https://floratte.by
```

Проверка только читает файлы и БД; запросы к БД выполняются в транзакции `READ ONLY`. По явному `--base-url` выполняются GET-запросы страниц и закрытых путей. Содержимое ответов закрытых файлов, пароли, логины SMS-провайдера, данные покупателей, номера заказов и тексты исключений не выводятся. Заказы, платежи, SMS и миграции не запускаются. Коды выхода: `0` — автоматические проверки без ошибок, `1` — найдены блокеры, `2` — ошибка параметров или выполнения. Даже `0` не подтверждает ручные проверки и публикацию.

Проверяются PHP и расширения, запись в служебные каталоги, отдельная учётная запись БД, обязательные таблицы и поля, владелец админки, реальные товары и их изображения, способы получения/оплаты, режим магазина, сведения продавца, домен, готовность индексации, WEBPAY и SMS. Пропуск юридической проверки показывается явно и не считается её завершением.

## Сборка

```powershell
.\tools\build-release.ps1 -Plan
.\tools\build-release.ps1
```

Архив и его SHA-256 сохраняются в закрытый каталог `storage/releases/`. `-Plan` только перечисляет будущие файлы. Повторная сборка не перезаписывает существующий архив. Каждый архив содержит `release-manifest.json` с SHA-256 и размером каждого файла. Состав и времена ZIP-записей фиксированы: одинаковые исходники дают одинаковый архив.

Включены корневые PHP-точки входа, `.htaccess`, приложение, шаблоны, публичные изображения/шрифты/скрипты, лицензии, базовая схема и ограниченный набор нужных на сервере CLI-команд. `config/app.php` формируется заново только из несекретных значений и переменных окружения. `config/local.example.php` — пустой шаблон подключения.

**Не включены:** `config/local.php`, `config/local-admin.txt`, настройки WEBPAY/RocketSMS, `.env`, существующее содержимое `storage`, резервные копии БД, логи, личные данные, тесты, временные файлы, исходные Excel/ZIP, локальные серверы и инструменты импорта. Не загружайте весь каталог разработки на хостинг. Код архива не заменяет перенос каталога и бизнес-настроек из БД.

## Требования к хостингу

- Apache 2.4 с `mod_rewrite`, разрешённым `.htaccess` и PHP. DocumentRoot — корень архива, где находятся `index.php` и `.htaccess`, а не папка `public`.
- Поддерживаемая ветка PHP, предпочтительно 8.4 с актуальными обновлениями. Локальная версия 8.1 совместима с текущими тестами, но её поддержка закончилась. После выбора версии на хостинге повторите проверки приложения. Сроки веток: [PHP Supported Versions](https://www.php.net/supported-versions.php).
- Расширения `pdo_mysql`, `mbstring`, `fileinfo`, `gd` с WebP, `curl`, `openssl`, `dom`, `simplexml`; MariaDB/MySQL с InnoDB и `utf8mb4`.
- Отдельный пользователь БД с доступом только к базе магазина. Не переносите локального `root`. Для миграций нужны права создания/изменения схемы; рабочему приложению достаточно необходимых прав на чтение/запись данных.
- Настоящий HTTPS-сертификат для `floratte.by`; перенаправление HTTP и альтернативного имени домена на один HTTPS-адрес на уровне виртуального хоста. Если TLS завершает reverse proxy, веб-сервер должен передавать PHP корректный признак HTTPS: cookies сеанса используют этот признак. Не доверяйте произвольному заголовку клиента.
- `display_errors=Off`, `log_errors=On`, закрытый журнал вне публичного доступа. Отдельные резервные копии БД и загруженных фото с проверкой восстановления.
- Запись PHP-пользователю в `public/assets/uploads`, `storage` и `config` (последняя нужна для сохранения настроек платёжного/SMS-провайдера). Ограничьте доступ правами пользователя приложения, без `chmod 777`.

Важна именно работа серверных правил: Apache игнорирует `.htaccess`, если соответствующие переопределения запрещены. [Документация AllowOverride](https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride). На nginx нужно самостоятельно перенести все ограничения и маршруты; этот архив не содержит проверенной конфигурации nginx.

## Перенос на сервер

1. Создайте отдельную БД и защищённый тестовый адрес на выбранном хостинге. На время подготовки закройте доступ паролем на уровне сервера. Выложите архив в новую папку, проверьте его SHA-256 и manifest.
2. Создайте `config/local.php` по примеру, задайте реквизиты БД сервера. Секреты вводятся непосредственно на сервере или через защищённое окружение. Не переносите файл локального пароля администратора.
3. Перенесите БД отдельным защищённым экспортом и проверьте восстановление в **пустую** БД. Полный перенос сохраняет администраторов, настройки, товарные связи и историю; он также переносит персональные данные и тестовую историю, поэтому требует отдельного решения владельца о составе. Базовый `database/schema.sql` не содержит каталог, админов и все добавочные миграции и не является готовым дампом магазина. Локальный `tools/install.php` с демонстрационными товарами намеренно исключён из релиза.
4. Создайте резервную копию БД сервера. При обновлении схемы используйте CLI-команды из архива; `migrate-customer.php --apply` сначала создаёт защищённую копию и проверяет сохранность прежних данных. `migrate-schema.php` выполняет общие добавочные миграции и требует предварительной резервной копии.
5. Сначала выполните `php tools/release-check.php --json`. Исправьте ошибки. Проверьте вход владельца и смените пароль при переносе локальной БД. Не открывайте каталог `config` через HTTP.
6. В админке проверьте название продавца, реквизиты, условия, цены и остатки, самовывоз, города и способы оплаты. Не используйте флажки пропуска проверки как отметку юридической готовности. Настройки индексации и платёжного провайдера проверяются отдельно.
7. Задайте ключи WEBPAY на сервере, выполните согласованный тест платежа и обратного уведомления в Sandbox, затем отдельно подключите рабочую среду. Возврат браузера не подтверждает оплату — должен обновиться серверный статус после проверенного уведомления.
8. Настройте RocketSMS, зарегистрированного отправителя и разрешения в админке. Проверьте OTP и напоминание на согласованном номере владельца. **Не копируйте эти реквизиты в публичный архив и не запускайте проверочные отправки без разрешения.** До завершения настройки оставьте отправку выключенной.
9. Для разрешённых SMS-напоминаний настройте cron раз в минуту: `* * * * * /path/to/php /path/to/shop/tools/sms-worker.php run >> /private/path/sms-worker.log 2>&1`. Сначала подтвердите готовность настроек и получателя. Сам cron выполняет реальные отправки по очереди, в отличие от `release-check.php` и `sms-status.php`. Проверьте сигнал планировщика в админке на новом сервере.
10. На рабочем домене выполните `php tools/release-check.php --base-url=https://floratte.by`, проверьте каталог → добавление → выбор оформления/продолжения → доставку → оплату. Тестовый реальный заказ делается только с владельцем и согласованным способом оплаты; после проверки обработайте или отмените его через админку.
11. Только после проверки данных, HTTPS, заказа и документов откройте публичный доступ/индексацию. Проверьте `canonical`, robots и заполненный sitemap на домене. Добавьте собственность в Google Search Console и Яндекс Вебмастер, подтвердите её и отправьте `https://floratte.by/sitemap.xml`. Снятие `noindex` не гарантирует индексацию и позиции.

## Откат и контроль после запуска

Сохраните предыдущую папку кода и согласованную копию БД до переключения. При ошибках сначала временно закройте оформление, сохраните поступившие заказы, затем переключайте код. Не восстанавливайте старый дамп поверх новых заказов: восстановление БД требует сверки новых записей. После переключения повторите HTTP-проверку и убедитесь, что изображения и закрытые пути работают как ожидалось.

Следите за серверными ошибками, неотвеченными заказами/обращениями, неподтверждёнными оплатами и ошибками планировщика. Хранение резервных копий и журналов с персональными данными должно соответствовать утверждённым правилам магазина. В первые дни проверьте отчёты индексации и реальные поисковые запросы; новые SEO-правки оценивайте по данным, без обещаний первого места.

## Telegram при переносе

Запустите добавочную миграцию чата до включения новых обработчиков заказов. Для первого запуска в новой среде настройте бота через админку; при частном полном переносе БД сохраните также закрытый ключ шифрования storage/private/lafleur-chat.key. Исходящий обработчик tools/telegram-worker.php нужен даже при webhook. Подробнее: [telegram-chat.md](telegram-chat.md). Сборка содержит исходники и миграцию, но не токен, ключ и историю переписки.