За последние 24 часа нас посетили 15916 программистов и 1578 роботов. Сейчас ищут 644 программиста ...

Отладка сайта

Тема в разделе "PHP для профи", создана пользователем phpdev1, 10 сен 2017.

  1. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Добрый вечер, коллеги

    Есть серьезная проблема с одним из сайтов на Wordpress + WooCommerce. Заключается она в том, что пользователи иногда не могут совершить оплату через один из платежных шлюзов (местные банки) - после оформления заказа, вместо переадресации на страницу банка, получают белый экран.

    А теперь о странном - ошибка не попадает в логи. Логирование включено и на уровне PHP, и на уровне WP (debug mode). Пробовал вызывать ошибки намеренно - логируются. Проверял файлы на bom - тоже все ок. Обновлял все, что связано с шаблоном, плагинами и Wordpress, менял модули оплаты - без результата. Менял хостинг. Сейчас навесил свой обработчик ошибок и завершающую функцию - жду результатов.

    Может у кого есть опыт отладки этой черной магии? Буду благодарен за любую наводку/метод.
     
  2. TeslaFeo

    TeslaFeo Старожил

    С нами с:
    9 мар 2016
    Сообщения:
    2.984
    Симпатии:
    759
    А в адресной строке у пользователей что?
    Может быть переадресация проходит успешно, а банк отвечает белым экраном...
     
  3. [vs]

    [vs] Суперстар
    Команда форума Модератор

    С нами с:
    27 сен 2007
    Сообщения:
    10.557
    Симпатии:
    631
  4. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Вангую, что косяк в платежном шлюзе, либо в обработке его ответа. Мб где-то таймаут ловится. Веб асинхронен, это надо учитывать. То есть, с точки зрения приложения, ошибки, которая стоила бы логгирования, не происходит и, технически, все работает правильно.
     
  5. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    В строке браузера урл чекаута. Опираюсь исключительно на информацию, которую предоставляют пользователи, которая зачастую довольно противоречива. Например, один из пользователей прислал скриншот ошибки - белый экран, а в правом нижнем углу торчит виджет JivoChat, который подключается у нас в (!) футере. То ли появляется какой-то оверлей, то ли проблема буфера... Ну или пользователь факапнул страницу перед тем как сделать скриншот.

    Были такие мысли. Там вообще не редирект, а js код, отправляющий в банк скрытую форму. Из-за белого экрана форма не отправляется, связи с банком не происходит.

    Логирование включено и работает.
     
    #5 phpdev1, 11 сен 2017
    Последнее редактирование: 11 сен 2017
  6. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Ну а воспроизводимость у бага есть? Закономерность появления?
     
  7. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Закономерности нет, или она очень сложная. Баг не воспроизводится.

    Хостер наконец предоствил нам access_log - размер тела ответа чекаута составляет примерно 18-19кб, в независимости от того, прошел заказ или нет. Похоже, что php отрабатывает без проблем. Попробую сохранять вывод в файлы и посмотрю что nginx отдает пользователям. Но это уже совсем другая история.
     
  8. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Попробуй протестировать с разным троттлингом сети. Ставлю на то, что где-то имеет место рассинхрон, кто-то пытается обработать данные, которые не успели придти, либо отослать что-то, что не успел получить.
     
    Okto нравится это.
  9. Okto

    Okto Новичок

    С нами с:
    19 авг 2017
    Сообщения:
    12
    Симпатии:
    9
    Может быть, дело в блокировщике рекламы в браузере или антивирусному ПО сайт кажется подозрительным (ssl-сертификат не в порядке и т.п.).
     
  10. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    @Fell-x27
    Отключил кэш браузера и включил Slow 3G троттлинг. Сделал пару заказов через проблемные банки - страница грузится ~30 секунд, но в конечном счете все ок, переадресация проходит.

    Интересные догадки, но с блокировщиком рекламы проблем нет - у меня у самого он стоит, да и на сайте нет никакой рекламы. Под паттерны блокировщиков урлы тоже подпадать не должны. Что касается антивирусов - пользователь не получает сообщение об ошибке. А сертификата у нас нет, работаем по http.
     
  11. TeslaFeo

    TeslaFeo Старожил

    С нами с:
    9 мар 2016
    Сообщения:
    2.984
    Симпатии:
    759
    можно гадать бесконечно.
    без кода ничего конкретного сказать нельзя.
     
  12. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Воу воу воу, как так? Платежи без SSL? Ну хотя бы Lets Encrypt то можно прикрутить.
     
    AlexProg нравится это.
  13. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Финансовую информацию клиент вводит уже на странице банка. В будущем обязательно подключим SSL, но сейчас его наличие некритично.
     
  14. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    А есть клиенты с регулярными багами? Если есть, опрашивайте все, вплоть до разрешения моника и пробуйте восстановить. Поглядите, что у него в адресной строке написано. Мб какой-то запрос тупо ломается. Попробуйте воспроизвести у себя условия максимально близко.

    P.S. А потом окажется, что проблема вообще где-то на уровне магистральных проксей или где-то DNS чудит на маршруте.
    --- Добавлено ---
    А еще у клиента может стоять достаточно умный Nod32, который может быть достаточно умен, чтобы херить формы ввода, если запрос на их получение был сделан не по https... Он еще любит перехватывать страницы с платежками и открывать их самостоятельно через встроенный браузер на базе хромцов. Типа супер-защищенный.

    То есть вот предела у уровня эзотеричности проблемы просто нет.
     
  15. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Нет, проблема всплывает рандомно, у разных пользователей (у одних firefox, у других chrome, у третьих что-то еще). В логах видно, как они, столкнувшить с ошибкой начинают обновлять страницу "пост-чекаута". Потом возвращаются в корзину или каталог и пробуют заполнить форму чекаута снова. Но обычно это не помогает. Мы стараемся мониторить такие кейсы и связываемся с пользователями сразу, как видим что у них проблемы - советуем выбрать другой метод оплаты (не шлюз - это всегда помогает) или высылаем счет, чтобы оплачивали не через сайт, а напрямую из банка. Но такой подход возможен не всегда, поэтому некоторые пользователи после нескольких неудачных попыток уходят с сайта, и возвращаются через, скажем, час, и пробуют снова - и, вуаля, все отрабатывает без проблем.

    Грешил на производительность сервера, но до этого пробовали впс - не помогло. А сейчас у нас шаред, и не самый дешевый пакет. php 7.1 fpm, nginx, opcache. На уровне приложения тоже есть кэш + жмем скрипты и стили. По метрикам "присядов" сервера не видно, в логах тоже отмечено, что страница "пост-чекаута" проблемного заказа загружена за 0.7 сек, не больше. Так что это не тот случай, когда на серверах начинается массовое обновления wordpress и ложится почти весь хостинг.

    "То есть вот предела у уровня эзотеричности проблемы просто нет." - пожалуй, добавлю эту фразу в свою копилку. Очень точно сказано.
    --- Добавлено ---
    Да там и с кодом ничего не скажешь. :)
     
  16. xaker01

    xaker01 Активный пользователь

    С нами с:
    16 апр 2016
    Сообщения:
    210
    Симпатии:
    34
    Если не секрет вышли ссылку сайта в ЛС.
    Часто баги ищу на стороне пользователя, может и тут что найду)
     
  17. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.106
    Симпатии:
    1.243
    Адрес:
    там-сям
    логирование на сервере. нельзя залогировать запрос, который не дошел до сервера. я бы посмотрел на JS создающий тот самый запрос, которого не происходит в итоге.
    ставлю рубль на race condition в джаваскрипте.
    --- Добавлено ---
    и ещё, я бы сделал graceful degradation: страница должна быть осмысленной для пользователя, когда джаваскрипт по каким-то причинам на*бнулся. не всё должно рендериться на клиенте, что-то таки должно быть изначально, что позволит двигаться дальше.
     
  18. TeslaFeo

    TeslaFeo Старожил

    С нами с:
    9 мар 2016
    Сообщения:
    2.984
    Симпатии:
    759
    сказал человек с говорящим ником :D
     
    machetero нравится это.
  19. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Запрос доходит и логируется. Не происходит выполнение js кода, который отправляет форму с данными в банк.

    Код там очень простой:
    Код (Text):
    1. jQuery(function($) {
    2.         jQuery('#bank_form').submit();
    3. });
    Graceful degradation у нас тоже есть, только у нас оно называется progressive enchancement :) Если js у пользователя отключен, или отвалился, то он руками жмет кнопку отправки формы.

    А вот насчет race condition я бы поспорил, ибо js однопоточен.

    Спасибо за желание помочь, но никнейм действительно стоит сменить :) А вообще, думаю помощь больше не потребуется. Вчера меня осенило, и я начал сохранять html-копии страниц пост-чекаута. Сегодня прилетел первый дефектный заказ, и я наконец смог увидеть то, что видел пользователь. Почти. Копия была в порядке и переадресовывала на страницу банка без проблем. И тут я вспомнил, как у нас один раз отвалился весь интранет из-за упавшего googleapis. :) Похоже, что проблема именно в нем. В итоге перенес все шрифты на сервер сайта, теперь наблюдаю.
     
  20. AlexProg

    AlexProg Активный пользователь

    С нами с:
    13 май 2014
    Сообщения:
    320
    Симпатии:
    7
    Какие ЭПС не работают? У некоторых SSL нужен на сайте + домен должен быть НЕ третьего уровня.
    Что в файле обработчике у вас?
     
  21. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Swedbank и SEB. Я не в РФ. Домен не третьего уровня. О каком файле обработчике идет речь? Обработка результата оплаты? До нее не доходит.
     
  22. TeslaFeo

    TeslaFeo Старожил

    С нами с:
    9 мар 2016
    Сообщения:
    2.984
    Симпатии:
    759
    если что, то нет никакой информации о том, что этот человек является хакером.
    Я это написал в шутку. Просто ситуация показалась забавной.
    А так, каждый разраб немного хакер.
    Если я где-то спалю, что мои коменты выводятся без htmlspecialchars, то вряд ли удержусь от возможности влупить огромную на весь экран надпись "Админ лох".
     
    AndreyKo нравится это.
  23. artoodetoo

    artoodetoo Суперстар
    Команда форума Модератор

    С нами с:
    11 июн 2010
    Сообщения:
    11.106
    Симпатии:
    1.243
    Адрес:
    там-сям
    где именно "грейсфул деградейшн" — submit это отправка. а проблема у тебя со страницей возврата. ты писал, что она либо совсем пустая, либо какие-то куски на ней.
    не потерял ли ты нить?
    --- Добавлено ---
    простой жсной асинхронности достаточно для race condition. без разницы как это на уровне процессов устроено — если переменная может быть не задана в момент использования по причине того, что какой-то запрос выполнился быстрее/медленнее чем предполагалось,
     
    Fell-x27 нравится это.
  24. phpdev1

    phpdev1 Новичок

    С нами с:
    10 сен 2017
    Сообщения:
    22
    Симпатии:
    0
    Давай еще раз разложу все по полочкам. Пользователь заполняет форму оформления заказа (чекаут), отправляет ее, попадает на страницу "переадресации" в банк (именно ее я и называю страницей пост-чекаута). На этой странице находится скрытая форма и жс код, который отправляет эту форму в банк - именно таким образом пользователь попадает на страницу банка. До обработки результата процесса оплаты не доходит. Т.н. graceful degradation тут в том, что в случае отключенного js пользователь отправляет эту форму сам нажатием кнопки "Перейти в банк", в противном случае, js делает это за пользователя. Так вот, на этой самой странице "пост-чекаута" не происходит выполнение этого жс кода, который отправляет пользователя на страницу банка. В жалобах пользователи пишут, что видят белую страницу (т.е. и кнопку нажать они не могут).

    Теперь, имея копию html-кода страницы пост-чекаута каждого совершенного заказа, я вижу, что на самом деле с этой страницей все хорошо, форма рендерится, жс код выполняется, и проблема, скорее всего, в том, что один из <link rel="stylesheet" /> запросов в шапке блокирует загрузку всей страницы, когда источник лежит или отдает стили слишком медленно. Но это не точно.

    Про race condition я тебя понял, и нет, это не тот случай :)
    --- Добавлено ---
    Я тоже написал это в шутку :)
     
    #24 phpdev1, 12 сен 2017
    Последнее редактирование: 12 сен 2017
  25. xaker01

    xaker01 Активный пользователь

    С нами с:
    16 апр 2016
    Сообщения:
    210
    Симпатии:
    34
    Во блин я им помочь, а уже стал врагом народа :D
    Но если что пиши)
     
    AndreyKo нравится это.