Содержимое XML-файла с расширением PHP

Скорее всего повторяюсь по данному вопросу, так как в той или иной мере уже писал об этой проблеме пару лет назад. Хочу ещё раз акцентировать то, что владелец, либо вендор имея, как говориться, на руках горячий прайс-лист в формате XML, но с расширением файла PHP не имеет возможности импортировать его в свой магазин, ввиду соответствующих критериев безопасности CS-Cart.

Суть в том, что владелец или вендор сражаются за нового партнёра, порой припадая на колено, тот в свою очередь даёт ссылку на скачивания файла, а файл оказывается с расширением PHP. Кто нибудь может представить ситуацию, когда просящий скажет, – чувак, а мне твой файл неподходит, дай как мне с другим расширением? Вот и я не могу представить.

Конечно же XML с расширением PHP встречаются не часто, например в моём случае на сотню 3-4, однако, не редко содержимое такого файла бывает намного дороже десятка прайсов с правильным расширением. Когда это единичный импорт, тогда можно переименовать файл, а как быть, если необходимо импортировать товары по CRON каждые 2 часа. А если мультивендор, то таких файлов может быть на порядок больше. Если владелец ещё как-то может решить проблему через танцы с бубном, то в случае с вендором эта проблема неразрешима. Ещё дело в том, что вендор столкнувшись с такой проблемой просто уйдёт с площадки, так как у него единственный партнёр, который предоставил ему файл с расширением, который невозможно использовать для импорта в CS-Cart.

Вижу решение в том, чтобы платформа автоматически меняла расширение PHP на XML, если такой файл загружается в пресет импорта.

Здравствуйте, не особо вникая в проблематику вопроса ( скорее всего поставщик не корректно передает заголовки не сообщая что это xml ) не вижу проблем предварительно скачивать тем же wget сам файл но сохранить с корректным расширением а дальше по штатному сценарию. Я понимаю что удобно когда система делает меджик и все работает даже на кривых источниках но все же есть определенные стандартны которых лучше придерживаться ибо можно напороться на неприятности в других моментах, например с безопасностью, в общем проблема решается более простым способом:

скачали например с помощью wget
сделали импорт с локального файла
удалили локальный файл

реализуется это либо длинной командой либо скриптом, в любом случае это проще и более корректнее чем вставлять кучу костылей и так далеко не идеальный импорт.

1 лайк

Поддерживаю, давать разрешение на закачку php - немаленькая дыра в безопасности

Скачать не значит выполнить - дыры в таком случае нет. В нашем модуле автоматизация прайс листов мы работаем с такими файлами, всех поставщиков под одну гребенку не поставить.

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

Если доверить доработку лапотнику, то конечно выйдет костыль, да и дыры вероятны.

Конечно, если не особо вникать, то и проблемы не увидишь, да ещё, когда читаешь пост по диагонали, и не ставишь себя на место вендора. Надо рассматривать вопрос с точки зрения крестьянина, а не помещика, тогда сможешь прочувствовать проблему. А основная проблема в том, что вендору недоступен импорт прайсов с помощью cron, потому он не может ничего предварительно скачивать. Максимум, что он может, это зайти в пресет, попробовать добавить файл, затем, на каком-то этапе обломаться, и уйти восвояси.

Не будет никакого маркетплейса и бизнеса, если руководствоваться – “главное нам удобно и понятно, а вендор уж как нибудь”. При импорте прайса вендор не должен сталкиваться с таким поведением скрипта, если даже это единичный импорт, иначе он очень быстро свалит с маркетплейса. Если вендор закопался с настройкой соответствия полей, то это ещё как-то решаемо, а вот когда он не сможет добавить файл, то это уже фиаско.

А если рассматривать функционал нынешнего импорта в целом, то именно по причине дурацких настроек пресета у меня уходят 9 из 10 новых вендоров в первые несколько дней. Попробовали вендор качнуть товары и тут же облом. И это не только по причине того, что у них файлы какие-то не такие, а ещё потому, что сам пресет импорта для вендора неподъёмный, особенно со всеми этими идиотскими настройками модификаторов, в том числе модификатора для категорий. В моём маркетплейсе из двух сотен вендоров ещё ни один не импортировал товары самостоятельно, ни один, ноль, zero, 零, а это уже не звоночек, это набат.

Кстати, вот попалась моя же тема полуторалетней давности и всё по этому же поводу – Импорт XML-файлов с иным расширением Вот так и мучаюсь сам, и мозги полощу вендорам, что они “серые” и не понимают всей прелести супер-мега-круто-продвинутого импорта. :rofl::rofl::rofl:

Для того чтобы хоть понять суть проблемы вы бы указали хотя бы один реальный пример, судить о сути по ссылке httр://site.ru/file.php как-то сложновато, если по ссылке передается хедер что это xml файл тогда проблема на стороне импорта, так как идентифицировать что это файл возможен для импорта возможно, и соглашусь с вашими претензиями, если же там просто шлют пачкой инфу без каких-либо идентификаторов то это уже не проблема импорта а поставщика сего контента. Посты по диагонали я не читаю, просто нельзя решить техническую проблему без технической инофрмации. Расширение файла не является идентификатором, это просто ссылка, вопрос к заголовкам которые передаются в ответе.

2 лайка

Пример отправил в личку.