stas2010
-
Публікації
260 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача stas2010
-
ждемс, усиленно тестируем
-
жаль, при парсинге всякая хрень периодически попадается.... если это будет удаление атрибута только из того товара, который имеет это значение, то гуд, а если просто удаление атрибута со всеми значениями, то не гуд, оно и так сейчас есть.
-
вот маладэц! не успел подумать или написать, а оно уже тут!
- 13 587 відповідей
-
- 1
-
-
- simplepars
- парсинг товаров opencart
- (і ще %d)
-
Хоть модуль еще в стадии разработки и пока встречаются иногда баги, но уже видно потенциал модуля. Модуль удобный и не сложный в освоении, а если "сложный" от незнания, то автор помогает, да и на форуме решить вопросы можно. Автор старается быстро исправить выявленные ошибки и добавить новый функционал, хотелки пользователей адекватно обсуждает, действительно необходимые функции внедряет. Благодаря модулю решил проблему сбора ссылок с сайтов донора, на которую потратил несколько месяцев, и на которую еще предполагалось потратить уйму времени. Даже за это уже БОЛЬШОЕ спасибо автору модуля. Модуль гибкий и, если нет какого-то функционала, то можно его реализовать, применив другой алгоритм действий в этом же модуле. Надеюсь на развитие модуля и расширение функционала.-
- 1
-
-
- simplepars
- парсинг товаров opencart
- (і ще %d)
-
Attributico_v3.0.4 не удаляет значение атрибута в закладке Атрибуты, хотя в подсказке имеется функционал "Удалить" - открывает окно на подтверждение действия, и всё - значение на месте остается.
-
Модуль спас ситуацию, когда в шаблоне Techstore надо было внизу страницы разместить информацию о магазине, а в шаблоне не было возможности вставить блок. Автору модуля - БОЛЬШОЕ СПАСИБО!
-
Модуль спас ситуацию, когда в шаблоне Techstore надо было внизу страницы разместить информацию о магазине, а в шаблоне не было возможности вставить блок. Автору модуля - БОЛЬШОЕ СПАСИБО!
-
- 3
-
-
- код аналитики
- код метрики
- (і ще %d)
-
отписался в лс
-
во-во это надо, а то постоянно хреновое настроение
- 13 587 відповідей
-
- 1
-
-
- simplepars
- парсинг товаров opencart
- (і ще %d)
-
так и сделал, но, тут обработка И или ИЛИ, а если на стороннем ресурсе будет также /LED/, то, я думаю, что будет добавлена ссылка со стороннего ресурса. маловероятно, но бывают случаи. я не про дубли в ссылках, а про дубли после АОП. про то, что АОП привязывается к sku, в крайнем случае дополнительному sku. но, очень часто бывает такое, что на странице донора нет именно этих данных. и по вашей, полученной ссылке придет в магазин "новый" товар, т.к. , например, артикул донора может быть его складским номером (у меня такая ситуация проскакивала - приходилось брать sku склада поставщика, т.к. у него только в этой колонке всегда были данные, а ean и артикул производителя периодически отсутствовали) - для АОП это будет новый товар, т.к ранее этого sku не было. т.е. я о том, что такой поиск товаров не совсем корректен. АОП не за что зацепиться, чтобы данные попали именно к тому товару, который уже в базе. тоже будет и наоборот, если сначала залить прайс, который был получен путем парсинга ссылок, а наверх прайс поставщика. Хорошо, если товаров 10-100, а если несколько тысяч или десятков тысяч, то потом вылавливать их будет не реально. в том то и проблема, что, например, ваш запрос не работает на нужных сайтах, а на одном только так можно search/result/?q=, на другом не знаю что скормить, т.к. через ввод ean на сайте работает, а через url - надо еще подбирать. это есть самое сложное, чтобы найти эту комбинацию, если знаете как - подскажите, пожалуйста. как бы да - было бы круто. автоматизация процессов по кусочкам как бы улучшает жизнь, но .... покупатели стремятся именно к "одной кнопке". это можно, знать бы что в конкретном случае вставлять. и еще останется каким-то образом на выходе в артикул вставить правильный sku (т.к. в поиске может быть не sku, а что-то другое), либо строго соблюдать порядок, чтобы не было потом смещения в таблице, когда обратно вставлять будем или новую создавать. опять же потом возникнет вопрос - скормили 100 ссылок, а на выходе получили таблицу с 20-ю строками, т.к. часть страниц с 404 или без товара. тут важно, чтобы в таблицу попадала первоначальная ссылка с исходным поисковым словом или пустые строки вместо нее, тогда и соотнести с товарами полученную ссылку будет возможно.
-
не так поняли. я про то, чтобы в ваш модуль можно было подгрузить прайс поставщика. далее модуль берет из столбца, указанных в настройках поисковое слово и подставляет его на сайт донора, а далее вытягивает уже правильную ссылку, которую записывает в указанную в настройках колонку в прайс поставщика. далее при необходимости по собранным правильным ссылкам или сразу модуль парсит в прайс поставщика данные согласно настроек модуля (артикулы, описания, атрибуты и т.п.). вот тогда получим действительно и экономию и завершенный функционал, миную ручную работу по удалению ненужных ссылок. т.е. наша задача получить ссылки для товаров в прайсе, а также другую информацию будет реализована в полном объеме. и тогда, действительно, останется только скормить в АОП один раз всё тот же прайс поставщика, при этом не размножая формы в АОП. а далее по той же схеме и новые товары будут добавляться, а те, на которые не нашлось сразу ссылок (и такое бывает) - также получат их и необходимые данные. при этом не нет необходимости полностью парсить всю структуру донора, и все ссылки. максиму, что на парсинг потратится - это разбор того, что будет на странице результатов поиска донора (описал выше - три варианта). вот только на это и уйдет время работы модуля. на текущий момент, чтобы мне получить инфу на 10 или даже 500 конкретных товаров мне необходимо (и это при условии, что на доноре будет sku, ean или название): 1. спарсить все ссылки с сайта донора (предположим, что товары находятся в разных категориях). 2. спарсить для всех товаров данные, хотя мне необходимо только на 10 конкретных товаров. 3. запустить спарсенный прайс на хрен знает сколько позиций и дай бог не на очень большое их количество, т.к. АОП спарсенный прайс на 10000+ будет лопатить довольно долго, а если еще и без крона...... даже, если предположить, что всё-таки со спарсенного прайса и не зальется всего шлака, а сделается выборка на 500 позиций, то всё-равно весь этот процеесс сейчас занимает довольно много времени. в моем же варианте 500 конкретных товаров вместе с данными спарсятся даже быстрее, чем вы спарсите структуру донора сейчас. самая сложная задача - впихнуть в поиск донору поисковое слово. какая-то программа для парсинга как-то такое делала, или заявлялось, что может делать - не помню.
-
уже два раза наблюдал небольшой баг - если сохранить настройки и запустить "Повторить фильтрацию", то по какой-то причине "Очередь сканирования ссылок" открывается пустой, Обработано ссылок: 1283 | Ссылок в очереди: 0 повторное сканирование сразу пишет, что завершено. очистил список - запустил сканирование, очередь сканирования - так и остается пустой.
-
а есть ли для ссылок переменные? например, попадаются /v9=12 или /318. тут бы хорошо сделать, например /v[n]=[n], где [n]-любое число, можно также и для символов,например, /v 9= 12, или просто для любой строки длиной S, например, /v[2]12. еще может быть проблема со ссылками на сторонние ресурсы. случайно нашел на vk и другие - попадают в списки. может можно будет как-то выделить эти ссылки, пометить другим цветом, чтобы в обработку не попадали и по ним переходов не было? хотя надо еще будет учесть, что некоторые магазины используют несколько адресов, например, для хранения изображений - их можно просто будет дополнительно прописать. и, возвращаясь к предыдущему посту, сейчас у меня есть два сайты, где ссылки получить не вопрос и спарсить можно, но! в части товаров не к чему зацепиться - sku и ean периодически отсутствует на доноре, а название точно не совпадает с тем, что в прайсе поставщика или у меня в магазине. нормальное название как раз и планируется взять с этих сайтов. но! если искать ссылки по sku, ean, названию (иногда прокатывает), то ссылки и товары можно найти на доноре. по-этому необходимо парсинг ссылок привязывать к данным из прайсов. иначе у меня будут в магазине 140000 товаров залитых по полученным ссылкам, которые сами по себе болтаются без привязки к прайсам, а накатив через АОП еще и прайсы поставщиков получим еще 30000 дублей. к тому же из 140000 большая часть нафиг не нужна будет. отсюда еще вопрос знатокам - как определить/задать/создать ссылку с запросом, чтобы получить результат, аналогичный тому, что получают при вводе слова в поисковик сайта донора? может я в чем то и заблуждаюсь или не понимаю в науке парсинга, но пока у меня такое видение этого вопроса.
-
я бы попробовал так: начало-конец: class="cena clearfix",<br> парсинг: <span>,руб. или <span>,</span> но тут вопрос в том, что цена стоит с пробелами.
-
есть одно пожелание и один небольшой баг: 1. в работе очень не хватает ссылки на страницу с новыми товарами и на страницу с товарами по акции, а также в фильтре сортировки "сначала новые" и "сначала товары на акции". было бы не плохо реализовать в шаблоне, т.к. в модуле на главной этих товаров можно указать очень мало, а если их приехало 100-500, то показать их нет возможности ни на главной, ни на отдельной, ни в фильтре, чтобы увидеть в категориях. 2. баг - на мобильной версии вместо текста, например, "под заказ" на товаре просто белый квадрат. и если функционал позволяет делать заказ при отсутствии товара, то клиент не видит, что сделал заявку на "под заказ" и думает, что товар в наличии.
-
Добрый день, с трудом, но осилил 16 страниц темы .... просмотрел эволюцию модуля - многое уже сделано. буду тестировать - идея хорошая и нужная. в свое время отказался от популярных парсеров по одной причине - парсится всё подряд, даже учитывая ограничения - на выходе много не нужного. у вас был хороший пример с такси - я заказал такси и приехал по конкретному 1-му адресу и вышел, где мне надо, а не по 1000 адресам с остановкой на каждом и потратив время в 1000 раз больше. уже как-то вопрос поднимался и ваш ответ не совсем устроил, т.к. также были лишние ссылки. объясню, как я делаю и, надеюсь, многие тоже так поступают, когда нет парсера. 1. беру sku (не всегда совпадает с донорами) или ean (практически всегда при поиске дает нужный товар, если на сайте правильно реализован поиск и он есть в базе), реже название товара. вставляю в строку поиска донора. 2. Результаты поиска чеще всего: а. Страница результата поиска с одним этим товаром б. страница самого товара в. очень редко - страница с найденным товаром и лишними совпадениями 3. в зависимости от результата п.2 либо сразу получаем нужную ссылку, либо имеем ссылку на товар на странице результата поиска. 4. берем необходимые данные, если надо с полученной ссылки. К чему пришли - было бы реально круто, если бы модуль умел следующее: 1. взять из прайса поставщика из указанной колонки данные для поиска, например, тот же ean. 2. по указанной ссылке + поисковое слово на сайте донора найти действительно нужную ссылку. 3. поместить найденную ссылку назад в прайс в указанную колонку. 4. получить дополнительные данные с сайта донора и добавить в прайс поставщика в указанные колонки. 5. можно также реализовать (иногда встречается, что ссылка на товар на доноре меняется), как и в АОП функцию Обновлять ссылки или только добавлять. Тогда будут добавлены ссылки только для новых товаров - опять же сильно сократит время. реализовав это получим следующее: 1. сократим время на ненужный сбор ненужных ссылок, например, если у меня у донора 140000 товаров, а у меня в магазине даже 30000, то на поиск, сбор, обработку уйдет очень много времени. согласен, что уже сильно сократится время на сбор ссылок при текущем функционале, но в предложенном варианте это время сократится еще в разы. 2. легко будет осуществить добавление именно новых товаров и именно для вашего магазина. опять же, у донора может обновиться/добавиться 5000 товаров, а у вашего поставщика только 100. зная эти 100 товаров уйдет намного меньше времени, чем на скан донора с нуля и обработку/подгонку под свои прайсы и магазин. как-то такая вот хотелка Ну, или по-этапная её реализация, начиная с того, что именно необходимые ссылки на указанный в поисковом запросе товар и в том же порядке будут получены в итоге. напомню, что в вашем решении, которое было выше, вы в результате на запрос по sku получили более 5 ссылок. сейчас функционал для этого, судя по теме, уже практически готов. Хотелось бы тоже для opencart 3.0 но, можно получить ссылки и через 2.3.
-
предложил автору сделать, чтобы можно было редактировать только после полной загрузки формы - будет дольше, но безопаснее. сам, зная об этом - часто делаю: открыл, сразу быстро изменил - быстро сохранил, а потом вспоминаю, что надо было подождать, особенно на хроме и опере и ,совсем критично, когда в категориях несколько страниц.
-
ну, не только настройки сео слетали у меня, но и атрибуты и др. .... но, если есть проблема, то её надо решать - лично с автором переписывался по многим вопросам, находили решения и модуль обновлялся уже с исправлениями. сейчас как и все жду своей очереди, когда автор сможет отписаться - ни чего страшного в этом нет. кстати, очень много вопросов лично возникало, пока не понял логику работы программы - всё это время автор помогал и примерами и советами. по поводу падения настроек - уже отписался автору, жду, будем вместе решать. связываю это с тем, что настройки могут падать в том случае, когда форма не загрузилась полностью. т.е. если открыть форму поставщика и сразу нажать, например, на сео, то сео не откроется, по крайней мере при большой форме необходимо время, а откроется через время, когда прогрузится. и если в это время, пока форма загружается, сделать изменения в настройках формы и сохранить, то обязательно потеряете часть формы. ну, это пока мои наблюдения. может причина и в другом - будем проверять с автором. было такое на нескольких релизах 9.0 и 9.1 - и тоже с автором выискивали этого "жука", давал доступ к серверу. а на то время - просто откатился на рабочую версию, которая не накидывала - и всех делов. если автор дал доступ к 9.1, то обновите модуль. на днях себе установил более свежую версию. вчера обновлял с прайсов - цены вроде правильные. есть авторы, которые действительно плевали на проблемы пользователей и только деньги собирают за недомодули. с этим модулем многое по другому - и поддержка есть и обновления. согласен, что иногда необходимо подожать - нас много, но вопросы решаются. если нашли ошибку - опишите её и постарайтесь написать небольшое описание, что делали и как получаете эту ошибку - это поможет быстрее решить проблему, т.к. входных данных очень много.
-
и таблицы как-то не правильно выводятся (заметил смещение еще в прошлой версии, а сейчас совсем не правильно стало):
-
вообще, логичнее, там никакой не должно быть надписи, если это версия 2.8.1 но, перезапись файлов не помогла. версия oc 3.0.2.0 (rs.4)
-
не напрягает, но, обновился до 2.8.1 - надпись "Настоятельно рекомендуем обновить модуль на более актуальную версию 2.7.9 !" не исчезла.
-
Вот отсюда и все танцы эти с бубнами.. по идее как бы и должен обрабатываться товар с галочками, на практике тоже товар с галочками начисляет скидки. по поводу того, что просто без отметки по фильтру будет начислена акция - не знаю, правильно ли это. с одной стороны как бы фишка, возможно подразумевалась автоматическая корректировка количества товаров, попадающих под фильтр. но, в фильтре для этого слишком мало условий (пока нет ценового диапазона, некоторым может надо с учетом атрибутов или опций, размера, веса и т.д. - всё конечно не учтешь...), по-этому на данном этапе без отметки товаров не обойтись. да и функционал "отметить все отфильтрованные товары" как бы подразумевает, что они будут отмечены галочками (даже иконка об этом намекает). а в противовес этой кнопке очень не хватает "снять отметку со всех товаров, учитывая фильтр", чтобы фильтр оставался и не надо было заново его настраивать. на текущем этапе использую скидки от диапазона цен, а некоторые товары после обновления прайсов изменяют цены - приходится еще несколько страниц листать в поисках "перебежавших" товаров, чтобы снять галочки с них. быстрее бы было - снял галочки разом и отметил по-странично заново.
-
этой задачей как бы должна заниматься индексация, наверное . Смена кода товара происходит через АОП при обновлении из прайсов - последний поставщик, у которого был товар и будет указан путем добавления кода поставщика к коду товара 1234 плюс -01 или -02. Подтянулись элементарно. даже знаю, в чем косяк модуля. два конфига для разных поставщиков создать не сложно - в фильтре выбрать поставщика, это и так понятно. далее модуль создает список по этому фильтру и, подозреваю, что список составляется по ID-товара. т.е. в базе конфига для поставщика -01 будет товар с кодом 1234-01 с ID 1234 (вернее запомнит только ID). отсюда и проблема при смене кода товара с 1234-01 на 1234-02. Фильтр для поставщика -01 товар не покажет, хотя он уже станет с кодом 1234-02 и останется в конфиге поставщика -01. Фильтр для поставщика -02 товар покажет, т.к. это уже его товар. Получается, что к обоим конфигам привязан товар с ID 1234. тут как бы должен был сработать модуль и согласно фильтру просто проигнорировать товар с этим ID 1234 - не устанавливать скидку 20% для поставщика -01, т.к условия фильтра не выполняются. аналогично при обратной смене поставщика (кода товара на 1234-01) первый конфиг должен присвоить скидку, а второй проигнорировать, т.к. по фильтру уже не проходит. В базе конфига как таковой товар можно оставить, чтобы еще раз не отмечать его при очередной смене поставщика. По поводу выбранного товара (галочками) - в моем примере необходима отметка товаров, т.к. еще нет сортировки по цене, отсюда и получилось, что условия в фильтре по поставщику одинаковые для разных акций, а для каждой акции товары выделяются по ценовому диапазону.
-
как бы так и делается, останавливаются акции и перезапускаются. НО, я думаю, что надо привязываться к фильтру в конкретной акции, т.к. у поставщика А уже нет в фильтре этого товара - он уже у поставщика В. к тому же этот товар даже не отключить в фильтре поставщика А, по той же причине - его там нет. Т.е. если товар попал ранее одновременно в фильтры товаров нескольких акций, то включать товару ту акцию, в которой в фильтре сейчас реально есть этот товар. Опять же бывает ситуация, когда товар отмечен галочкой в двух акциях и он там виден, т.е. подпадает под фильтр и там и там. В этом случае не хватает информации - в каких конфигах он еще отмечен. понять одновременное нахождение товара в двух акциях можно только по перечеркнутой цене, да и не всегда, а только, если акция запущена. Для небольших магазинов, где товаров не много - можно такие товары визуально вычислить. Для больших, где несколько тысяч или десятков тысяч - поменять поставщика на 5000 товаров выборочно - не реально. По-этому на основании фильтра надо назначать акции. Индексация как видно из моего примера, на практике не назначила правильно акцию. Проверил еще раз - остановил обе акции, провел индексацию, запустил акции - на первом товаре опять вместо 10% выставлено 20%.
