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

Axelenz

Users
  
  • Posts

    744
  • Joined

  • Last visited

Everything posted by Axelenz

  1. Предложение для расширения функционала. Часто сталкиваюсь с тем, что у клиентов работают в связке модули SimplePars и АОП (как вариант). Если много проектов, то приходится повозиться с настройками, чтобы всё включалось в работу последовательно и отрабатывало правильно. Предлагаю в новые релизы включить функционал, который может несколько облегчить настройки. Я бы назвал это "задержка". Разместить его в "Настройка задания" в cron. Как пример: - включается в работу SimplePars по cron в 12-00; - включается в работу АОП в 12-00. Причём АОП должен обрабатывать данные, которые он получает с SimplePars. Перенести на другое время нельзя, необходимо быстро обновить (пусть выгрузка с 1С) через АОП то, что получено от SimplePars. Выход из положения. Пусть "задержка" - это будут минуты, диапазон 1-60, могут принимать так же и отрицательные значения. Т.е. "задержка" -5 при указании в cron "Часы" 12-00 означает, что cron сработает в 11-55 с учётом "задержки" -5. (Если "задержка" 5, то cron начинает работу в 12-05 и т.д...) Тогда получим, что, например, за 5 минут до 12-00 SimplePars уже начинает работать и АОП (или другой модуль) в 12-00 может получить необходимые данные данные. Это всего лишь как предложение для рассмотрения.
  2. https://simplepars.top/index.php?page=note&n=53 Почитайте документацию, вопросы отпадут... И вообще, с таким размером xml необходим что тарифный план приличный, что настройки php смотреть, по умолчанию, как правило, всё по минимуму выставлено на хостинге.
  3. Если SimplePars не работает через cron на этом хостинге, то или перейдите на более высокий тариф (там он точно работает) или смените лучше хостинг... Вся проблема Ваша в том, что в начальном тарифе у них не предусмотрена в планировщике работа cron по времени: * * * * * Поясню на примере: У Вас есть сумка и Вы пришли с ней в магазин купить хороший инструмент. Оказалось, что он не влезет в Вашу сумку и Вы говорите, что инструмент плохой... Так может сумку под него необходимо другую приобрести ?
  4. Bitrix может хранить в кеше не только размер 100х100 потому я и нарисовал регулярку универсальную, не зависящую от размера, подходит практически на любой сайт... Ну или завтра захочет поставщик увеличить размер и сделать 200х150 и что ? А регулярка будет работать и завтра и через год...
  5. Чтобы покороче написать, то можно использовать такое регулярное выражение: (/resize_cache| - перед ним не нужно) {reg[#resize_cache/(iblock/[^/]+/)[^/]+/([^.]+\.jpg)#]}|$1$2 а если заморочиться, то можно и так написать: {reg[#resize_cache/(iblock/[^/]{3}/)[^/]{3,}/([^.]+\.[befgijpstvw]{3,4})#]}|$1$2
  6. Было бы весьма замечательно, если бы Вы "прибили гвоздями" в коде сразу же самые часто встречающиеся возможные ошибки (ну хотя бы в том же самом блоке категорий) и указали, что всем желающим лезть в файл ... в строку № ... Это намного упростило бы жизнь, потому, что когда мы сами вносим что-то в файл, то привязываем клиента к определённому релизу... А если клиент в следующий раз будет работать с другим исполнителем и тот обновит модуль, то как ? Да и самим помнить, кому и какие вносили изменения в модуль, сомневаюсь... Поэтому на мой взгляд это было бы самое правильное решение - вещи, которые трудновыносимые во вкладки модуля всё же реализовывать в модуле посредством дописывания кода и комментированием его (кому нужно - расскомментирует).
  7. А зачем поиск/замена на весь xml если это и так дальше реализовано в соответствующей вкладке ? Из-за ошибок в блоке категории возникают дальнейшие проблемы. Возможно ли сделать поиск/замену только для этого блока ?
  8. Да, тут соглашусь, сам сталкивался с вариантами, когда это очень помогло бы избежать дальнейших придумок... Выбор "или" в этом месте это было бы здорово.
  9. Прайсы в .xls это как анахронизм какой-то... Да, раньше почти все сайты в этом формате отдавали данные, но сейчас то xml/yml это давно уже формат де-факто... ну иногда ещё и CSV встречается, но то такое (формат полностью не стандартизирован)... Не думаю, что модулю это вообще нужно... вперёд лучше смотреть, а не оглядываться назад.
  10. Зачем это нужно, если есть АОП ? Ответ только один: для экономии, чтобы не покупать два модуля, а обходиться одним... А мне больше хотелось бы видеть реализацию работы с "кривыми" выгрузками xml/yml (без правки самих файлов модуля), которых не мало, а не дублирование того, что и так уже реализовано у других...
  11. По ссылке можно найти такой ответ и что следует дальше делать. Но без информации c php.ini трудно что-то предполагать... и что за тарифный план, насколько он позволяет разогнаться ? PHP ошибка Fatal Error. Как решить проблему? Я себе на локалке поставил, например...
  12. Не скажу даже... но в модуле стоит логика, что делать При обновлении Обновлять или Не обновлять ... очевидно, что такая логика выбрана исходя из того, что товар не может быть загружен без Цены. Поэтому товар загружается всегда с какой-то ценой, а обновлять её в дальнейшем или не обновлять... это уже на выбор... Если бы были отдельные поля Цен, что делать При добавлении и отдельно При обновлении... это конечно решило бы много подобных проблем... Ну можно ещё добавить логики в уже существующую в модуле логику, например {ifup[]} и {ifadd[]} соответственно... Если обновление и если добавление... Но тогда вопрос с дальнейшими обновлениями модуля... Сам всегда в подобных случаях использовал скрипты, но это тормозит возможности использования мультипоточности (
  13. Но это необходимо управление не самой ценой а действием над ценой: обновлять или не обновлять. Тут с помощью имеющейся логики не получится, она как раз работает с ценой. Два проекта без скриптов будет нормально... Но тут необходимо знать, используются ли уже скрипты в данном проекте. Если используются, то можно и ещё один добавить... тогда получится обойтись и одним проектом. Как вариант, можно попробовать предложить модулю внести в цену заведомую ошибку (например - текст). Пример: Делаем дополнительную границу, в которой заменяем наименование всех (кроме двух) Производителей на 1. Имена тех, где не нужно обновлять меняем на 0. Делаем в цене проверку 1 или 0. Если 1, то используется граница с ценой, если 0 - то подсовываем, например, границу с названием Производителя. Это ошибка и тут вопрос, как модуль это воспримет... можно попробовать, может он просто оставит прежнюю цену...
  14. Тогда и я вставлю свои 5 копеек... Подобное происходит потому, что у клиента на хостинге время у планировщика выставлено не так, как рекомендует сам разработчик модуля: * * * * * (ежеминутный старт), а вот так: 0 * * * * (или что-то похожее...) А это далеко не одно и то же... Это значит, что cron должен срабатывать не ежеминутно, а каждый промежуток времени, кратный 10 (десяти). Т.е. в 10, 20, 30... минут. Вот cron и срабатывает не ровно в 2 часа, а ровно в 2 часа и 10 минут и выполняет обработку xml 16 секунд и парсинг 16 секунд. Если бы товаров было много и он не успевал бы обработать всё за 1 минуту, тогда произошёл бы останов по окончании минуты и следующий запуск и работа cron продолжилась бы в 2 часа и 20 минут... я так себе это представляю... Следующий запуск cron произойдёт через 4 часа, согласно настроек модуля... т.е. в 6 часов и 10 минут... Только вот дёргать каждые 4 часа обновление 374 товаров... смысл такой себе ) Ну 2-3 раза... это какая высокая оборачиваемость товара должна быть, чтобы требовалось постоянное обновление остатков...
×
×
  • 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.