CMS Catalog - Ecommerce

[lsnull]

Всем привет.
Есть легкая CMS Каталога + Корзина товаров и разный под функционал для заказов, добавления в корзину, отслеживание статуса, продажи, покупки, баланс и так далее.

Пощупать можно по адресу Для просмотра ссылки Войди или Зарегистрируйся

Кого заинтересовал, пишите комменты.

Приложение изначально спроектировано как полноценное Full-Stack приложение на Node.js (Express + React + Vite).
Вот как устроена эта архитектура:

• Режим Node.js (Основной Когда приложение запускается на сервере Node.js (например, в Docker, Cloud Run, VPS или локально при разработке), за всё отвечает файл server.ts. Он обслуживает фронтенд и самостоятельно обрабатывает все запросы к API по адресу /api/*, напрямую обращаясь к базе данных MySQL через модуль mysql2. В этом режиме PHP вообще не требуется и никак не задействуется.
• Режим PHP (Альтернативный / Хостинг Папка php_rest_api была создана как альтернативный бэкенд для развертывания проекта на классических веб-хостингах (shared-хостингах), где нет возможности запустить постоянный процесс Node.js, но есть поддержка PHP и MySQL.

Благодаря добавленному глобальному перехватчику fetch в src/main.tsx, приложение определяет окружение автоматически:

• Если это локальная среда разработки или облачный контейнер (Node.js), запросы идут напрямую на бэкенд Express (/api/*).
• Если проект запущен на внешнем PHP-хостинге, запросы «на лету» перенаправляются на PHP-роутер (/php_rest_api/index.php/api/*).

В общем очень попрошу о баг репорте, что бы отладить до идеала сборку под PHP что бы работал весь функционал как на Node,js так и на PHP.Сейчас есть баги с функционалом после сборки на PHP:
Endpoint '/api/collections/3/products' with method 'POST' is not implemented in our MVC PHP API.

Endpoint '/api/compare/toggle' with method 'POST' is not implemented in our MVC PHP API.

1. Исправление Избранного и Сравнения товаров (Wishlist & Comparisons)​

• Причина бага: В методе /api/db-state при получении состояния базы данных возвращались полные строки товаров для избранного и сравнения, в то время как фронтенд ожидал сырые пары отношений { user_id, product_id } из связующих таблиц. Из-за отсутствия этих полей фильтрация на клиенте data.favorites.filter((f) => f.user_id === userKey) всегда возвращала пустой массив. Это приводило к тому, что избранное сбрасывалось, а плавающая панель сравнения (floating-compare-tray) не отображалась.
• Решение:
  • В модели /public/php_rest_api/models/Product.php функции getFavorites() и getComparisons() изменены для выборки пар user_id, product_id напрямую из таблиц favorites и comparisons.
  • В контроллере /public/php_rest_api/controllers/ProductController.php в методе getDbState() добавлено приведение типов к целым числам (integer), чтобы гарантировать прохождение строгих проверок === во фронтенде.
  • Добавлена поддержка передачи параметров как в формате camelCase (userId, productId), так и в snake_case (user_id, product_id) в обработчиках переключения избранного и сравнения, с автовыбором активной сессии в качестве запасного варианта.

2. Сохранение Основных характеристик (Custom Values / Characteristics)​

• Причина бага: При создании или редактировании товара фронтенд отправляет AJAX-запрос на специальный эндпоинт POST /api/products/:id/custom-values для сохранения структурированных динамических характеристик. Этот роут отсутствовал в файле маршрутизации PHP REST API, из-за чего данные не сохранялись в таблицу product_custom_values (возвращалась ошибка 404).
• Решение:
  • В файле маршрутизатора /public/php_rest_api/index.php зарегистрирован роут POST products/:id/custom-values.
  • В контроллере /public/php_rest_api/controllers/ProductController.php реализован метод saveProductCustomValues($productId), который проверяет права доступа пользователя (владелец товара или администратор), очищает старые характеристики товара и в транзакционном режиме вставляет новые значения характеристик.

Часть уже пофиксил, расширил api для сборки