Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Rassol2

Extensions developer
  • Posts

    11,656
  • Joined

  • Last visited

Everything posted by Rassol2

  1. Обновление v4.9-9_beta Улучшение построение в XML/YML дерева категорий. По просьбе @Axelenz внедрил штучное преобразование дерева категорий от донора. Очень часто дерево категорий приходит от донора битыми, раньше модуль мог составить дерево категорий только в том случаи если в выгрузке xml была корректная. И указывались правильно родительские категории донора. Теперь же, если придет битое дерево категорий то модуль попробует исправить ошибку прайса и выдать дерево категорий. Возможно некая погрешность в стартовой категории дерева, но при этого все равно будет 95%+ правильно составленных категорий. Погрешность возможно там где битые категории, где все нормально модуль по прежнему будет выдавать результат на основе обработки категорий донора, без доработки. С этим уже можно будет работать, это луче чем отсутствие категорий как таковых.
  2. Здравствуйте. Вы как то не совсем понятно объяснились. Что значит массово, массово вручную забивать, или из прайс листа доставать, или парсить сайт донор. Из чего то эта массовость должна состоять, так что опишите что у вас за входные данные.
  3. Обновление условий использования. (Пока еще не закреплена в лицензионном соглашении) С этого момента ограничение переноса лицензии с одного сайта на другой проходит процесс либерализации. Раньше переносить ключ с одно сайта на другой можно было не чаше одного раза в 72 часа. С этого момента перенос можно производить не чаше 1 раза в 24 часа. То есть сократилось в 3 раза. Пока что это официально не закреплено в лицензионном соглашении, если не будет злоупотребления буду продолжать либерализацию. Ну а если пойдет злоупотребления вернемся к прежней практике. ЗЫ. не хотел писать этот пост но нужно донести эту информацию до масс. Не хотел писать по причине холивара в этом вопросе. Так что давайте воздержимся от него.
  4. Все старо как мир. делаете границы {gran_1} - oldprice {gran_2} - price И указываете в цену {gran_1}{|}{gran_2} а в акцию {gran_2} Подробнее про оператор {|} можно узнать здесь https://simplepars.top/index.php?page=note&n=33
  5. Верхний пост не относится к парсингу XML которые вы нарезаете, так как после нарезания они будут у вас на хостинге, а долбить себя можно сколько вам будет угодно.
  6. Совет для большинства. Ну или поделюсь опытом. Я как автор хотел бы что бы мой модуль делал все что вы захотите и любые ограничения в нем в первую очередь бьют по мне. Так как это снижает привлекательность моего продукта, так вот именно я тот кто меньше всего хочет их внедрять. И если они есть они обусловлены какими то вескими причинами, не просто так что бы нагадить. Если откатится во времени к моменту внедрения много поточности, то там была большая дискуссия, я проводил много тестов на десятках клинских сайтов, и ограничение в 5 потоков это баланс. До 5 потоков скорость парсинга растет кратно, а от 5 уже не значительно, но при этом нагрузка растет значительно, как и риски блокировок. В общих чертах, в частных случаях и парсинг в 5 потоков может показать худший результат чем в один поток если сильно убогий хостинг у вас или у донора. Лично я парсю, или парсил в такой конфигурации. Если донор знакомый и я с ним работаю постоянно. И я знаю его поведение. Если донор новый, или к примеру какой то из крупных сайтов, где я могу предположить что есть хороший отдел it который не захочет со мной делится информацией. Я парсю в таком конфиге. Эти два конфига я бы назвал базовыми при здоровом парсинге. Но я понимаю что, там где я могу себе позволить делать что то медленно, с минимальными рисками, вы может не захотите или у вас другие требования. Я просто пишу как я поступаю лично. Из прокси у меня есть только один, на тот случай что бы убедится что проблема не в моем ip, как правило в баны не попадаю. Так поступал я когда парсил активно на заказ. Ну и помните, пока вы не создаете проблемы донору, а именно нагрузку, вы никому не интересны. Когда начинаете парсить 50 000 ссылок в 5 потоков, у донора растет нагрузка на веб сервер, и к нему приходит хостер с просьбой перейти на больший тариф или угомонить трафик. И вот тогда донор начнет задумываться что происходить и искать причину и бороться с ней. То есть с вами. Уважайте своего донора и будете жить дружно и долго.
  7. Скрипты дают свободу в решении ваших задач. Просто не стоит в любой непонятной ситуации уповать на них. В данном случаи действительно через скрипты вы не сможете увеличить потоки.
  8. И это благополучно не будет работать. По двум причинам. 1) модуль не подает больше 1 ссылки на парасинг когда включены скрипты. 2) при объявлении собственных функций в скриптах если бы работала много поточность, не работал бы модуль. Из за ошибки области видемости переменных. @buslikdrev Я понимаю что вы шарите в пхп и готовы расширять возможности через собственные скрипты. И это похвально. Можете заказы выполнять по написанию скриптов для моего модуля, тут такого много. Но не нужно делать акцен что все через скрипты. А то это уже похоже на поговорку, "если у меня в руках молоток то все вокруг гвозди."
  9. Ограничение по потокам тоже через скрипты убирается. Вы уверены ? Просто когда вы включаете скрипты потоки ограничиваются до 1 в независимости от настроек. Мне интересно как вы увеличиваете потоки через скрипты ?
  10. С повышением потоков напишу статью. А вот с заметками поиск замене я думаю каждый должен для себя делать такие заметки. Такая статья есть но она обшего плана и сильно хитрые правила не описать в ней так что бы она стала понятна всем. Да и не читают ее если честно. Вот она. https://simplepars.top/index.php?page=note&n=37 Не читают и не смотрят видео по настройкам поиск замены, а эту статью не осиливают даже когда я ее отправляю в ответ на вопрос. Так что большого смысла это не сышит.
  11. не не не Вот с вайбером пусть кто то сам. У меня он есть но я туда не захожу. Я сказал кто хочет быстро вязаться, телеграмм а в вайбере я отвечу раз или два в месяц. После двух лет, все нужные люди в телеграмме. Вайбер бесит лагучае гУмно.
  12. Ну еше не готово, у меня но вот вдумайтесь какой уровень взаимодействия с клиентом. Или отвлеченности можно организовать в телеграмм. Можно записывать что смотрел клиент. Можно напоминать ему о своем существовании через меседжер. Можно делать рассылки и напоминания. Предложение. А еше можно анализировать просмотры запросы и поведение клиентов, группировать их по интересам и делать предложения определенным группам. Допустим у вас есть 1000 клиентов кто покупает одинаковый товар. Допустим тарелки и крушки. И 900 из них, так же покупают салатники. Вы берете 100 клиентов которые не покупают, и присылаете им сообщение. Здравствуйте обратите внимание на данные салатники. И показываете товар. А снизу пишите Мы не хотели вас беспокоить, но они будут чудесно сотрется в сочетании с вашими стаканами и тарелками. Короче можно делать вещи. А главное это в телеграм. Где женщина не пропустить это сообщение как происходит с почтой. Где она может переслать сообщение подругам, мужу обсудить и загореться. Маркетинг становится более технологичным.
  13. Я тоже считаю что традиционные интернет магазины горзадо удобнее. А моя бабушка слово интернет не могла выговорить, а мама к примеру до сих пор на покупки через интернет смотри с опаской. А как поведет себя поколоение которое будет сидеть в семеджерах, мне не известно, но вот попробовать подготовится к этому мы можем. Так что что сейчас не идеально может пилится годами и стать неотъемлемой частью жизни через 5-10 лет.
  14. Может позже вернемся к этому вопросу и я сделаю для вас отправку заказа в стандартную систему, но не полноценную а только ту часть что нужно для интеграции с 1с
  15. Не это возможно только в далеком будущем когда делать уже будет нечего. Если не будет мелких краткосрочных задач начну реализацию системы рассылок. Что бы можно было устроить современный маркетинг. что бы были рассылки сообщений напоминания, и так далее.
  16. Да возможно, но это супер нелогично. я понимаю что вам хочется иметь решение проблемы с кривыми Id категорий, но подымать из за этого целый комплекс поиск замены со всеми вытекающими на подобие. Создания блока для поиск замены в дизайне. Хранить данные в базе. Выводить на странице. Обработка в пред просмотре. Обработка при нарезании. Эксопрт этих настроек. Импорт этих настроек. под каждой из этих строк не малый обьем работы который нужно проделать и учитывать в будущих реализациях. И вот это все еше и не будет работать на весь файл а только на блок категорий. И это еше нужно объяснить клиентам. И самое досадное что это нужно просто что бы удалить parentID="1" в одной категории. Если бы это хоть работало на весь файл, то были бы шансы что данный функционал найдет какое-то применение в будущем а так ….. я может гвоздями в коде прибью что если в категории указан ид родителя а его нет, считать эту категорию самой родительской. и на этом и порешаем. Это если такое будет иметь смысл, я еше не проводил ресерч.
  17. Для тех кто хотел поиск замену на весь файл XML. Решил попробовать внедрить и понял почему этого нет)) Если мы хотим сделать поиск замену на весь файл XML где то здесь. То сталкиваемся с большой проблемой. Модуль не держит в памяти сразу весь xml а читает его построчно, а значит нельзя применить правило поиск замены к всему файлу. Так сделано что бы модуль мог обрабатывать файлы большого обьема и не крашится из за нехватки ОЗУ. Так что поиск замену можно применять только к нарезанным товарам. Эта задача тоже пока не реализуем. В теории это можно сделать, но на данный момент цель не оправдывает средства.
  18. Обновление v4.9-7_beta 1) Исправлена один недочет в парсинге файлов. 2) Ускорен париснг XML/YML примерно до 20% Просьба, обратит внимание на скорость до обновления и после и описаться. Так как данная инновация не является финальной и все будет зависит от от вас. Если не будет отзывов. Или не будет повышение производительности у вас, тогда данное изменение будет аннулировано. Решение спорное и требует тестов в разных сценариях. Скорость должна увеличится именно на парисинг нарезанных xml файлов. Так же при больших потоках производительность должна повысится.
  19. Провел тесты, новой обработки xml думал смогу выжать несколько X скорости, но увы. Если у вас хороших хостинг то прирост скорости будет незначительный. Если у вас слабый хостинг тогда прирост будет кратный. Старая технология. 13466 ссылок ориентировочно будут обработаны через 55 минут и 47 секунд. Новый подход 46 минуты 32 сек на том же обьеме работы. Здесь я попробовал исключить веб запросы при обработке xml, это самое дорогое в парсинге. Дорого как по времени так и по ресурсам. В новом подходе это будет исключено. По мимо прироста скорости должно снизится потребление ресурсов, то есть ниже нагрузка. Что то же должно порадовать обладателей бюджетных хостингов. Собственно прирост на производительном хостинге составил около 17% при понижении потребления, что не может не радовать. Хотя я ожидал большего. Завтра закончу и выложу релиз, а от вас просьба замерить производительность. Так как мои расчеты показывали больший прирост.
  20. Найден баг. В модуле в последней версии найден баг с загрузкой файлов. Поправлю к следующему обновлении. Сейчас файлы грузятся битые. Обновление попробую сделать сегодня завтра.
  21. Внимание. Мне нужен проект с xml где после делания файла будет 5000 + товаров. Нужно для тестирования ускорения работы парсинга xml. Пришлите готовый проект с настроенным созданием товаров и тд. Буду признателен.
×
×
  • Create New...

Important Information

On our site, cookies are used and personal data is processed to improve the user interface. To find out what and what personal data we are processing, please go to the link. If you click "I agree," it means that you understand and accept all the conditions specified in this Privacy Notice.