Dram: Хочу повестить все это дело на крон но не могу придумать как автоматически менять категорию на другую?
if (условие, при котором менять категорию) // кончились товары в "Этой" - дошёл до последней страницы,..
$category = 'другая'; // между запусками можно сохранять в базу/файл
А вообще можно в "очередь" закидывать то, куда заглянуть надо.
Разных типов - "Список категорий", "Категория с товарами" (+ постраничная разбивка), "Товар".. при разборе каждой формируется набор для следующих.
Dram: В базу записалось 2 одинаковых товара - 2 раза записался первый товар, еще раз прогнал - опять они же записались )
Видимо, имеет смысл перед записью проверять наличие этого товара в базе.. по какому-то уникальному идентификатору (ID в прайсе, либо название).
if (!$good = Good::find(array('id_inner'=>$row['id_inner']))
$good = new Good;
// .. устанавливаем атрибуты
$good->save();
А ещё есть фишка - импортировать всю таблицу в таблицу в память (тип Memory) и
а) если товары точно есть
UPDATE product p INNER JOIN tmp_product tp SET p.price = tp.price, p.status = tp.status
б) старые обновляем, новые добавляем
INSERT INTO p (id_inner, name, price, status ...) SELECT id_inner, name, price, status FROM tmp_product tp
ON DUPLICATE KEY UPDATE name = tp.name, price = tp.price
TF-Studio: к примеру размеры. пользователь может завести в мм, см, мм итд
Возможно, имеет смысл привязывать свойства к категориям..
Вес ювелирки в каратах, вес приправ-сыпучек в граммах, вес гантелей в кигограммах и вес машин-прицепов в тоннах.. по сути - это разные веса (массы.. но не суть)..
Заведённые пользователем - пересчитывать к основной (хранить оба - "реально используемое" значение и значение "от пользователя") .. и при поиске "поисковое" занчение приводить к "основной" и искать по нему.. Результаты можно выводить удобно "для пользователя" (как вариант - уже при выводе характеристики пересчитывать её значение.. )
burunduk: лучше class добавить к таким ссылкам и обрабатывать событие клик именно на элементе с классом
Лучшее, говорят, враг хорошего.. )
Если, к примеру, "якоря" в статье (а-ля содержание) указываются в WYSIWYG-редакторе админки, то автор (а если они ещё и меняются..) может банально забыть класс добавить.
Для 10k обращений при наличии 1000 ссылок на странице.
By class: 4606 ms
By regexp: 4989 ms
Не скажу, что класс намного быстрее.
Если у ссылок убрать #якоря:
<a class="blabla" href="blabla">
By class: 4680 ms
By regexp: 1703 ms
Если не совпадает класс и в ссылках нет якоря:
<a class="bla" href="blabla">
By class: 355 ms
By regexp: 1436 ms
* для последнего варианта получается 0,15ms (vs 0,035) на далеко не последнем компьютере.. Насколько это соизмеримо, к примеру, со временем загрузки JQuery.. или с расходами на выпадающие менюшки/слайдеры и прочее.. решать
ТАДАМ,,,, получаю 8 записей!!! Какого фига вместо 4 - 8 ??
второй раз туда заходит же ))
Хочу повестить все это дело на крон но не могу придумать как автоматически менять категорию на другую?
А вообще можно в "очередь" закидывать то, куда заглянуть надо.
Разных типов - "Список категорий", "Категория с товарами" (+ постраничная разбивка), "Товар".. при разборе каждой формируется набор для следующих.
если банальный цикл из 4 итераций уходит на второй круг,
Так смотри код.. или кидай, вместе посмотрим )))
В базу записалось 2 одинаковых товара - 2 раза записался первый товар, еще раз прогнал - опять они же записались )
Видимо, имеет смысл перед записью проверять наличие этого товара в базе.. по какому-то уникальному идентификатору (ID в прайсе, либо название).
if (!$good = Good::find(array('id_inner'=>$row['id_inner']))$good = new Good;
// .. устанавливаем атрибуты
$good->save();
А ещё есть фишка - импортировать всю таблицу в таблицу в память (тип Memory) и
а) если товары точно есть
б) старые обновляем, новые добавляем
к примеру размеры. пользователь может завести в мм, см, мм итд
Возможно, имеет смысл привязывать свойства к категориям..
Вес ювелирки в каратах, вес приправ-сыпучек в граммах, вес гантелей в кигограммах и вес машин-прицепов в тоннах.. по сути - это разные веса (массы.. но не суть)..
Заведённые пользователем - пересчитывать к основной (хранить оба - "реально используемое" значение и значение "от пользователя") .. и при поиске "поисковое" занчение приводить к "основной" и искать по нему.. Результаты можно выводить удобно "для пользователя" (как вариант - уже при выводе характеристики пересчитывать её значение.. )
https://www.php.net/manual/en/function.flush.php
а в избежании ошибочного срабатывания если у внешней ссылки есть якорь
$('a[href^="#"]').on('click'...Cработает, только если href у ссылки ^начинается с # ;)
лучше class добавить к таким ссылкам и обрабатывать событие клик именно на элементе с классом
Лучшее, говорят, враг хорошего.. )
Если, к примеру, "якоря" в статье (а-ля содержание) указываются в WYSIWYG-редакторе админки, то автор (а если они ещё и меняются..) может банально забыть класс добавить.
p.s. Для аргументированных рассуждений на тему производительности vs удобство предлагаю: https://jsfiddle.net/wo9pfk8v/
Для 10k обращений при наличии 1000 ссылок на странице.
By regexp: 4989 ms
Не скажу, что класс намного быстрее.
Если у ссылок убрать #якоря:
By regexp: 1703 ms
Если не совпадает класс и в ссылках нет якоря:
By regexp: 1436 ms
* для последнего варианта получается 0,15ms (vs 0,035) на далеко не последнем компьютере.. Насколько это соизмеримо, к примеру, со временем загрузки JQuery.. или с расходами на выпадающие менюшки/слайдеры и прочее.. решать
$('a[href^="#"]').on('click'...А файл в кодировке unicode? ))
В ANSI - сработало, в UTF-8 - нет.
---------- Добавлено 28.05.2019 в 16:31 ----------
$re = '~<td>[a-zа-я ]{5,90}</td>~isu';