Dotrox

На текущий момент это не имеет значения, но https там уже есть, так что его указание в этих ссылках никаких проблем не вызовет. Но и отсутствие там https сейчас (и в обозримом будущем) тоже проблем вызывать не должно. Кстати, уберите в баннерах вообще домен (пусть ссылки будут относительными), а то у вас сейчас там везде (слайдер, карусель производителей) ссылки остались с http. И поправьте ссылку контактов в футере. Вероятно, она там вообще вручную вписана, потому что у неё даже ЧПУ нет, хотя при переходе редиректит на ЧПУ.

Так я ж и посмотрел и написал что увидел. Модуль то бесплатный, посмотреть не проблема. Так что откуда берутся в сайтмапе http - непонятно. Разве что в конфиге HTTP_SERVER без https (хотя на скрине выше - обратное) и тогда всё логично, поскольку модуль третий параметр в $this->url->link не ставит и если оно в /system/library/url.php не поправлено, то вполне логично, что ссылки без https. А вообще, я открыл сайт и как-то совсем не похоже, чтоб там было так: Там полная каша с протоколами, но преобладает всё же именно http, так что могу предположить, что и в конфигах HTTP_SERVER без https и в /system/library/url.php правки нет.

Ну, не считая вот этого для главной страницы: $output .= '<loc>' . HTTP_SERVER . '</loc>'; ссылки там формируются через $this->url->link, так что, если в конфигах вы везде вписали ссылки с https (как на вашем скрине) проблем быть не должно (и даже с главной).

$this->url->link - это в контроллерах при формировании ссылки. А в этом файле это просто функция link и её третий параметр ($connection = ''). Просто впишите в эти пустые кавычки - SSL. Но, если у вас в конфиге уже везде вписаны ссылки с https, а на сайте всё равно где-то остаются ссылки с http, значит у вас есть как раз те кривые модули, которые лечит модуль Марка (либо ручная правка кода этих модулей) и эта правка в link всё равно не поможет. Можете, кстати, написать авторам этих модулей, такое они обязаны исправлять даже, если модуль бесплатный, ибо такого изначально не должно было в модуле быть (в смысле вбивания протокола прямо в код). А я говорил совсем не об этом. Я ничего не имею против исправления вашим модулем кривых модулей. Я говорил о вашем былом утверждении, что поправить /system/library/url.php - это костыль и только ваш модуль правильное решение. Как я уже написал выше, правка сработает только, если ссылка формируется через $this->url->link, так что она ваш хлеб на фиксах кривых модулей не забирает. А заодно эта правка сразу поможет выявить все кривые модули (кривые в контексте формирования ссылок), ибо только они не начнут использовать https. А дальше уж люди могут с полной уверенностью в его необходимости ставить ваш модуль (либо идти ломать руки авторам выявленных модулей)

Это как раз ещё не самое страшное. Встречаются модули, где только поковыряв код можно заставить их использовать https. А в случае, когда не подхватывается HTTPS_SERVER дело не только и, возможно, не столько в модулях, сколько в особенностях самого ОК. По умолчанию предполагается, что сайт на SSL на самом деле его использует только для страниц с конфиденциальной информацией (регистрация, оформление заказа и т.д.), поэтому даже в родных файлах ОК все ссылки на другие страницы формируются без SSL. За тип протокола отвечает третий параметр в $this->url->link, который в большинстве вызовов этого метода не заполнен и потому используется дефолтное значение установленное при объявлении этого метода в /system/library/url.php, а оно false (в 1.5 там было NONSSL, что имело тот же эффект). Поэтому простой и правильный вариант заставить по умолчанию все ссылки, которые формируются через $this->url->link использовать https - это исправить в указанном файле дефолтное значение на true. Но, если в каком-то модуле ссылки формируются не через $this->url->link, а вручную и там без каких-либо проверок намертво вбито HTTP_SERVER, то, конечно, эта правка не поможет и надо таки править конфиг. P.S. Сейчас прибежит Марк и начнёт орать, что менять дефолтное значение в /system/library/url.php - это костыль и единственное правильное решение - купить его модуль.

Редирект всё равно нужен, чтоб в принципе не было возможности попасть на http версию. Например, если кто-то будет вбивать адрес вашего сайта вручную, он точно не будет указывать протокол, а браузер это расценивает, как http.

Вероятно, дело в категории: если в категории текущего товара мало товаров - запросов меньше и наоборот. А запросов там столько, сколько товаров в категории текущего. Это один из ярких примеров, когда автор модуля/шаблона не подозревает, что бывают магазины, где больше пары сотен товаров! И таких полно.

Да, всё в полном порядке.

Если вы хотите проверить сертификат и настройки SSL, то вот: https://www.ssllabs.com/ssltest/

Кому-то заплатить, чтоб разбирался Если для вас это критично.

Вероятно, это и есть последствия правок. Каша там в разных меню. Закрывающие li, ul где попало.

К проблеме это отношение не имеет, но зачем у вас на странице трижды идёт проверка на мобильное устройство? И в вёрстке местами каша (именно каша, а не просто незакрытые теги).

Это уже "экранированные" (на самом деле это называется html сущностями, но в данном контексте можно считать экранированием). Посмотрите ссылки. Ну, и это было слепое предположения на основе имеющейся информации. Амперсанд - самое вероятное при такой ошибке, но кто знает, что там на самом деле. Гадать в слепую тяжело.

Без ссылки на сайтмап можно только нагадать, что у вас там где-то незаэскейпленный амперсанд.

Слэш указывает на директорию. То есть страница отдельного товара/статьи - тут однозначно без слэша. Категория - со слэшем. Контакты - без. Ну и вообще исходите из принципа, что слеш должен быть только там, где страница является условно директорией, то есть, содержит страницы более низкого уровня вложенности (как товары для категории).

Это утверждение от тех, кто не умеет готовить php-fpm. Каждый пул php-fpm может работать от имени отдельного пользователя и группы и более того, слушать на отдельном сокете. То есть, владелец/группа пула могут быть те же, что и у вебдиректории и никаких проблем с правами не будет. Лично я смысл этой связки кроме, как для организации параллельно нескольких версий php на шареде - не понимаю. Потому что Апач тут вообще выступает лишней прослойкой.

Там есть нюанс: https://secure.php.net/manual/en/configuration.file.per-user.php Не обязательно! Конфиг можно перезагрузить без перезагрузки сервиса: systemctl reload nginx.service А ещё перед этим полезно тестировать конфиг: nginx -t

Это плохой пример. Версия 2.0 была мёртворождённой, такое должно было быть стыдно называть релизом, оно даже на бету не сильно тянуло. Разница между 5.4 и 5.6 не такая кардинальная, чтоб её можно было хорошо заметить невооружённым глазом. В рамках пятёрки основной скачёк был между 5.3 и 5.4, а дальше уже достаточно заметный - на семёрку. И это тоже наследие Апача Если вы пишите $request_uri, то регулярка уже не нужна (и даже добавляет лишней работы). Достаточно так: if ($host = 'domain.ru') { return 301 https://www.domain.ru$request_uri; }

Вот такой код - это наследие Апача (образа мышления из его конфигов).: if (!-f $request_filename) { set $rule_3 1$rule_3; } if (!-d $request_filename) { set $rule_3 2$rule_3; } if ($uri !~ ".*.(ico|gif|jpg|jpeg|png|js|css)") { set $rule_3 3$rule_3; } if ($rule_3 = "321") { rewrite ^/([^?]*) /index.php?_route_=$1 last; } Во-первых, доки nginx настоятельно рекомендуют избегать использование if без крайней необходимости, потому что он может приводить к непредсказуемым результатам. А во-вторых, это всё в nginx делается через секции location, которые, по сути, тоже условные операторы с проверкой пути. Чтоб отправить к ОК только запросы, для которых не существует статических файлов или директории, достаточно вместо этого полотнища условий одного блока: location / { try_files $uri $uri/ @opencart; } Почти то же самое, что выше уже выложил @sitecreator , но с одной небольшой правкой - $uri/. Таким образом nginx сначала попытается найти файл ($uri), потом директорию ($uri/) и если ничего не найдёт, передаст запрос дальше в блок @opencart.

Каким местом он под эту конфигурацию заточен? Вопрос не риторический и требует в ответ конкретных примеров! Хотя, уверен, вы отпишетесь пафосными фразами о том, что вы слишком круты, чтоб отвечать на такие вопросы. Кстати, при чём там вообще mysql? Я уже где-то полтора года перевожу магазины на связку nginx+php-fpm и за это время ещё ни разу не сталкивался с проблемами из-за отсутствия Апача, так что не надо выдумывать! Ну, а если у кого-то руки не из того места, то сколько на форуме тем о том, как люди не могут внести элементарные правки в .htaccess. Любопытно, а как вы связываете скорость и количество запросов? Количество запросов влияет прежде всего на количество воркеров, а они в свою очередь на потребление памяти. И таки да, на сотне воркеров Апач не хило её нажрётся, но при чём тут скорость? И потребление памяти - это второй пункт, почему надо использовать именно nginx+php-fpm. На KVM виртуалках память достаточно дорогой ресурс, чтоб транжирить её на Апач. Какая у вас "гениальная" логика: если запросов мало - это костыль, если много - уже не костыль. Это так не работает: костыль - он всегда костыль. Иначе это уже не костыль, а просто не рациональное использование инструментов. Но в использовании php-fpm ничего не рационального нет - это полноценная альтернатива запуску php под Апачем, которую можно использовать в любых случаях, потому что она не несёт каких-либо отрицательных изменений по сравнению с Апачем, а только положительные. Такое впечатление, что у вас бизнес по настройке Апача и вы боитесь его потерять, если все начнут от Апача отказываться. Наверное, лет 10 назад вы бы точно так же призывали не переносить отдачу статики с Апача на nginx (что уже стало стандартом) и с теми же аргументами про количество запросов и костыли.

Единственное, что приходит в голову - это php_admin_flag и php_admin_value. Если где-то через них установлен показ ошибок, то никак это переопределить не получится.

Это стандартный запрос на выборку товара (метод getProduct в /catalog/model/catalog/product.php), так что этих запросов и должно быть много (имею ввиду запрос из этого поста: Но этих запросов не должно быть больше, чем товаров на конкретной странице. Если запросов больше, чем должно быть, ищите места использования getProduct.

Число то смешное, но, как правильно было сказано, большинство разработчиков модулей не подозревают, что в магазинах бывает больше пары сотен товаров. Да и сам Дэниэль об этом не особо думает.

А вы не обратили внимание, что вы отфильтровали не только по категории файлов, но и по автору? То есть, вам показало только языковые пакеты от пользователя опенкарт-раша. И это такие не хамство, а нормальная реакция. Если кто-то стоит спиной к булочной и спрашивает у прохожих, как пройти в булочную - что вы о нём подумаете?

Я немного игрался с этим, но на ОК не испытывал. Могу только сказать, что оно работает и со стороны nginx каких-либо сложностей там нет. Возможно. Можно даже особо не трогать сам ОК, а просто указать nginx список правил запрещающих кеширование: адреса страниц, типы запросов (POST, например, точно лучше не кешировать) и т.д.. Для этого есть директивы fastcgi_cache_bypass и fastcgi_no_cache. Первая говорит nginx игнорировать существующий файл кеша и запрашивать ответ у php, а вторая говорит этот ответ не кешировать. Только условия надо проверять предварительно, а в эти директивы уже передать бинарное значение. Правда, как минимум корзину всё же придётся подправить, чтоб она загружалась аяксом не только при добавлении/удалении товара, но и при обновлении страницы. И то же самое с любым контентом, который может меняться из-за действий пользователя, но является частью страниц, которым кеширование запретить нельзя. Например, тот же модуль просмотренных, он может быть на любой странице, а его контент меняется в процессе переходов пользователя по магазину.