Добрый вечер, коллеги Есть серьезная проблема с одним из сайтов на Wordpress + WooCommerce. Заключается она в том, что пользователи иногда не могут совершить оплату через один из платежных шлюзов (местные банки) - после оформления заказа, вместо переадресации на страницу банка, получают белый экран. А теперь о странном - ошибка не попадает в логи. Логирование включено и на уровне PHP, и на уровне WP (debug mode). Пробовал вызывать ошибки намеренно - логируются. Проверял файлы на bom - тоже все ок. Обновлял все, что связано с шаблоном, плагинами и Wordpress, менял модули оплаты - без результата. Менял хостинг. Сейчас навесил свой обработчик ошибок и завершающую функцию - жду результатов. Может у кого есть опыт отладки этой черной магии? Буду благодарен за любую наводку/метод.
А в адресной строке у пользователей что? Может быть переадресация проходит успешно, а банк отвечает белым экраном...
Вангую, что косяк в платежном шлюзе, либо в обработке его ответа. Мб где-то таймаут ловится. Веб асинхронен, это надо учитывать. То есть, с точки зрения приложения, ошибки, которая стоила бы логгирования, не происходит и, технически, все работает правильно.
В строке браузера урл чекаута. Опираюсь исключительно на информацию, которую предоставляют пользователи, которая зачастую довольно противоречива. Например, один из пользователей прислал скриншот ошибки - белый экран, а в правом нижнем углу торчит виджет JivoChat, который подключается у нас в (!) футере. То ли появляется какой-то оверлей, то ли проблема буфера... Ну или пользователь факапнул страницу перед тем как сделать скриншот. Были такие мысли. Там вообще не редирект, а js код, отправляющий в банк скрытую форму. Из-за белого экрана форма не отправляется, связи с банком не происходит. Логирование включено и работает.
Закономерности нет, или она очень сложная. Баг не воспроизводится. Хостер наконец предоствил нам access_log - размер тела ответа чекаута составляет примерно 18-19кб, в независимости от того, прошел заказ или нет. Похоже, что php отрабатывает без проблем. Попробую сохранять вывод в файлы и посмотрю что nginx отдает пользователям. Но это уже совсем другая история.
Попробуй протестировать с разным троттлингом сети. Ставлю на то, что где-то имеет место рассинхрон, кто-то пытается обработать данные, которые не успели придти, либо отослать что-то, что не успел получить.
Может быть, дело в блокировщике рекламы в браузере или антивирусному ПО сайт кажется подозрительным (ssl-сертификат не в порядке и т.п.).
@Fell-x27 Отключил кэш браузера и включил Slow 3G троттлинг. Сделал пару заказов через проблемные банки - страница грузится ~30 секунд, но в конечном счете все ок, переадресация проходит. Интересные догадки, но с блокировщиком рекламы проблем нет - у меня у самого он стоит, да и на сайте нет никакой рекламы. Под паттерны блокировщиков урлы тоже подпадать не должны. Что касается антивирусов - пользователь не получает сообщение об ошибке. А сертификата у нас нет, работаем по http.
Финансовую информацию клиент вводит уже на странице банка. В будущем обязательно подключим SSL, но сейчас его наличие некритично.
А есть клиенты с регулярными багами? Если есть, опрашивайте все, вплоть до разрешения моника и пробуйте восстановить. Поглядите, что у него в адресной строке написано. Мб какой-то запрос тупо ломается. Попробуйте воспроизвести у себя условия максимально близко. P.S. А потом окажется, что проблема вообще где-то на уровне магистральных проксей или где-то DNS чудит на маршруте. --- Добавлено --- А еще у клиента может стоять достаточно умный Nod32, который может быть достаточно умен, чтобы херить формы ввода, если запрос на их получение был сделан не по https... Он еще любит перехватывать страницы с платежками и открывать их самостоятельно через встроенный браузер на базе хромцов. Типа супер-защищенный. То есть вот предела у уровня эзотеричности проблемы просто нет.
Нет, проблема всплывает рандомно, у разных пользователей (у одних firefox, у других chrome, у третьих что-то еще). В логах видно, как они, столкнувшить с ошибкой начинают обновлять страницу "пост-чекаута". Потом возвращаются в корзину или каталог и пробуют заполнить форму чекаута снова. Но обычно это не помогает. Мы стараемся мониторить такие кейсы и связываемся с пользователями сразу, как видим что у них проблемы - советуем выбрать другой метод оплаты (не шлюз - это всегда помогает) или высылаем счет, чтобы оплачивали не через сайт, а напрямую из банка. Но такой подход возможен не всегда, поэтому некоторые пользователи после нескольких неудачных попыток уходят с сайта, и возвращаются через, скажем, час, и пробуют снова - и, вуаля, все отрабатывает без проблем. Грешил на производительность сервера, но до этого пробовали впс - не помогло. А сейчас у нас шаред, и не самый дешевый пакет. php 7.1 fpm, nginx, opcache. На уровне приложения тоже есть кэш + жмем скрипты и стили. По метрикам "присядов" сервера не видно, в логах тоже отмечено, что страница "пост-чекаута" проблемного заказа загружена за 0.7 сек, не больше. Так что это не тот случай, когда на серверах начинается массовое обновления wordpress и ложится почти весь хостинг. "То есть вот предела у уровня эзотеричности проблемы просто нет." - пожалуй, добавлю эту фразу в свою копилку. Очень точно сказано. --- Добавлено --- Да там и с кодом ничего не скажешь.
Если не секрет вышли ссылку сайта в ЛС. Часто баги ищу на стороне пользователя, может и тут что найду)
логирование на сервере. нельзя залогировать запрос, который не дошел до сервера. я бы посмотрел на JS создающий тот самый запрос, которого не происходит в итоге. ставлю рубль на race condition в джаваскрипте. --- Добавлено --- и ещё, я бы сделал graceful degradation: страница должна быть осмысленной для пользователя, когда джаваскрипт по каким-то причинам на*бнулся. не всё должно рендериться на клиенте, что-то таки должно быть изначально, что позволит двигаться дальше.
Запрос доходит и логируется. Не происходит выполнение js кода, который отправляет форму с данными в банк. Код там очень простой: Код (Text): jQuery(function($) { jQuery('#bank_form').submit(); }); Graceful degradation у нас тоже есть, только у нас оно называется progressive enchancement Если js у пользователя отключен, или отвалился, то он руками жмет кнопку отправки формы. А вот насчет race condition я бы поспорил, ибо js однопоточен. Спасибо за желание помочь, но никнейм действительно стоит сменить А вообще, думаю помощь больше не потребуется. Вчера меня осенило, и я начал сохранять html-копии страниц пост-чекаута. Сегодня прилетел первый дефектный заказ, и я наконец смог увидеть то, что видел пользователь. Почти. Копия была в порядке и переадресовывала на страницу банка без проблем. И тут я вспомнил, как у нас один раз отвалился весь интранет из-за упавшего googleapis. Похоже, что проблема именно в нем. В итоге перенес все шрифты на сервер сайта, теперь наблюдаю.
Какие ЭПС не работают? У некоторых SSL нужен на сайте + домен должен быть НЕ третьего уровня. Что в файле обработчике у вас?
Swedbank и SEB. Я не в РФ. Домен не третьего уровня. О каком файле обработчике идет речь? Обработка результата оплаты? До нее не доходит.
если что, то нет никакой информации о том, что этот человек является хакером. Я это написал в шутку. Просто ситуация показалась забавной. А так, каждый разраб немного хакер. Если я где-то спалю, что мои коменты выводятся без htmlspecialchars, то вряд ли удержусь от возможности влупить огромную на весь экран надпись "Админ лох".
где именно "грейсфул деградейшн" — submit это отправка. а проблема у тебя со страницей возврата. ты писал, что она либо совсем пустая, либо какие-то куски на ней. не потерял ли ты нить? --- Добавлено --- простой жсной асинхронности достаточно для race condition. без разницы как это на уровне процессов устроено — если переменная может быть не задана в момент использования по причине того, что какой-то запрос выполнился быстрее/медленнее чем предполагалось,
Давай еще раз разложу все по полочкам. Пользователь заполняет форму оформления заказа (чекаут), отправляет ее, попадает на страницу "переадресации" в банк (именно ее я и называю страницей пост-чекаута). На этой странице находится скрытая форма и жс код, который отправляет эту форму в банк - именно таким образом пользователь попадает на страницу банка. До обработки результата процесса оплаты не доходит. Т.н. graceful degradation тут в том, что в случае отключенного js пользователь отправляет эту форму сам нажатием кнопки "Перейти в банк", в противном случае, js делает это за пользователя. Так вот, на этой самой странице "пост-чекаута" не происходит выполнение этого жс кода, который отправляет пользователя на страницу банка. В жалобах пользователи пишут, что видят белую страницу (т.е. и кнопку нажать они не могут). Теперь, имея копию html-кода страницы пост-чекаута каждого совершенного заказа, я вижу, что на самом деле с этой страницей все хорошо, форма рендерится, жс код выполняется, и проблема, скорее всего, в том, что один из <link rel="stylesheet" /> запросов в шапке блокирует загрузку всей страницы, когда источник лежит или отдает стили слишком медленно. Но это не точно. Про race condition я тебя понял, и нет, это не тот случай --- Добавлено --- Я тоже написал это в шутку