01Цену определяет ваш сервер, а не браузер
Конфигуратор показывает сумму, пока клиент выбирает, но число, с которым записывается заказ, пересчитывается на сервере только из самого выбора. Сумма, присланная браузером, попросту игнорируется. Деньги хранятся целыми в младших единицах, поэтому длинный заказ никогда не расходится на копейку между счётом и заказом.
02Загруженные фотографии не являются вложениями медиатеки
Они попадают в каталог, имя которого нельзя угадать, защищённый сразу четырьмя способами: правилом .htaccess, файлом web.config для IIS, файлом index.php и правами доступа, которые не дают прочитать их никому, кроме самого сайта. Файл принимается по тому, чем являются его байты, а не по тому, что заявляет его имя: исполняемый файл, переименованный в .jpg, отклоняется на пороге. Публичного URL им не выдают никогда.
03Один выход — и он проверяет, кто стучит
Каждая фотография и каждый эскиз отдаются через единственный шлюз. Вашу команду пропускает право на редактирование заказов WooCommerce, клиента — подписанная ссылка, которая сверяется именно с этим заказом и ни с каким другим. Ссылка, созданная для одного заказа, не откроет файл другого, а подделанная не откроет ничего.
04Клиент одобряет, не создавая учётную запись
Страница одобрения открывается прямо из письма: без входа, без пароля, без корзины. Просить человека зарегистрироваться прежде, чем он сможет посмотреть собственный эскиз, — самый верный способ потерять это одобрение. Ссылка несёт свои полномочия сама, подписана и имеет срок; страница никогда не кэшируется, поэтому эскиз одного клиента не может быть показан кому-то другому.
05Правки до «да», затем производство и больше никаких изменений
До одобрения клиент может просить правку столько раз, сколько потребуется, и каждая просьба записывается к заказу. После одобрения форма правок исчезает — и сервер тоже отказывает в запросе, а не только экран. По турецким правилам дистанционной торговли персонализированный товар не даёт права отказа после изготовления, поэтому момент, когда клиент с этим соглашается, фиксируется вместе с одобрением.
06Четыре состояния заказа, которые движутся только вперёд
Моделирование, ожидание одобрения, печать, готово. Что за чем может следовать, записано списком разрешённых переходов, а не запрещённых: шаг, о котором никто не подумал, по умолчанию отклоняется, а не разрешается молча. Состояния — это настоящие статусы заказов WooCommerce, поэтому они появляются в списке заказов, в отчётах и в ваших нынешних фильтрах.
07Очередь, которая говорит, что просрочено, а не просто что открыто
Экран мастерской сортирует открытые заказы по времени ожидания и отмечает красным те, что вышли за обещанный срок: обычно двадцать четыре часа, шесть — для срочного заказа. Оператор загружает эскиз с того же экрана, и письмо клиенту уходит тем же действием; второго места, где нужно не забыть нажать, нет.
08Четыре письма, отправляемые самим WooCommerce
Заказ принят, эскиз готов, одобрение записано, отправлено. Все они проходят через собственный почтовый шаблон вашего магазина, поэтому выглядят как остальная ваша почта, а не как приделанное сбоку. Ссылка на одобрение встречается в письме дважды — кнопкой и обычным текстом, — потому что некоторые почтовые клиенты кнопку не рисуют.
09Фотографии не остаются навсегда
Ежедневная задача удаляет загрузки и эскизы завершённых заказов по истечении срока хранения, который задаёте вы: из коробки — шестьдесят дней. Заказ, его сумма и запись об одобрении остаются; фотография клиента — нет. Хранить фотографию ребёнка на сервере магазина бессрочно — это ответственность, а не возможность.
010Он не воюет с вашим кэшем
И конфигуратор, и страница одобрения отключают кэширование страницы для себя — на языке, который одинаково понимают LiteSpeed, WP Rocket и W3 Total Cache, — и вдобавок отправляют заголовки no-store. Закэшированный конфигуратор отправляется с устаревшим токеном и молча падает; закэшированная страница одобрения показывает эскиз одного клиента следующему посетителю. Здесь невозможно ни то, ни другое.