savage4pro

навскидку вижу 3 ошибки 1. в SSLCertificateChainFile цепочку сертификатов указывайте без своего, в случае с LE - только корневой и промежуточный 2. добавьте шифр TLS_RSA_WITH_3DES_EDE_CBC_SHA (вот так, например: ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA) 3. прицепите DH-ключ для поддержки Forward Secrecy, 2048 достаточно и это.. где nginx?

переместил попробуйте так ControllerProductProduct -> review(...) $results = $this->model_catalog_review->getReviewsByProductId($this->request->get['product_id'], ($page - 1) * 5, 5); заменить на $results = $this->model_catalog_review->getReviewsByProductId($this->request->get['product_id'], ($page - 1) * 10, 10);

ИЕ 6 на ХР = все плохо, версии выше - более менее ИЕ 7+ на не ХР = все хорошо

считать вам надо смотреть не только ОС, но и браузер, с 6м ослом все печально как ни крути, можно накостылить, конечно, но очень желательно клиенту в его настройках включить TLS соединения в качестве секьюрных https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=6&platform=XP&key=100 а вот 8й уже ничего так, едва терпимо, но ничего, если веб-сервер обслуживает один сайт на одном IP, сойдет https://www.ssllabs.com/ssltest/viewClient.html?name=IE&version=8&platform=XP&key=101

моя СЕО не понимай почти совсем но насколько понимай, идея внутренней перелинковки по низкочастотным запросам хороша, насчет реализации в модуле ничего не скажу - не видел, не слышал, не трогал

тут может быть несколько причин, какая из них ваша - не знаю 1. старые браузеры не поддерживают SNI, и в основном в связи с древностью данных клиентов эта проблема не является проблемой, поэтому ее никак и не решают а кому критично, для их поддержки заводят отдельные IP для каждого виртуалхоста, или как минимум для того, какой должен быть доступен всем 2. отсутствует поддержка Forward Secrecy, поэтому для корректной работы вероятно придется расширить набор шифров, добавив в том числе и дырявые, также для полноценной поддержки FS веб-сервер должен цеплять ключ для протокола Diffie-Hellman'а 3. ну и еще в браузере может отсутствовать возможность соединения по TLS, а иметься только SSL2/3, а правильно настроенный сервер такие соединения не устанавливает, т.к. опять же несекьюрно, и тут два варианта - А) если таких клиентов вы лично знаете, можно попробовать их уговорить погуглить решение на сайте мелкомягких для поддержки TLS-а; и Б) пожертвовать безопасностью и все-таки разрешать соединения по SSL2 или SSL3 если объединить решения в 1 кучу, можно прийти к выводу, что для страшных динозавров лучше всего будет завести отдельный контейнер со своим веб-сервером на отдельном IP, своими пользователеми, и закрыть его куда-нибудь, чтобы оттуда ничего не вылезло

ну давайте же фантазировать лично я первым делом думаю на фильтр он может при более-менее внятном кол-ве товара с помощью кликов нескольких пользователей загнать БД очередью запросов в ожидании разблокировки myisam таблицы товаров, которая с легкой руки ничего не подозревающего пользователя будет пробовать увеличить счетчик просмотра какого-нибудь товара, и чтобы совершить это действие будет опять же ждать окончания толстого запроса от фильтра, а дальше - больше ну это только одно из предположений, хоть и из опыта, даже самые вкусные фильтры не без греха

отдача контента это дело уже 50-е, там сервер захлебывается

просто оставлю это здесь http://ocshop.info/nebolshoj-dajdzhest-2/

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

да отключите вы его к бесам если кнопок хотите, ставьте от яндекса https://tech.yandex.ru/share/

в идеале все, что не навигация и контент, но полезное, должно быть свернуто где-нибудь в уголках и не шевелиться там, максимум немного вылезать при наведении и только по явному клику/тапу разворачиваться по поводу данных "ярлыков" - в текущем виде они таки будут закрывать полезное пространство, большие экраны "не только лишь у всех", а под эти хрени вряд ли будет выделено пространство в макете, разве что случайно так совпадет

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

<!-- /Yandex.Metrika counter --> <script async=async src="https://w.uptolike.com/widgets/v1/zp.js?pid=1438606" type="text/javascript"></script> </body></html> вот кто этот js пишет в футер, тот и виновник вашей трагедии

ну как бы да, включено?

конечно, а как иначе

клиенту письмо о заказе приходит? если да, то в настройках магазина включено "Уведомление о новом заказе"? если да, то на хостинге данный почтовый домен заведен? если да, то сам почтовый сервер считает домен локальным или удаленным? ищите настройки переключения схемы работы почтового сервера либо в панели хостера, либо в хелпах, при SMTP-отправке это скорей всего не имеет разницы, но в случае отправки функцией php mail действия такие - если не знаете, что себе думает сервер, посмотрите в веб-мейле хостинга для данной учетки, если письмо там, значит "локально" - если не нашли переключатель, пишите хостеру, прикинувшись веником и вкратце объяснив ситуацию - вы хотите обрабатывать доменную почту, отправленную с данного хостинга, на другом сервере - должны помочь или обломать, но однозначность должна быть - если локальным, переключайте - если удаленным, но все равно письма не идут, то пишите хостеру, он обязан помочь разобраться в проблеме

"в дверь стучат, а дома - пусто" (ц) на самом деле не помню, чтобы я ругал статические адреса, в лучшем случае мне все равно, в худшем - я буду в окопе защитников белых ip (* исторические параллели неуместны, кто проведет - получит в репку) не знаю что за модуль, просто окмод да 3 места, чтобы адресок добавился в любом роуте - и в списке, и в форме, и в просмотре

не одобряю ни дыры в безопасности, ни долбаную работу с заказами в админке через api в общем, на свой страх и риск <file path="admin/contoller/sale/order.php"> <operation> <search><![CDATA[ $this->load->model('user/api'); ]]></search> <add position="after"><![CDATA[ $results = $this->model_user_api->getApiIps($this->config->get('config_api_id')); $ip_data = array(); foreach ($results as $result) { $ip_data[] = $result['ip']; } if (!in_array($this->request->server['REMOTE_ADDR'], $ip_data)) { $this->model_user_api->addApiIp($this->config->get('config_api_id'), $this->request->server['REMOTE_ADDR']); } ]]></add> </operation> </file> и все же периодически чисти `oc_api_ip`

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

какое-нибудь поле из этих у вас точно не используется upc varchar(12) ean varchar(14) jan varchar(13) isbn varchar(17) mpn varchar(64)

https://httpd.apache.org/docs/current/programs/htpasswd.html

имя ящика, от имени которого вы собираетесь слать письма, должно совпадать с email администратора учтите это при обработке отправки в controller/inftormationcontact.php, там с каких-то пирогов берется указанный клиентом почтовый адрес в качестве отправителя, вместо адреса администратора магазина, так или иначе, это неправильно и над менять код - ни один гугл в здравом уме не даст отправлять письма ящиков своих аккаунгов с негугловских серверов а также стоит учитывать этот нюанс с ящиками при отправке писем с других магазинов, у которых почта администратора может быть другой, а smtp-авторизация та же

1. создавайте файлы паролей за пределами веб-доступа, тогда не придется писать костыль <Files ...> 2. путь должен быть строго абсолютным, т.е. от корня сервера, посмотрите его, например, в phpinfo 3. для гарантии работоспособности создавайте/меняйте .htpasswd на месте, ну или как минимум, средствами той же версии апача в аналогичной ОС, которыми пользуетесь 4. имена пользователей не должны содержать двоеточие (:)

default в новой папке