remix8080
-
Публікації
177 -
З нами
-
Відвідування
Тип публікації
Профілі
Форум
Маркетплейс
Статті
FAQ
Наші новини
Магазин
Блоги
module__dplus_manager
Усі публікації користувача remix8080
-
Я з західної частини країни. Те, що Ви пишете в п.5-6 - це якась куйня. Хоча, всюди є всякі неадекватні створіння
-
Доброго. Я колись використовував таку : +38(999)999-99-99 Виходило, як на фото.
-
Доброго. Щоб добавити "=" в опції - тут. П.С. Сам не користувався.
-
Вітаю. Один з варіантів - не унікальні SEO URL для товарів.
-
Вітаю. Теж трохи додам.
-
Вітаю. Ви не вказали версію. Для 2-ки тут.
-
Так і я про це. @Freestyle2020 , а яка специфіка товарів? Покажете сайт? Можна в пп.
-
Моє імхо. Жоден автоматичний переклад не дасть 100% правильного результату. Можна таким скористатися, а далі вже "шліфувати" вручну. Для однотипних товарів можна буде використати UPDATE `oc_product_description` SET name = REPLACE(name, 'старий_текст', 'новий_текст') WHERE language_id=|код укр.мови| Так, займе трохи часу, але хендмейд є хендмейд )
-
@Freestyle2020 жартуєте? А уважно прочитати? desCription.
-
Вітаю. Зустрічав лише під 1.5 https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=16710
-
Так, і не інакше.
-
Перепрошую за довгу відповідь, був не на зв'язку. Ця "потреба" була не на постійно, а тимчасово. Для редагування зображень певної кількості товарів (мінялися і шляхи і назви файлів). Вирішив, що "шкурка вичинки не варта". Після заміни очищу махом кеш зображень та й все. П.С. Дякую за відповіді та приділену увагу!
-
Вітаю. Можливо, хтось зустрічав "лайфхак" для очистки кешу зображень, але лише конкретного товару після його редагування? Тобто, щоб при його (товару) збереженні видалялися зображення всіх розмірів. Дякую. П.С. ocStore 1.5
-
Це була одна з неробочих чернеток (не пригадую, не записав, але там були якісь нюанси). Ще раз Вам щиро вдячний за допомогу!
-
На рахунок аліасів так, я написав не цей свій варіант (поплутав). Поекспериментував: Ваш попередній запит в мене, в середньому, виконується 0,08с. Крайній запит: при MAX - 0,007с, при SUM - 0,008с.
-
При ~ 3,5К записів в oc_product_option_value один і другий запит 0,0018с
-
Думаю, не істотно, оскільки запит з MAX виконується практично моментально. UPD. При великій кількості записів в oc_product_option_value - безперечно.
-
Для одного товару з oc_product може бути кілька записів в oc_product_option_value, серед яких не всі quantity=0. Тому через MAX вибираю всі нульові.
-
Доброго дня. Якось так UPDATE oc_product pr INNER JOIN (SELECT prov.product_id FROM `oc_product_option_value` prov GROUP BY prov.product_id HAVING MAX(prov.quantity)=0) ON pr.product_id = prov.product_id SET pr.quantity = 0
-
Пробував, експериментував - не вийшло (
-
Брр, не знаю як, але відпрацювало практично моментально. Розбиратися/аналізувати вже буду завтра ) Як в Петрика П'яточкіна. "Ура, 10 слоненят. Тепер я засну" )))
-
Індекс додав. Час не змінився. Та то вже таке... Ще раз вдячний за допомогу!
-
Всі наступні запити також виконуються такий самий час (~160с). П.С. Саме на крон і планую згодом повісити деякий "пучок" запитів.
-
Не варіант. Цей видасть товари, в яких ХОЧА Б ОДНА опція має залишок 0. А я вибираю ВСІ такі товари. Та й швидість цього запиту практично не береться до уваги. Результат видає не багато, ~ 200 товарів. Перевірку не додавав, думав, не дасть приросту. Але все-таки при pr.quantity>0 зменшився час з 210с до 160с. Вже результат ) П.С. Вдячний за відповідь.
-
Специ, підкажіть, як можна оптимізувати/прискорити цей запит? Виконується більше 3 хв ( UPDATE `oc_product` pr SET pr.quantity=0 WHERE pr.product_id IN (SELECT prov.product_id FROM `oc_product_option_value` prov GROUP BY prov.product_id HAVING MAX(prov.quantity)=0); Сам селект SELECT prov.product_id FROM `oc_product_option_value` prov GROUP BY prov.product_id HAVING MAX(prov.quantity)=0 виконується практично миттєво.
