Скрипт интернет-магазина PHP MySQL

Скрипт интернет-магазина на PHP и MySQL закрывает путь «товар → корзина → заказ» без WooCommerce. Это отдельный движок на своём хостинге: каталог, карточка, корзина, checkout, админка заказов. Я ставлю его клиентам, когда нужен свой домен и white label, а не подписка на конструктор с процентом с оборота.

Проверка первого заказа — в мануале магазина. Ниже — что должно быть в продукте и как не перепутать с «просто каталогом».

Минимальный контур, без которого это не магазин

• Категории и карточка с ценой, фото, постоянным URL.
• Остаток (хотя бы простой): ноль не должен уходить в заказ.
• Корзина с пересчётом суммы при смене количества.
• Checkout: контакты, способ доставки, способ оплаты.
• Запись заказа в админке даже если почта ещё не настроена.

Витрина без корзины — это каталог. Путать термины в брифе опасно: заказчик ждёт оплату, а получает галерею.

Когда не брать WordPress

WP + Woo удобны экосистемой плагинов. Ломаются на обновлениях, теме и конфликте кэша. Отдельный PHP-скрипт проще откатить целиком (файлы + дамп). Берите скрипт, если:

1. Нужен свой бренд без витрины «powered by…» в критичных местах.
2. Каталог относительно стабильный, не 50 тысяч SKU с омниканалом.
3. Хотите контролировать оплату и вебхуки сами — см. ЮKassa.
4. Не хотите платить процент SaaS-платформе с каждого заказа.

Админка после установки: первый день

1. Создать 2–3 категории с нормальными названиями.
2. Завести товар с фото, ценой, артикулом, остатком > 0.
3. Если есть варианты размер/цвет — завести SKU. Практика: варианты.
4. Пройти checkout тестовым покупателем до статуса «новый» в заказах.
5. Проставить зоны доставки и самовывоз — доставка.
6. Подключить оплату в тестовом режиме, потом боевые ключи.

Пока шаг 4 не зелёный, рекламу и «откроемся завтра» не обещаю. Checkout детально — оплата.

Заказ как объект системы

В админке заказ должен содержать:

• состав (товар, вариант, цена на момент покупки, количество);
• сумму, скидку по промокоду, доставку;
• контакты и адрес;
• статус оплаты и статус сборки/отправки;
• историю смены статусов — кто и когда ткнул.

Цена «как сейчас в каталоге» при переоткрытии старого заказа — ошибка. Фиксируйте снэпшот строки. Промокоды — отдельный разбор.

Склад и варианты

Если продаёте футболки — без размерной сетки получите возвраты и ручные переписки. Остаток на уровне варианта, не «общий 100 на все размеры». При оплате онлайн списывайте после успешного вебхука или резервируйте на время сессии — решите одну модель и не мешайте обе. Иначе два клиента купят последний размер M.

Связка с хостингом

PHP-версия по требованиям скрипта, MySQL/MariaDB, SSL, почта для писем «заказ принят» (или хотя бы очередь писем). Бэкапы до обновлений. На VDS — отдельный vhost, не складывать магазин в подпапку чужого сайта «на время».

Ecommerce на своём сервере шире описан в ecommerce-скрипте. Если нужен только прайс без оплаты — снова каталог, не этот продукт.

Чеклист перед сдачей клиенту

• Тестовый заказ виден без фильтра в админке.
• Нулевой остаток нельзя положить в корзину.
• Промокод на скидку отражается в заказе.
• Способ доставки меняет сумму ожидаемо.
• Онлайн-оплата в тесте меняет статус; отмена не помечает оплаченным.
• Карточка товара открывается по ЧПУ с телефона.

Скрипт интернет-магазина на PHP MySQL — это не тема для блога, а контур продажи. Замкните каталог, корзину и заказ; потом наращивайте оплату, доставку и акции. Иначе витрина будет красивой, а касса — в мессенджере у менеджера, как до установки скрипта.

Роли людей вокруг скрипта

На запуске обычно три роли, даже если их играет два человека:

• контент — карточки, фото, цены;
• менеджер заказа — статусы, звонки, трек-номера;
• админ — ключи оплаты, бэкапы, пользователи.

Пароль админа не vivёт в общем чате. После настройки ЮKassa тестовые ключи выключаю явно. Менеджеру достаточно экрана заказов и товаров; доступ к правке шаблонов писем и cron ему не нужен. Когда кто-то «на минуту зашёл в админку поправить цену» под общим логином — потом не найти, кто снёс остаток.

Что я показываю на приёмке заказчику

1. Карточку товара на телефоне.
2. Путь до заказа с самовывозом.
3. Этот заказ в админке с составом.
4. Смену статуса и (если успели) тестовую оплату.
5. Где лежит бэкап и кто его делает.

Если на приёмке вместо этого крутят только анимацию баннера — магазин не сдан. Баннер клеится за час; контур заказа либо есть, либо нет. Документацию доступов отдаю владельцу домена списком: хостинг, DNS, админка, касса, почта. Скрипт без доступов у владельца — бомба замедленного действия на момент смены подрядчика.

Контент и скорость витрины

Магазин на PHP умирает не только от дырявого checkout — ещё от тяжёлых фото и пустых категорий в меню. Перед сдачей выключаю пустые разделы, жму превью, проверяю карточку на LTE. Юридические страницы оплаты и возврата — короткие, без копипасты чужих оферт слово в слово. Покупателю важно понять срок доставки и способ оплаты, а не читать роман.

Скрипт интернет-магазина PHP MySQL имеет смысл, когда команда готова жить в заказах админки. Если продажи всё равно уйдут в мессенджер навсегда — подождите с внедрением или честно используйте каталог. Когда готовы замкнуть оплату и доставку — ставьте движок, прогоняйте первый заказ и только потом включайте рекламу. Так дешевле, чем чинить воронку под горящим бюджетом.

Связка с учётом

Даже простой магазин на PHP быстро упирается в вопрос: как заказы попадают в 1С/таблицу/складской учёт. На старте хватает выгрузки CSV и дисциплины менеджера. Главное — не вести параллельную «истинную» таблицу цен, которая разъедется с сайтом. Скрипт интернет-магазина PHP MySQL должен оставаться источником витринных цен и остатков, пока вы не построите нормальный обмен.

Если обмен появится позже, заранее держите стабильные артикулы и не переиспользуйте id товаров. Иначе интеграция превратится в археологию. Закройте контур заказа на сайте, вычистите каталог, настройте оплату — и только потом усложняйте учёт. Обратный порядок плодит двойную работу и ошибки в чеках.