excalibur

Понял. Буду ждать тогда. В лс отправил. Спасибо Адаптацию делал но не помогло. Делал кликом кнопки "Адаптировать". Или нужно еще в ручном режиме какой-то код изменить? Инструкции изучал, сделал все что там было указано.

Странно, утром проверял не было) Может что-то напутал Отправил в личку доступы, у меня какая-то беда с работой вашего модуля, посмотрите, пожалуйста, хотя бы куда копать.. Вроде ничего не модифицировал, ocStore + moneymaker.... Язык меняется только если в строке адреса вписать нужный префикс. Пытался отследить через логи - почему то при перезагрузке страницы у меня три раза загружается startup.php, три раза обновляется переменная сессии кода языка... в логе отображется например gb-en ru-ru gb-en и все это при однократной загрузке страницы... Может я наломал дров в htaccess с переадресациями... Мне нужен https и убирать www.. Посмотрите, пожалуйста

У вас в демоверсии на главной и в информационных статьях тоже нет hreflang ссылок...

применил, но hreflang теги на главное этот модификатор не добавляет, так же как и на информационных страницах. <file path="catalog/controller/common/home.php" error="skip"> <operation error="skip"> <search position="replace"><![CDATA[$this->document->addLink(HTTP_SERVER]]></search> <add position="replace"><![CDATA[ $this->document->addLink($this->url->link('common/home') ]]></add> </operation> <operation error="skip"> <search position="replace"><![CDATA[$this->document->addLink($this->config->get('config_url')]]></search> <add position="replace"><![CDATA[ $this->document->addLink($this->url->link('common/home') ]]></add> </operation> </file> вот это и всё что должно быть? Этого ведь недостаточно. На главной и на информационных тоже нужны теги hreflang

Почему hreflang не применяется к главной и страницам-информационным?

А как на счет мультиязычности?

Это хорошо, но напишите хоть в чем была проблема, какое решение нашли, какая версия опенкарта у вас, для других, у кого может возникнуть такая же проблема

Сразу извиняюсь за некоторые неправильные умозаключения в посте Дело в том, что у меня на сервере в настройках PHP (версия 5.6) папка для сохранения временных файлов значилась tmp. Там действительно появлялись файлики вида sess_*************, НО, только сессий авторизации в cPanel. Как я не пытался где либо найти файлы сессий такого же вида самого Opencarta их нигде не было. Поэтому предположил, что сессии на сервере хранятся как-то в неявном виде, в кеше временном типа, без создания этих файлов сессий во временной папке. Но когда я уже в опенкарте задал другую папку для сохранения сессий, отличную от по-умолчанию, скажем tmp/opencart/ - там начали появлятся заветные файлики сессий sess_*********** каждого посетителя сайта. И эти файлики будут храниться установленное время gc.max_lifetime и очищаться сборщиком мусора, который запускается при каждом вызове сессии с вероятностью gc_probability/gc_divisor Относительно вопроса почему файлов сессий опенкарта не было до этого, хотя в настройках PHP значилась доступная мне папка, там создавались файлы сессий cPanel... Скорее всего эти файлы создавались в папке, к которой на хостинге доступа нет - где-то в /var/lib/php/session.... Если у вас не выделенный собственный сервер, а хостинг - не все доступно для просмотра и тем более редактирования.

Всё. Теперь окончательно со всем разобрался. Стоило просто прописать в опенкарте отдельную папку для хранения файлов сессий. Теперь opencart туда скидывает файлы сессий которые в себе содержат идентификатор пользователя. Если этот пользователь - покупатель - в сессию записываются так же закладки. Если администратор - его айди и токен. Есть три параметра отвечающих за обработку файлов сессий. session.gc_probability integer session.gc_probability в сочетании с session.gc_divisor определяет вероятность запуска функции сборщика мусора (gc, garbage collection). По умолчанию равна 1. session.gc_divisor integer session.gc_divisor в сочетании с session.gc_probability вероятность запуска функции сборщика мусора (gc, garbage collection) при каждой инициализации сессии. Вероятность рассчитывается как gc_probability/gc_divisor, т.е. 1/100 означает, что функция gc запускается в одном случае из ста, или 1% при каждом запросе. session.gc_divisor по умолчанию имеет значение 100. session.gc_maxlifetime integer session.gc_maxlifetime задает отсрочку времени в секундах, после которой данные будут рассматриваться как "мусор" и потенциально будут удалены. Сбор мусора может произойти в течение старта сессии (в зависимости от значенийsession.gc_probability и session.gc_divisor). Таким образом, в файле system\library\session.php задаем нужные нам параметры, если хотим чтобы они отличались от тех, что по умолчанию на сервере. параметры по умолчанию хостера можно узнать выведя функцию phpinfo(); Я у себя создал в папке tmp дополнительную папку для хранения сессий посетитетелей сайта и указал ее в session.save_path и изменил session.gc_maxlifetime на нужное мне время. Теперь всё работает как часики.

@lilianz В сети большинство пишет о том, что нужно в настройках хостинга увеличить время gc.max_lifetime с стандартных 1440 секунд (24 минуты) до требуемых и мол будет счастье. Нифига этот способ не работает, во всяком случае в 2.3 просто потому что обнаружил что не создаются файлы сессии, а сессия посетителя хранится в куки. Чтобы увеличить время жизни корзины - нужно в вышеупомянутом system\library\cart\cart.php поставить INTERVAL x HOURS. Закладки же хранятся в глобальной переменной $_SESSION с привязкой к значению куки default. Всего куки создается 4 - язык, валюта (срок действия - месяц), default и PHPSESSID. Лично у меня на сервере при попытке в файле system/library/session.php session_set_cookie_params(0, '/'); заменить ноль на, например, 7*24*3600 (7 суток) я не мог залогиниться в админку. При этом по сети опять же множество рекомендаций замените ноль на требуемое количество секунд и будет счастье, мол печенька будет жить не сессию, а сколько вам нужно. Проще говоря, и PHP и опенкарт создают по печеньке. Оба используют переменную времени жизни куки. Вот только PHP берет этот параметр и сам его плюсует к текущему времени чтобы установить Expires (действительна ДО), а Opencart создает куки используя тот же параметр сразу как "действительна ДО ...". Поэтому получается, устанавливая параметр в секундах на сервере вместо 0, на определенное значение в секундах - тогда создается корректное куки PHP с именем PHPSESSID, но не создается куки опенкарта так как время недействительное. Если устанавливаем time()+x, создается корректно куки опенкарта, а вот PHPSESSID создается до мая 2065 года (time()+time()+x) Решение нашел такое - в файле вместо нуля установить session_set_cookie_params(7*24*3600, '/'); а в строке где именно опенкарт создает куки if ($key != 'PHPSESSID') { setcookie($key, $this->session_id, ini_get('session.cookie_lifetime'), ini_get('session.cookie_path'), ini_get('session.cookie_domain'), ini_get('session.cookie_secure'), ini_get('session.cookie_httponly')); } заменить ini_get('session.cookie_lifetime') на time()+х секунд Тогда обе куки создаются с одинаковым временем жизни.. При этом куки PHPSESSID живет пока не умрет по сроку давности, а default куки обновляется при каждом запросе к серверу и умрет только если не заходить на сайт установленное количество секунд х.... Опытным путём вычислил сейчас, что те же закладки записываются на сайте в глобальную переменную $_SESSION с привязкой к куки. И очищается эта переменная каждые 1440 стандартных секунд. Поэтому спустя 24 минуты выбрасывает из админки и очищаются закладки. Корзина не очищается потому что есть запись в базе данных. То же самое эффективно и для установок языка, валюты в куки - пользователь заходит на сайт и опенкарт берет значения которые он ему присылает.. А вот с закладками и авторизацией... Идёт проверка в глобальном массиве сессий - если соответствия идентификатора не найдено - увы, от ворот - поворот. И у меня на хостинге мне вроде бы предоставили доступ к изменению параметра gc.max_lifetime но его изменение влияет только на чистку файлов сессий подключений к самой cPanel... но не влияет на время жизни сессий PHP. Либо перебивается каким-то глобальным параметром сервера, который не меняют... Я не специалист... В итоге сейчас возникла идея создавать еще куки закладок, которые будут хранится у пользователя установленное время и при его заходе на сайт подхватываться опенкартом так же, как подхватываются значения выбранного языка и валюты, хранящиеся месяц на стороне пользователя. Хранение в базе - преимуществ не вижу, а минус есть - нужно еще реализовать чистку, аналогичную чистке корзины с определенным интервалом... А вот что делать со временем авторизации админки в 24 минуты бездействия - вопрос. Использовать костыль с пингом сервера не хочется, ибо это актуально будет только для включенного компьютера с запущенным браузером... Надеюсь не запутал своими умозаключениями. У кого будут какие еще идеи или сведения?...

Оформил Guest_favorites.ocmod.xml

Когда-то в версии 1.5 делал доступ к закладкам лишь удалив в контроллере первых несколько строк проверки логина пользователя, и всё работало. Сейчас проделал подобное, но обнаружил, что закладки каким-то образом общие для любых поситителей, любых IP, браузеров устройств. Реализовал работу с закладками исключительно правкой контроллера catalog\controller\account\wishlist.php Убрать строки if (!$this->customer->isLogged()) { $this->session->data['redirect'] = $this->url->link('account/wishlist', '', true); $this->response->redirect($this->url->link('account/login', '', true)); } После строки: $this->model_account_wishlist->deleteWishlist($this->request->get['remove']); Добавить: if (!$this->customer->isLogged()) { $this->session->data['wishlist'] = array_diff( $this->session->data['wishlist'], array($this->request->get['remove']) ); } После строки $results = $this->model_account_wishlist->getWishlist(); Добавить: if (empty($results)){ if (!empty($this->session->data['wishlist'])){ foreach ($this->session->data['wishlist'] as $wish){ $results[]['product_id'] = $wish; } } } Чтобы кнопка "Продолжить" со страницы закладок перенаправляла не в аккаунт а на предыдущую страницу Строку : $data['continue'] = $this->url->link('account/account', '', true); Заменить на: $data['continue'] = 'javascript:history.go(-1)'; И последнее, в конце строку: $json['success'] = sprintf($this->language->get('text_login'), $this->url->link('account/login', '', true), $this->url->link('account/register', '', true), $this->url->link('product/product', 'product_id=' . (int)$this->request->post['product_id']), $product_info['name'], $this->url->link('account/wishlist')); Заменить на: $json['success'] = sprintf($this->language->get('text_success'), $this->url->link('product/product', 'product_id=' . (int)$this->request->post['product_id']), $product_info['name'], $this->url->link('account/wishlist')); Протестировал, у меня все работает, закладки теперь привязаны к сессии, следственно каждый посетитель сайта может накидать закладок и потом из них выбрать и оформить заказ без регистрации (если это доступно), при закрытии браузера закладки не обнуляются, Не могу утверждать что решение идеальное, поэтому кто заинтересован - берите, тестируйте, оценивайте, предлагайте идеи, если можно что-то улучшить. У меня остался нерешенным вопрос - вычислить длительность пользовательской и админской сессии и как их продлить. Решения, найденные на форуме и в сети неоднозначные и описывают замену строк в файле session.php которые гораздо проще чем в версии 2.3.0.1

Убедили :) Непривычно просто все-таки элементарно по причине частоты выхода обновлений - когда-то раньше главные версии программ обновлялись в течении месяцев... Или вовсе раз в год, как на примере многих продуктов типа Corel Draw 13, 14, 15 и т.д.) Поэтому возникает когнитивный диссонанс, когда несколько дней назад установил версию 9.0, а уже 10.0, а еще через неделю, глядишь, будет 12.0 .. :-) И собственно приставка .0 вроде как лишняя - возникает ощущение "перепрыгивания" чего-то необходимого... типа "как 10.0?! А где же 9.2, 9.3, где промежуточная работа?" :D

У вас последнее время частота выхода мажорных версий модуля (8.0, 9.0, 10.0) напоминает тенденцию Firefox... :-D 8.1, 8.2 и т.д. не комильфо выпускать? :lol: "главное число (major) увеличивается, когда происходят значительные переходы в функциональности, второстепенное число (minor) прибавляется только тогда, когда были добавлены незначительные функции или внесены исправления. Номер версии изменяется, если исправлены все мелкие неполадки". Не то чтобы это на что-то влияло, просто ожидаешь мега-нововведений, когда видишь за несколько дней переход версии, а оказывается там пару функций добавлено и кое-что исправлено :-)

Нашел ошибку из-за которой не работал фильтр по дате изменения в списке заказов. Файл admin/model/sale/order.php строка 595 o.date_modified нужно заменить на date_modified. Было: $sql .= " AND DATE(o.date_modified) = DATE('" . $this->db->escape($data['filter_date_modified']) . "')"; Правильно: $sql .= " AND DATE(date_modified) = DATE('" . $this->db->escape($data['filter_date_modified']) . "')";