Артем

Артем

Был в сети 23 марта 2022, 14:24
Заказы не принимаю
А что плохого в парсинге? Есть поставщики, которые предоставляют каталог продукции, если клиент становится их дилером, то ему необходимо спарсить весь каталог к себе на сайт. Так, собственно, и появляется задача на парсинг товаров. Как уже было сказано, если каталог хренового качества — нужно подчищать дубли и все косяки, чтобы у клиента было не абы что, а нормальный каталог. Имхо, автоматизированное и проверенное решение в разы выгоднее, удобнее, быстрее и надежнее любого менеджера, а еще платить никому не надо.
1. Вам не знакомо понятие импорта и экспорта статических файлов?
2. Давно компоненты стали чувствительны к данным в таблицах типа site_content?
3. Стащите, кто мешает?
4. Уверен, что если компонент вам действительно нужен, то вы найдете свой собственный тестовый контент.
т.к. предполагаю, что с этой болью сталкивались (почти) все
так и есть, все и решают ее традиционными способами: либо вы выставляете ручками везде дополнительные пробелы, либо вы погружаетесь в
эту статью и вникаете в принцип работы {ignore}, чтобы понимать, где он сработает, а где нет, а затем комбинируете это с первым вариантом, либо вы пишете свой плагин, который обрабатывает нужный вам контент, ищет вхождения регуляркой и заменяет их, добавляя дополнительный пробел. Собственно, это просто автоматизированный первый вариант.
Вполне себе уместное замечание было касаемо Shopkeeper'а. msBonus и msBonus2 связывают только общее название и не более, почему автор должен заботиться об обратной совместимости с чужим компонентом? Об этой особенности явно написано на странице компонента в modstore.
Честно говоря, msProductOption вообще имеет какую-то проблемную таблицу и с ним постоянно всплывают какие-то нюансы, буквально недавно наткнулся ровно на ту же проблему, напрямую получал объект msProductOption, менял значение через xPDOObject::set(), сохранял, а в таблице ничего не менялось, при этом и ошибок никаких не было, xPDOObject::save() возвращал true. Скажу даже больше, использование xPDO вместо объектов тоже не решило эту проблему, данные все так же не менялись. Вероятно, это связано с отсутствием PK в этой таблице как такового, другой причины не вижу.

Собственно, остается работать с этой таблицей только через PDO, именно так это и реализовано в методе msProductData::saveProductOptions(), который вызывается во время сохранения товара.
Спасибо за webpack, да и вообще отличную заготовку! Правда один момент неоднозначный получается: ресурсы генерируются со статическими id из массива, но что, если менеджер создал несколько новых ресурсов в админке? Получится так, что если мы вдруг надумаем добавить еще один ресурс в массив, то при следующей сборке ранее созданные ресурсы менеджером перезапишутся ввиду того, что наш пакет не знает о них. Такая же история получается при какой-нибудь выгрузке из 1C, например.