Такой интересный баг.
При добавлении/обновлении/просмотре товара в PrestaShop через REST (Web Service) на этапе парсинга возвращаемых данных XML возникает ошибка с кодом 76 и сообщением "Unexpected end tag : p". Для разбора XML используется SimpleXML. Самое интересное, что ошибка не постоянная. Если взять этот XML, на котором "споткнулся" парсер и проверить в онлайн валидаторах, то данные оказываются полностью корректными. И даже, если повторно запустить добавление/обновление товара, то ни какой ошибки не будет. При каждой итерации может возникать до нескольких десятков таких ошибок (причем на разных товарах), а может и не возникнуть вовсе. Номер строки ошибки всегда разный и указывает на теги генерируемые CMS. Все текстовые данные находятся в структуре CDATA, управляющие символы с кода удаляются регуляркой.
Собственно вопрос. Каким способом возможно реализовать локализацию бага?
Попробуйте на отдельной тестовой странице позабирать xml и вообще его не обрабатывать никак. Просто сохраняйте где-нибудь. Это должен быть один и тот же товар, забранный несколько раз. Это нужно, чтобы точно определить валидность в пределах одного товара. 2) Сохраните несколько видов xml для нескольких товаров и тоже все их протестируйте на валидность.
Тут главное убедиться, что вы всегда получаете валидный xml.
Если там все хорошо, тогда переходите к парсеру. Прогоняйте все через него, но при этом отключив как можно больше функций удаления и очистки. Если и там все будет хорошо, тогда добавляйте по одной функции очистки/удаления или другие имеющиеся функции, постепенно локализуя проблему.
Не стоит себе или кому-то верить наслово). Истина таится в мелочах (с)))
То, что написано в первом абзаце уже пробовал. Товар, на котором однажды появлялась ошибка прогонял до 20 раз, повторно ошибок не возникало. При этом всегда сохранялся xml и проверялся на нескольких валидаторах, xml всегда был полностью валиден.
Единственная функция очистки от управляющих символов (вроде 0x02) применяется только для краткого и полного описания товара, т.к. в описаниях поставщика товаров очень много таких символов.
Вопрос в том, что повторно не удается воспроизвести ошибку.
Я подозреваю, что там, где у вас html теги содержатся, есть незакрытый тег (то есть дисбаланс тегов), либо одиночный тег типа img без / в конце. Непонятно, почему во второй раз такой же xml разбирается без проблем, но то, что проблема в балансе тегов, думаю, стопудово. Не смотрите на валидаторы. Сами посчитайте все теги вручную. Если ошибка плавающая, значит кто-то обманывает).
heartdevil: Насколько я знаю, что данные в структуре CDATA не обрабатываются, а воспринимаются как plain text. Для подтверждения провел тесты со сломанной версткой в описании: никаких проблем не обнаружено.
Также провел еще один тест, когда вместо какого либо описания забивал пустой текст и на этот раз ошибок нет. Подозреваю, что в описании все таки находятся служебные символы, которые не удаляются функцией очистки. Но что это за символы? Ищу служебные символы по регулярке
'/[\x{00}-\x{0008}\x{000B}\x{000C}\x{000E}-\x{001F}\x{007F}-\x{0084}\x{0086}-\x{009F}\x{FFFE}\x{FFFF}]/u'
И это не объясняет почему ошибка возникает случайным образом
zed1cus: А пока вы проводите все эти манипуляции, ошибка еще раз всплывала? Это я так, чтобы периодичность все-таки выявить. Если так не получается, тогда вам надо самим попробовать вызвать эту ошибку. Попробуйте загуглить точную ошибку и посмотреть в каких случаях схожая ошибка появляется и попробуйте инициировать ее в коде. Вот поглядите этот список ошибок https://validator.w3.org/docs/errors.html в частности 76. Вот тут еще о том как группируются тэги. www.w3.org/TR/html5/grouping-content.html#the-p-element -- может быть совсем не в тему, но все же из-за неправильной позиции тегов тоже может ругаться. А так, абстрактно, мыслей больше и нет.
Простой
Простой
