nogocuHoBuk

Вы всё время копаете не в ту сторону. Опенкарт, как и ocStore ВООБЩЕ не определяет устройство, с которого Вы заходите на сайт. Эта часть заголовков ему не интересна, разве что Вы собственноручно установили како-то модуль/дополнение/скрипт, который может это делать. Но с вероятностью 99.99% подобные "определения" служат для других целей (адаптация, разные шапки, меню и прочее), но точно не для "убийства" сессии... Как вариант - где-то в настройках Андроида включена опция - очищать историю браузера при закрытии. Т.е. при закрытии браузера очищается кеш. Логично, что в таком случае авторизация будет слетать. ЗЫ. Начал писать это сообщение в 2:02 - в это время авторизовался с мобильного на Вашем сайте. Свернул браузер на 28 минут. И вот сейчас в 22:30 открыл браузер - я всё ещё авторизваон. Дополнительно отпишусь утром (если не забуду) ЗЗЫ. Отправил вам в личку видео из которого видно, что проблема не в ocstore.

Да. кавычки не те. либо $this->db->query("DELETE `p1` FROM " . DB_PREFIX . "product_image p1, " . DB_PREFIX . "product_image p2 WHERE (p1.product_image_id < p2.product_image_id) AND (p1.image = p2.image)"); либо $this->db->query("DELETE p1 FROM " . DB_PREFIX . "product_image p1, " . DB_PREFIX . "product_image p2 WHERE (p1.product_image_id < p2.product_image_id) AND (p1.image = p2.image)");

Проще все подобные запросы (тяжелые) повесить на крон (например раз в час, в зависимости от продаж. ВОзможно Вам и раз в сутки хватит) и писать результаты в отдельную таблицу, например oc_product_rating Ну и модулем уже дёргать не из всей базы, нагружая её перебирая все товары и заказы, а брать рассчитанные значения непосредственно из таблицы.

Как я писал выше - я так и не понял что этот запрос делает. Но согласно синтаксису - всё правильно )

Ну так в editProduct добавляйте. Причем учитывая сам запрос можно перед этим вставить: $this->db->query("DELETE FROM " . DB_PREFIX . "product_to_download WHERE product_id = '" . (int)$product_id . "'"); Я всё ещё не понимаю зачем, но всё в Ваших руках И да. Не забудьте обновить модификаторы после изменения модели. Это обязательно.

А кто Вам запрос составлял? Бо DELETE table FROM table не укладывается в моей голове. Не могу понять логику запроса Возможно, конечно, жара и я торможу, но интуиция подсказывает что "что-то тут не так".

Кстати. МОжет Вас просто ДДосят? Отсюда и нагрузка. В момент падения сайта добавьте в htaccess Order Allow,Deny Deny from all Allow from ВАШ_IP_АДРЕС И если сайт в течение минуты оживёт (естественно только для Вас) - настраивайте cloudflare.

У Вас эти запросы в хедере чтоли? Просто непонятно как запрос продаваемых товаров может "уложить", например, страницу контактов. Или под "лежит" Вы понимаете определенные страницы?

В oc_order_product добавьте индексы для product_id и quantity ну и можно создать общий индекс, как написал @buslikdrev для product_id order_id

Первый запрос: Дай восемь id товаров, и количество продаж для самых продаваемых товаров для всех активных, включенных товаров из категории 196 главного магазина со store_id=0 и отсортируй список по количеству продаж. В общем выборка 8-ми самых продаваемых товаров из определенной категории. Во втором запросе какая-то тарабарщина для товара с ID 598 (похоже что считает количество продаж). Не уверен. Не стал вникать Вы б лучше сказали что Вам нужно, и тогда можно подсказать как это сделать ) Ну и для оптимизации запросов с джоинами желательно индексировать группы полей. Да, размер БД слегка (иногда и не слегка) увеличится, но даст прирост в производительности.

Не должно біть никакх ограничений на время хранения сессии. Вполне возможно на телефоне Ві авторизовались "по старым" параметрам. Попробуйте снова авторизоваться. ЗЫ. Скорее всего предварительно нужно сбросить кеш на телефоне. Не уверен, что это обязательно, но на всякий случай.

До смены оператора 90% сайтов определяли моё местоположение как Харьков. Хотя я нахожусь в Киеве. Проблема оператора - пул IP адресов Триолана привязан к Харькову. И подобная ситуация у Воли. Про мобильных операторов вообще молчу - там дичь дикая. Для точного определения местоположения нужны скрипты гугла, с всплывающим уведомлением, типа "разрешить сайту отслеживать Ваше местоположение" и прочими радостями. По IP - задача практически невіполнимая. Ну или как сделано в OLX - определять по IP (с большой вероятностью погрешности) но тут же спрашивать у пользователя: "Ваш город Городище?" - с последующим выбором города и области.

Не php.ini, а phpinfo() Имелось ввиду: 1. В корне сайта создать файл, например info.php 2. В содержимое файла добавить: <?php phpinfo(); ?> 3. Перейти по ссылке https://ваш_сайт/info.php Скинуть сюда информацию о параметре session.gc_maxlifetime или ссылку на этот файл. Дело в том, что изменения в php.ini не всегда отрабатываются, так же как и у хостера в панели управления может стоять разрещенный максимум (например 144000, а при установке большего значения устанавливается дефолт - 1440.

phpinfo из корня сайта покажите, плиз.

Я Вам больше скажу. Страницу можно не закрывать. Достаточно бездействия 1440 секунд (22 минуты). Копать в сторону session.gc_maxlifetime и session.cookie_lifetime.

А вот и комментарий специалиста подъехал. Важное: Резюмируя: 1. Только главная страница сайта без префикса должна быть ******ской. Остальные языки - с префиком. 2. Никаких переадресаций. 3. Даже первый заход на сайт из поисковой системы (в том числе из мессенджеров, чатов, сайтов etc) не считается первым заходом и подобный переход не должен открываться на ******ском языке. Думаю на этом вопрос может быть исчерпан. Статья в FB написал языковой омбудсмен Тарас Креминь. Так что его статью можно считать за официальное объяснение закона.

А зачем эта манипуляция, если не секрет. Суть в том, что место хранения кеша, по сути, может быть изменено хардкорно в коде (в image.php), к тому же могут создаваться дополнительные изображения (при установленных модулях), например WebP и, следовательно, подобный модуль писать нецелесообразно, так как велика вероятность, что модуль не будет работать из коробки и понадобится "допиливать". А кода в подобном модуле, по идее, 10 строк. Т.е. проще для каждого отдельного пользователя запилить решение Потому Вам лучше в услуги (ну либо тут кто-то предложит свою помощь незадорого" ЗЫ. Я так понимаю Вы при редактировании товара удаляете "старые" изображения. При редактировании Вы, например, удаляете одну картинку и добавляете вторую. Так вот в форме не передаётся инфа о том, какие картикни были изначально. Только новые. Следовательно в модели перед "delete FROM oc_product_image" и "UPDATE oc_product" нужно получить массив всех изображений и по пресету /cache/{path/to/image/imagename}-*.{ext} получить файлы из кеша и удалить их. Свои "тонкости", конечно, могут возникнуть, но суть именно такая. Во всех других случаях удалять кеш изображений конкретного товара не вижу вообще смысла.

{% set foo = '' %} {% for breadcrumb in breadcrumbs %} {% set foo = breadcrumb.href %} {% endfor %} {{ foo }} Это если не хотите в контроллер правки вносить. А вообще правильней в контроллере, например перед: $this->response->setOutput($this->load->view('product/product', $data)); Добавьте: $data['samdosebe'] = $this->url->link('product/product', '&product_id=' . $this->request->get['product_id']); И выводите в твиге: {{ samdosebe }}

ААА. Вся моя жизнь летит в пустоту. Спасибо за инфу. Значит будем "спать" 5 секунд, потом спрашивать.

дык в том то и дело, что вопрос в толковании. Токование 1. ЛЮБАЯ страница сайта без куки должна открываться на ******ском. Реализуемо? Вполне. 301 без куки на укр, плюс вешаем куку. Минусы - гугл скажет досвидули. Толкование 2. Никаких переадресаций. Главная без префикса - укр. С префиксом - другой язык. Гугл в восторге. Но что скажет проверяющий? Если читать закон диагонально, можно подумать, что там написано, что закон касается только главной. Моё имхо - это не так Толкование 3. Без переадресаций, но без куки плашка с выбором языка (если язык не укр). Мол "согласно требованиям закона ща вы будете перенаправлены". Закрытие попапа = выбору укр языка и переход на укр версию (аналогичное действие при выборе укр языка). Выбор другого языка - просто закрытие попапа без переадресации. Попап вызывать аяксом, чтобы гугл его даже не видел. Гугл, в принципе, счастлив. Но и требование закона "должен открываться на укр языке" не совсем выполнено, хотя плашка говорит, что "сейчас будет переадресация", хотя она будет ТОЛЬКО в случае выбора укр языка (закрытия попапа).

Вопрос не в натяжке, а в том, как этот закон будет интерпретировать проверяющий. Я, собственно, потому и написал - нужно ждать первых судебных тяжб и надеяться, что либо в закон внесут изменения, либо уполномоченные орграны дадут разъяснения по этим моментам. И да, я у себя на сайте сделал так же, как и Вы. Никаких переадресаций. Главная (без префикса) на ******ском, главная оркская - с префиком ru. Но есть одно огромное отличие. Я понимаю, что закон несовершенен и вс' будет зависеть от толкования, потому ГОТОВ заплатить штраф, если мне его начислят. А вот для Вас, когда/если придет проверяющий на один из сайтов, где Вы убедили заказчика, что всё в рамках закона - будет неприятная неожиданность... Ну или Вы правы. Тогда и мне не о чем переживать.

Вы по диагонали закон читаете, чтоль? Да, интернет-представительства это интернет-магазины в том числе :)

Ну як це не вказано? Вказано. Не зовсім зрозуміло до чого це питання. Сайти вже мають повний переклад усіх можливих сторінок, товарів, блогу, новин, реклами та іньше... Питання виникає лише в переадресаціі. І його я описав в першому своєму пості в цій темі.

Поддерживаю предыдущего оратора. Главная у меня открывается українською. Остальные ссылки без переадресаций. Т.е. если пользователь перешел по линку uk - попадает на укр версию. Да, если "проверяющий" захочет докопаться (перейдя по ру линку и попав на ру версию, например site.ua/ru/tovar1, придётся доказывать, что я не верблюд. Закон в єтом плане неоднозначен, но я принял решение, что готов заплатить штраф, чем вариант с "выплевыванием" гуглом всех моих проиндексированных страниц и товаров. Вот тут было "крайнее" обсуждение в тему. Там слегка "срачег", но суть спора и варианты реализации предложены, вроде, все (как правильный, так и остальные ).

Если вопрос стоит так - Вам лучше в услугах поискать. Ну или в личку напишут 100% с предложением реализации. То, что я написал выше - способ получения отображаемых товаров. Подробнее - Вам не поможет, на сколько я понимаю. Потому лучше наймите специалиста.