Улыбнуло, но решил тактично "незаметить".. )
Формально, всё же, я согласен со Sly32 - возможности и применение Python гораздо шире, нежели озвучиваемые собеседниками, пытающимися его обесценить.. ))
а) Точно все изменения были проведены на том же сайте?
б) если открыть картинку в новой вкладке (после правого щелчка мыши по картинке), - откроется ли она.. откроется ли она на том же сайте, в обновлённом виде, в обновлённом формате
в) другие изменения на сайте работают?..
https://en.wikipedia.org/wiki/Python_(programming_language)
Ага, с прицелом на далёкое будущее из начала 90х... (конца 80-х)
А тут есть несколько альтернативных (нежели упомянутый ArbNet) вариантов по использованию языка https://stxnext.com/what-is-python-used-for/
Затем, что далеко не весь "мусор" (который для ИМ - вполне рабочие и нужные, а порой - необходимые данные) нужен в 1С..
Более того, отдельная информация в 1С категорически не нужна..
* это в дополнение к личному кабинету пользователя с данными, историей и "плюшками", который, строго говоря, не совсем админка..
Представляю, как некий условный озон-амазон прислал пользователю многогигабайтный json с актуальной инфой о товарах... на переход с рекламы на главную с мобильного..
* при среднем названии в 100 символов (UTF), описании в 2к символов (тоже UTF, но без всяких смайликов), всякой служебной инфы ещё (цены, наличие-остатки, минимальный заказ, возможность доставки туда-сюда, габариты, вес ...
Харакеристики-вариации с ценами пока опустим, но в уме иметь в виду..) (чтоб считать "круглее" было - берём грубо условных 4000 байт на товар)... Т..е 1к товаров будет занимать примерно 3,8 Мб (без сжатия). 10к товаров, соответственно - 38Мб, 100к - 380Мб...
Пусть мы на лету эффективно сожмём это раз в 10 до 38 Мб..
а) качаться оно будет ощутимо даже при хорошем интернете...
б) на клиенте его нужно распаковать.. и работать с ним как-то..
в) потом получать жалобы, почему "вкладка в хроме" (а ещё интереснее - ваш сайт на мобильном) жутко тормозит.. и отжирает всю память..
А зачем изобретать "что-то ещё", если можно вполне нормально делать?..
Тем более, что в современных реалиях увеличение ассортимента на тысячи - десятки тысяч товаров - вполне обычный итог договорённостей с новым поставщиком.
На таких объёмах товаров (условные 100к) на "нормальном" хостинге с поиском справится и MySQL без эластиков-сфинксов.. Придумывать "что-то ещё" без значительного изменения архитектуры при увеличении количества товаров первое время можно за счёт переходов на бОльший тариф, выделения дополнительных к тарифу ресурсов, переезда на более мощный VPS-дедик, добавление "кубиков" масштабируемому VPS-у, выноса базы на отдельный ресурс,
Естественно, в какой-то момент проще использовать специализированные решения.. Но, всё же, организация поиска по ИМ на клиенте - это, имхо, не очень подходящее решение для ИМ..
Вообще, ссылку на этот ресурс именно в этой теме вторым ответом сам leonid239, и оставил.. )))
p.s. Я бы вот это вот многоразповторяющееся в цикл бы завернул..
Что-то вроде
foreach(strpos($array["response"]["results"]["grouping"]["group"] as $k => $g)if (!empty($g["doc"]["url"],'site.ru'))){$json = json_encode($g); // $array["response"]["results"]["grouping"]["group"][$k]// ...
У яндекса есть (был?) "грант" на 4 т.р. для тестов https://cloud.yandex.ru/docs/free-trial/concepts/usage-grant
По квотам-лимитам - см https://cloud.yandex.ru/docs/free-trial/concepts/limits
Так continue отправляет на "новый заход" в начало цикла, а "запись в базу" - в конце, до неё обработка в этом случае просто не доходит.
...
10 честностей..
Т.е. Вы ищете того, кто делал (смог бы сделать) аналог Кинопоиска на WP?
Как быть при наличии не очень успешного опыта создания очень архитектурно сложного проекта?..
