nogocuHoBuk

Добрый. Пытался изучить правки, вносимые модулем в url.php но не смог получить ответ на свой вопрос. Суть. Формирую sitemap.xml одним файлом согласно рекомендации гугла. На примере формирования линков для products. $this->url->link('product/product', 'product_id=' . $product['product_id']) Но ссылка формируется учитывая текущий язык. А учитывая, что в каждом товаре нужно сформировать 2 линка (ru и uk) для alternate приходится "переключать" язык в системе на лету. И раньше использовал для этого: $this->config->set('config_language_id',$lang_id); Однако при оспользовании модуля в url.php добавляются условия для прописывания префикса языка. Не долго думая добавил в url.php: Ну и в сайтмапе функция переключения языка выглядит так: private function set_lang($lang_id) { $this->config->set('config_language_id',$lang_id); $this->url->add_prefix_f($lang_id); } Да. Это костыльный костыль, потому вопрос к автору модуля. Есть ли какой-то более "мягкий" способ получения корректного линка посредством $this->url->link() для указанного языка? Т.е. с возможностью указания $lang_id для "формирователя" ссылки?

фид для переноса на озон? Очень интересно. Понаблюдаю за темой ЗЫ. Думаю Вам, для начала, стоит прочитать документацию озона. Через фид можно ТОЛЬКО обновлять остатки и цены к уже добавленным товарам.

Ну, или, измените положение блока алерт, например вот так: Или так: В стили в /admin/view/stylesheet/stylesheet.css например (ну или какой свой стиль, если что-то подключаете) добавьте что-то вроде: .alerts { z-index: 1001; position: fixed; top: 0; left: 0; width: 400px; } А дальше єкспериментируйте с местоположением

Это Admin Quick Edit PRO. Нужно смотреть в его скриптах, там 146% указано время отображения для "fade in"

Любой скрипт выполняется на устройстве посетителя. Следовательно работать он сможет исключительно в рамках тех товаров, которые в данный момент отображены. В Вашем случае нужно делать отдельный контроллер для аякс запроса, который будет обращаться к БД, дёргать нужные товары (по поиску) и возвращать результат в виде либо готового html, либо в json и дальнейшим отображением скриптом.

Столько вопросов сразу Какая версия опенкарта? Какую цель преследуете? Почему сразу не установить цену для товаров на 9% ниже? Нужно именно феййовое отображение скидок? Попробуйте поискать вот так: "как назначить фейковые скидки в опенкарт" Нужно отображение процента скидки? Как поступать, если понадобятся дополнительные акции? Вы представляете какой ад будет твориться в разделе "Акции" ( index.php?route=product/special )? В него ж и фильтр нормально не встроить. Там будет просто полотенце ВСЕХ товаров вашего магазина. Но если эти вопросы Вас не пугают - есть готовые решения, которые будут точно дешевле, чем делать модификатор с нуля (да и с большим функционалом) Ищите по словам "Bulk Special" или "Массовая скидка". Либо массовое редактирование. На этом форуме есть вот такое решение: Из удобного, чем пользовался я: Bulk Discount/Special 3.x

Тай таке Дивно, що у Вас на руках вже був запит, котрий виконується 0.007с, а Ви використовували той, що працює 210 секунд. Хоча це, можливо, якщо не було WHERE pr.quantity > 0 Ну, врешті решт, вітаю. 0.007(0.008) то вже не прискорити

Доречі. У Вас тут має бідкатися БД на те, що немає аліасів. Потрібно якось так: 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) AS per ON pr.product_id = per.product_id SET pr.quantity = 0 WHERE pr.quantity > 0 (додав ще й перевірку на кількість більше 0) Але мені здається цей запит будет довшим за той, що я пропонував раніше. Бо там для IN вибираються виключно ті product_id у яких кількість в oc_product більше 0. В останньому ж запиті кількість записів для обробки значно більша. PS. Ну і в такому вигляді потестуйте чи є різниця між SUM та MAX. То вже мені на майбутнє

КРщае перевірити 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 SUM(prov.quantity)=0 Бо на моїх 100 записах час в межах похибки У Вас точніше буде.

Мені здається (я навіть впевнений) що SUM() буде працювати швидше, ніж MAX() SUM(prov.quantity)=0

Знайшов рішення UPDATE `oc_product` pr SET pr.quantity=0 WHERE pr.product_id IN ( SELECT prod_id FROM ( SELECT prov.product_id AS prod_id FROM `oc_product_option_value` prov LEFT JOIN oc_product op ON op.product_id = prov.product_id WHERE op.quantity > 0 GROUP BY prov.product_id HAVING MAX(prov.quantity)=0 ) AS pid ) Задля наочності написав у кілька рядків. Суть полягає в тому, що SELECT вибирає лише ті product_id для IN, де кількіть в oc_product більше 0 Ну і таке рішення само по собі буде швидше. Ваше перше рішення: 1.37 секунд Мій перший варіант, з додаванням перевірки кількості: 0.79 секунд Остаточне рішення: 0.05 секунд Нарешті можу і в люлю)

Це все "Stranger Things"

додайте oc_product_quantity до индексу ALTER TABLE `oc_product` ADD INDEX(`quantity`) І насолоджуйтесь Бо перший запит апдейта до кількості. Дайте змогу вибрати значення миттєво (в переносному сенсі, звісно). Навіть при 15к записів навіть 160 секунд це ДУЖЕ багато.

Так. То вже я тупанув. При повторному запиті має зрости до 0. (звісно залежить від часу виконання SELECT'а) Тому краще повісити на крон раз в день/12 годин/годину в залежності від кількості продаж. Може раз на день, а може й раз на годину При періодичному виконанні кількість апдейтів буде стабільно мала.

Такий запит буде швидше, (при наймні в данному випадку): SELECT DISTINCT prov.product_id FROM `oc_product_option_value` prov WHERE `quantity` = 0 аніж Ваш SELECT prov.product_id FROM `oc_product_option_value` prov GROUP BY prov.product_id HAVING MAX(prov.quantity)=0 А час виконання апдейту залежіть, мені здається, від того, яку кількість product_id повертає попередній запит. Тому в UPDATE краще зменьшити кількість апдейтів, додавши в запит перевірку на кількість. UPDATE `oc_product` pr SET pr.quantity=0 WHERE pr.quantity > 0 AND pr.product_id IN (SELECT DISTINCT prov.product_id FROM `oc_product_option_value` prov WHERE `quantity` = 0); Таким чином не будуть апдейтітись поля, в яких ВЖЕ кількість дорівнює 0.

В том то и дело, что качество зависит от опыта, а не от времени. Или Вы хотите сказать что собранная Вами за 15 минут прошивка говно, в стравнении с той, которую собирает "другой мастер" за неделю? Вы же сами себе противоречите)

Вы не совсем правильно рассуждаете. Стоимость часа - ориентир в 99% случаев. Если задача конкретная, по которой можно оценить трудозатраты - Вам так и напишут: "Сделаю за 3 часа". И Вы можете прикинуть ваши расходы. У одного 5 в час, но сделает за 15 часов. (3 календарных дня) У второго 30 в час, но сделает за 4 часа. тут Вам выбирать. за 75 но ждать 3 дня (потом, опять же, тестирование) Либо "к вечеру", но за 120. Иногда задачи 5-ти минутные, но перед тем, как что-то выполнить, нужно перечитать задачу, побеседовать с заказчиком, обсудить варианты реализации, получить доступы, подключиться к серверу (а там, часто, закрыты доступы по IP, а заказчки не знает как добавить исключения. Пароль "старый" скинул, ща у бухгалтера запрошу. Ой, а у меня нет доступа к FTP, я думал через админку можно... и т.д.), СДЕЛАТЬ ВСЁ ЗА 5 МИНУТ, протестировать, отдать на тестирование заказчику, получить фидбек, попросить заплатить, проконтролировать оплату. Закрыть задачу. И чаще всего это тоже время, потому часто пишут: Час работ - $30 Минимальное время задачи - 2 часа. И суть не в том, что человек не берется за 5-ти минутные. Просто хочет получить оплату за ВСЁ потраченное на заказчика время. А почасовка - вынужненная мера. Вы даете ТЗ 5-ти исполнителям на оценку. И по времени реализации можете примерно прикинуть опыт исполнителя. Если 4-ро из 5 напишут что на задачу нужно 3 часа, а пятый напишет, что 20 часов - Вы разве не сообразите кто опытней? А уже ПОТОМ спрашиваете ставку за час у каждого из 4-х. И если ставка одинаковая - выбираете того, кто смазливей Всё ж просто.

Ну дык у "другого мастера" и расценки другие, нет? Ведь если "тот мастер" возьмет за прошивку 1000 рублей это совсем не значит, что Вы это сделаете за 5 рублей. верно?

Нет. Не перезалить. По ссылке выше даже в описании написано, что это надстройка, т.е. она работает ТОЛЬКО вместе с оригиналом Там, собственно, всё расписано. Или Вы просите, чтобы я Вам с англиского на понятный перевёл? Ведь по сути именно это и придется делать. Ну и если возникают такие вопросы, думаю, лучше найти специалиста, который интегрирует.

В пользовательские CSS добавьте: #ocd_multilang { float: none !important; } #ocd_multilang .btn-group.open { width: 100%; } первый предотвратит схлопывание: Второй развернет блок языка на всю ширину, по примеру переключателя валют:

Причем Вы сделали что-то только для фильтра в функции getProducts(), но не предусмотрели того же фильтра для getTotalProducts(), который и используется для пагинации. Т.е. запрос к getTotalProducts() не учитывает тех фильтров, которые применяются для getProducts() и возрвщается большее количество товаров для расчета постраничного показа.

Доброго времени суток. С этим моментом, конечно, всё понятно - по умолчанию SEO URL для каждого языка свой. Но ЧАСТО бывают исключения, когда нужно принудительно задать одинаковый SEO URL Когда это касается товара, то с большой вероятностью сео_урл будет разный, так как названия в разных языках будут транслитерироваться по разному, НО есть, например, производители Пример: Производтель Apple Я задал и для украинского и для русского одинаковый SEO URL - "apple" А есть же ещё формирование ссылок вместе с категориями. При одинаковой транслитерации прописываешь, например для русского - "-ru", а для украинского "-ua" (или можно оставлять пустым), но вот такой путь, мне кажется, уже перебор для en: /house/foundation/cement/material для ru: /house-ru/foundation-ru/cement-ru/material-ru для ua: /house-ua/foundation-ua/cement-ua/material-ua Ведь куда удобней было б: для en: /house/foundation/cement/material для ru: /ru/house/foundation/cement/material для ua: /ua/house/foundation/cement/material Так вот к чему я это. Есть ли возможность для ocStore 3.0, всё же, заставить этот триклятый код языка показываться?

Simple использует inputmask И автор это указывает, обращая внимание пользователей, что вопросы с работой плагина в поддержку не входят Но есть надстройка для этой библиотеки - inputmask-multi Т.е. можно подключить и тогда для цифр будет использоваться не 9, а # и можно смело задавать маску: +998-##-###-####

Чтобы было понятно. Та картинка, которую Вы прикрепили, на самом деле png, но поставщик отдает её c расширением .jpg. Программам на компьютере по сути фиолетово на расширение. Ибо расширение служит лишь для того, чтобы понять какой программой эту картинку открывать. Т.е. видим, что расширение jpg/png/gif/bmp/etc - значит это изображение. Открываем, например, редактором. А уже редактор читает содержимое файла и определяет mime type и от него зависит работа с картинкой. Аналогично с браузером. Ему не важно что за расширение у картинки. А вот встроенному "сжимателю" опенкарта - НЕ всё равно. Так как он ориентируется именно на расширение. И код выше, как раз, исправляет это проблему в библиотеке. Т.е. заставляет применять функции сжатия (imagegif(), imagepng(), imagejpeg()) основываясь не на расширение файла, а на mime type изображения.

Если с хостингом нет проблем и оригинальные изображения нормальные, то миниатюры создаются практически мгновенно. Не нужно самому в папку кэш ничего помещать. Сжимайте оригиналы и, думаю, всё решится само собой.