Rassol2

27.10.2023 в 02:55, nikitishin сказал:

Здравствуйте, подскажите как решить проблему с парсингом фото

Есть ссылка на фото 
/upload/resize_cache/iblock/de2/100_100_1b24bf9e35bfbc8de9fc7f31afe648f50/foto1.jpg

 

По даному пути открываеться фото с водяным знаком, 
Без водяного знака путь будет такой
/upload/iblock/de2/foto1.jpg

У меня прописано такое правило

.webp|.jpg
/resize_cache|
{reg[#/upload/iblock/[0-9]+x[0-9]+/(.*?)/#]}|/

Покока я получил такой путь
/upload/iblock/8dd/100_100_1b24bf9e35bfbc8de9fc7f31afe648f50/foto1.jpg

Подскажите как прописать регулярное выражение что убрать 100_100_1b24bf9e35bfbc8de9fc7f31afe648f50 
/8dd/ ета папка динамическая для разных фото
 

Анука, я тоже поучаствую в вашем конкурсе.
Я бы сделал так.

Само правило.
resize_cache/|
/100_100_{skip}/|/
Я не сторонник усложнять решения без веской на то причины. Хотя по сути все решения будут работать с одной скорость, и давать тот же результат.
так что выбор всегда есть.

17.10.2023 в 18:37, Vetlucky777 сказал:

Подскажите как можно такое реализовать.

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

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

с одной ссылкой все работает и данные пишет только в один товар.

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

 

дополнительно тестил библиотеку PHP Simple HTML DOM Parser написал скрипт вроде все корректно парсит и записывает.

но такое хочу реализовать именно в этом модуле для гибкости настроек

С одной ссылки обновить несколько товаров нельзя.
Так же как и добавлять дубли ссылок и товаров. Это нарушает самую основу модуля. Написать скрипт который будет это делать можете.

Обновление v4.9-9_beta
Улучшение построение в XML/YML дерева категорий.
По просьбе @Axelenz внедрил штучное преобразование дерева категорий от донора.
Очень часто дерево категорий приходит от донора битыми, раньше модуль мог составить дерево категорий только в том случаи если в выгрузке xml была корректная. И указывались правильно родительские категории донора.
Теперь же, если придет битое дерево категорий то модуль попробует исправить ошибку прайса и выдать дерево категорий.
Возможно некая погрешность в стартовой категории дерева, но при этого все равно будет 95%+ правильно составленных категорий.
Погрешность возможно там где битые категории, где все нормально модуль по прежнему будет выдавать результат на основе обработки категорий донора, без доработки.

С этим уже можно будет работать, это луче чем отсутствие категорий как таковых.

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

Обновление условий использования.  (Пока еще не закреплена в лицензионном соглашении)
С этого момента ограничение переноса лицензии с одного сайта на другой проходит процесс либерализации.
Раньше переносить ключ с одно сайта на другой можно было не чаше одного раза в 72 часа.
С этого момента перенос можно производить не чаше 1 раза в 24 часа. То есть сократилось в 3 раза.

Пока что это официально не закреплено в лицензионном соглашении, если не будет злоупотребления буду продолжать либерализацию.
Ну а если пойдет злоупотребления вернемся к прежней практике.

ЗЫ. не хотел писать этот пост но нужно донести эту информацию до масс.
Не хотел писать по причине холивара в этом вопросе. Так что давайте воздержимся от него.

28.09.2023 в 13:27, yurok79 сказал:

Подскажите как бороться с таким)

Товар со скидкой

<oldprice>2990</oldprice> - Цена 

<price>2890</price> - Цена со скидкой

 

Товар без скидки

<price>2990</price> - Цена

 

Тоесть в товарах со скидкой и без скидки теги меняются местами и меняют свое значение. Как правильно настроить?

Все старо как мир.
делаете границы
{gran_1} - oldprice
{gran_2} - price

И указываете в цену
{gran_1}{|}{gran_2}
а в акцию
{gran_2}


Подробнее про оператор {|} можно узнать здесь
https://simplepars.top/index.php?page=note&n=33

Верхний пост не относится к парсингу XML которые вы нарезаете, так как после нарезания они будут у вас на хостинге, а долбить себя можно сколько вам будет угодно.

Совет для большинства. Ну или поделюсь опытом.

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

Если откатится во времени к моменту внедрения много поточности, то там была большая дискуссия, я проводил много тестов на десятках клинских сайтов, и ограничение в 5 потоков это баланс. До 5 потоков скорость парсинга растет кратно, а от 5 уже не значительно, но при этом нагрузка растет значительно, как и риски блокировок. В общих чертах, в частных случаях и парсинг в 5 потоков может показать худший результат чем в один поток если сильно убогий хостинг у вас или у донора.
Лично я парсю, или парсил в такой конфигурации.

Если донор знакомый и я с ним работаю постоянно. И я знаю его поведение.

Если донор новый, или к примеру какой то из крупных сайтов, где я могу предположить что есть хороший отдел it который не захочет со мной делится информацией.
Я парсю в таком конфиге.
 

Эти два конфига я бы назвал базовыми при здоровом парсинге.
Но я понимаю что, там где я могу себе позволить делать что то медленно, с минимальными рисками, вы может не захотите или у вас другие требования.
Я просто пишу как я поступаю лично. Из прокси у меня есть только один, на тот случай что бы убедится что проблема не в моем ip, как правило в баны не попадаю.

Так поступал я когда парсил активно на заказ.
Ну и помните, пока вы не создаете проблемы донору, а именно нагрузку, вы никому не интересны. Когда начинаете парсить 50 000 ссылок в 5 потоков, у донора растет нагрузка на веб сервер, и к нему приходит хостер с просьбой перейти на больший тариф или угомонить трафик. И вот тогда донор начнет задумываться что происходить и искать причину и бороться с ней. То есть с вами.
Уважайте своего донора и будете жить дружно и долго.

27.09.2023 в 21:02, buslikdrev сказал:

Без скриптов модуль не универсален.

Скрипты дают свободу в решении ваших задач.
Просто не стоит в любой непонятной ситуации уповать на них.
В данном случаи действительно через скрипты вы не сможете увеличить потоки.

27.09.2023 в 15:36, buslikdrev сказал:

		// убираем ограничение по многопоточности
		$script_data['urls'] = array();

		foreach($pars_url['links'] as $key => $result) {
			if ($key < $script_data['setting']['thread']) {
				$script_data['urls'][] = $result['link'];
			} else {
				break;
			}
		}

 

И это благополучно не будет работать.
По двум причинам.
1) модуль не подает больше 1 ссылки на парасинг когда включены скрипты.
2) при объявлении собственных функций в скриптах если бы работала много поточность, не работал бы модуль. Из за ошибки области видемости переменных.

@buslikdrev Я понимаю что вы шарите в пхп и готовы расширять возможности через собственные скрипты. И это похвально. Можете заказы выполнять по написанию скриптов для моего модуля, тут такого много. Но не нужно делать акцен что все через скрипты.
А то это уже похоже на поговорку, "если у меня в руках молоток то все вокруг гвозди." 

27.09.2023 в 13:48, buslikdrev сказал:

26.09.2023 в 07:24, partshez сказал:

 

Ограничение по потокам тоже через скрипты убирается.

Вы уверены ?
Просто когда вы включаете скрипты потоки ограничиваются до 1 в независимости от настроек.
Мне интересно как вы увеличиваете потоки через скрипты ?

@Axelenz Пришлите пару примеров xml с сломанными категориями.

26.09.2023 в 07:24, partshez сказал:

И еще хотелку. В коде есть закоментированные строки. Например, 10 потоков для крон и при ручном запуске, увеличение лимита времени работы скрипта свыше 25 сек ... И еще некоторые возможности, расширяющие функционал модуля. 

В Инструкциях создать примерно такую статью, как Заметки по регулярным выражениям. В ней указать коментированные строки, для шибко грамотных и любознательных пользователей. 

Иначе после каждого обновления приходится рыться в своих записях для поиска таких данных. У меня, конечно, есть такой блокнотик для служебного пользования  Но удобнее было бы видеть в Инструкциях

С повышением потоков напишу статью.
А вот с заметками поиск замене я думаю каждый должен для себя делать такие заметки. Такая статья есть но она обшего плана и сильно хитрые правила не описать в ней так что бы она стала понятна всем. Да и не читают ее если честно. Вот она.
https://simplepars.top/index.php?page=note&n=37

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

26.09.2023 в 13:36, SSHEVA сказал:

Да полностью согласен, по этому и приобрел этот модуль, некоторые клиенты уже сделали уже заказ и все прошло успешно.

Так что это хороший инструмент, который развивать и развивать. Было бы неплохо подобное для Вайбер, но у них такое.. Д... API делал я под него уведомления о заказах, намучился. 

не не не
Вот с вайбером пусть кто то сам.
У меня он есть но я туда не захожу. Я сказал кто хочет быстро вязаться, телеграмм а в вайбере я отвечу раз или два в месяц. После двух лет, все нужные люди в телеграмме.

Вайбер бесит лагучае гУмно.

Ну еше не готово, у меня но вот вдумайтесь какой уровень взаимодействия с клиентом. Или отвлеченности можно организовать в телеграмм.
Можно записывать что смотрел клиент.
Можно напоминать ему о своем существовании через меседжер.
Можно делать рассылки и напоминания.
Предложение.

А еше можно анализировать просмотры запросы и поведение клиентов, группировать их по интересам и делать предложения определенным группам.
Допустим у вас есть 1000 клиентов кто покупает одинаковый товар.
Допустим тарелки и крушки. И 900 из них, так же покупают салатники.
Вы берете 100 клиентов которые не покупают, и присылаете им сообщение.

Здравствуйте обратите внимание на данные салатники.
И показываете товар.
А снизу пишите
Мы не хотели вас беспокоить, но они будут чудесно сотрется в сочетании с вашими стаканами и тарелками.

Короче можно делать вещи. А главное это в телеграм. Где женщина не пропустить это сообщение как происходит с почтой. Где она может переслать сообщение подругам, мужу обсудить и загореться.

Маркетинг становится более технологичным.

26.09.2023 в 06:20, williamwill009 сказал:

Мне кажется что телеграмм неудобный для интернет магазина.

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

Обновление v4.9-8_beta

Исправления недочетов в парсинге файлов.

25.09.2023 в 04:21, maxleshiy сказал:

Спросил что нужно, я написал ))) Ждем! А то без этого функционала для меня модуль так и остается только для тестирования, в работу пустить не могу так как операторы заказы в программе не увидят никогда

 

Может позже вернемся к этому вопросу и я сделаю для вас отправку заказа в стандартную систему, но не полноценную а только ту часть что нужно для интеграции с 1с

25.09.2023 в 00:10, maxleshiy сказал:

У меня такая вот беда. У меня все заказы залетают в 1с, а так как ТГ заказы в отдельной ветке, то в 1с ничего не поподает. Давайте сделаем возможность импорта заказов с тг в штатные заказы

Не это возможно только в далеком будущем когда делать уже будет нечего. 
 

Если не будет мелких краткосрочных задач начну реализацию системы рассылок. Что бы можно было устроить современный маркетинг.

что бы были рассылки сообщений напоминания, и так далее. 

24.09.2023 в 15:49, Axelenz сказал:

А зачем поиск/замена на весь xml если это и так дальше реализовано в соответствующей вкладке ? Из-за ошибок в блоке категории возникают дальнейшие проблемы. Возможно ли сделать поиск/замену только для этого блока ? 

Да возможно, но это супер нелогично.

я понимаю что вам хочется иметь решение проблемы с кривыми Id категорий, но подымать из за этого целый комплекс поиск замены со всеми вытекающими на подобие. 
Создания блока для поиск замены в дизайне. 
Хранить данные в базе. 
Выводить на странице. 
Обработка в пред просмотре. 
Обработка при нарезании. 
Эксопрт этих настроек.

Импорт этих настроек. 
 

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

И вот это все еше и не будет работать на весь файл а только на блок категорий. И это еше нужно объяснить клиентам. 
И самое досадное что это нужно просто что бы удалить parentID="1"

в одной категории. 
 

Если бы это хоть работало на весь файл, то были бы шансы что данный функционал найдет какое-то применение в будущем а так ….. 

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

Для тех кто хотел поиск замену на весь файл XML.
Решил попробовать внедрить и понял почему этого нет))

Если мы хотим сделать поиск замену на весь файл XML где то здесь.
 

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

Так что поиск замену можно применять только к нарезанным товарам.
Эта задача тоже пока не реализуем.

В теории это можно сделать, но на данный момент цель не оправдывает средства.

Обновление v4.9-7_beta

1) Исправлена один недочет в парсинге файлов.
2) Ускорен париснг XML/YML примерно до 20%
 

Просьба, обратит внимание на скорость до обновления и после и описаться. Так как данная инновация не является финальной и все будет зависит от от вас.
Если не будет отзывов. Или не будет повышение производительности у вас, тогда данное изменение будет аннулировано.
Решение спорное и требует тестов в разных сценариях.

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

Провел тесты, новой обработки xml думал смогу выжать несколько X скорости, но увы. Если у вас хороших хостинг то прирост скорости будет незначительный.
Если у вас слабый хостинг тогда прирост будет кратный.

Старая технология.

13466 ссылок ориентировочно будут обработаны через 55 минут и 47 секунд.
 

Новый подход

46 минуты 32 сек на том же обьеме работы.

Здесь я попробовал исключить веб запросы при обработке xml, это самое дорогое в парсинге.
Дорого как по времени так и по ресурсам. В новом подходе это будет исключено.

По мимо прироста скорости должно снизится потребление ресурсов, то есть ниже нагрузка. Что то же должно порадовать обладателей бюджетных хостингов.
Собственно прирост на производительном хостинге составил около 17% при понижении потребления, что не может не радовать.
Хотя я ожидал большего. Завтра закончу и выложу релиз, а от вас просьба замерить производительность.

Так как мои расчеты показывали больший прирост.

Что из пожеланий на реализацию следующим ?