Протокол https для Joomla - страница 3 - Joomla 3.x: Установка, обновление и настройка

отклоняет, потому что у вас по прежнему нет никаких редиректов, http доступен.

закончилось тем, что Яндекс с третьей попытки склеил зеркала. о первой склейке и расклейке я писал. вторая попытка - 10.01 https опять вернулись в индекс, но при этом вебмастер в Переезд сайта начал выдавать Ошибка сервиса, третий раз указал что переезд на https. третья попытка - 22.01 ТИЦ рухнул и до сих пор не восстановился, 23.01 зеркала склеились. надеюсь все

Так а ТИЦ восстановился хоть?

Так а ТИЦ восстановился хоть?

я не знаю что вы настраивали, но сервисы проверки ответа сервера упрямо говоря обратное http://prntscr.com/e3w0va. а должно быть http://prntscr.com/e3w1gm
до сих пор нет

buto, а вы forse_ssl на весь сайт включили?

Сча сделал редирект через сервер

вот теперь все в порядке http://prntscr.com/e3xyvo

Решал недавно проблему с тем, что сайт в админке не включался на https. Google посоветовал вывести $response дабы узнать какой ответ сервера идёт. Однако переменная приходила пустой. По логам выяснил, что оказывается на сайте слетел cURL, установил, проблема с переключением исчезла.
Вам советую разобраться с проблемой, а не использовать костыли с правкой ядра.

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

ндя... 50 секунд это конечно недопустимо... http://prntscr.com/e5id65 никакой поисковик ждать не будет само собой. что то вы там "наоптимизировали"

Вам же ответили, проблема с доступностью сайта, а скорее всего с оптимизацией.
Простой тест на Google пейджспид выдал:
Тайм-аут при получении основного ресурса. Убедитесь, что страница загружается в браузере, и повторите попытку.
Значит надо подумать о кэшировании, проанализировать, что так долго грузит и исправить.
Или подумать о другом хостинге, хотя если по законодательству, то кроме хостера и деваться некуда.

по всей видимости ддосят вас

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

Указанные записи об ошибке сообщают о несоответствии определённого фрагмента кода "строгим стандартам" PHP, при необходимости мы можем отключить логирование таких ошибок.

Причиной замеченного Вами снижения быстродействия сайта был активный парсинг сайта поисковым роботом Mail.ru. Сравните число запросов за последние три дня:
# zcat /var/www/instrumenty/data/logs/instrumenty.by.access.log-20170208.gz | grep Mail.RU_Bot | wc -l
3122
# zcat /var/www/instrumenty/data/logs/instrumenty.by.access.log-20170207.gz | grep Mail.RU_Bot | wc -l
1570
# zcat /var/www/instrumenty/data/logs/instrumenty.by.access.log-20170206.gz | grep Mail.RU_Bot | wc -l
4

При этом только в 4 из 3122 случаев запрашивалась HTML-страница, в остальных был запрошено XML-карта определённого раздела, на Вашем сайте такие запросы обрабатывает отдельный компонент CMS. Пример записи из лога:
217.69.134.109 - - [07/Feb/2017:03:27:49 +0300] "GET /index.php?id=1&option=com_xmap&view=xml HTTP/1.1" 301 196 "-" "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/Fast/2.0; +http://go.mail.ru/help/robots)"

В качестве дополнительной меры по повышению быстродействия установили модуль PHP opcache.

Причиной замеченного Вами снижения быстродействия сайта был активный парсинг сайта поисковым роботом Mail.ru

В качестве дополнительной меры по повышению быстродействия установили модуль PHP opcache.

та те warning не имеют никакого отношения к тормозам. при чем тут 4 warning php и открытие сайта в течении минуты не очень понятно, зачем вы о них вообще спрашивали... карту сайта тоже не понятно как вы хотите запретить доступ. отключите ее, зачем тогда она вам, если к ней Google и Яндекс не будут доступа иметь? сделайте ее статической sitemap.xml и генерируйте 1 раз в сутки по крону, если у вас ее генерация сервер укладывает.

Да сегодня это только возникла такая задержка, вчера было 3.4 с . Сча смотрю логи в сек 3-6 запросов такого плана идет

Спойлер

[свернуть]

даже не знаю что это

я вообще обязан у вас спросить - а чем вам старый хостинг не нравился?

P.S opcache - это круто видать мега модуль для ускорения, кто юзал? =)

та те warning не имеют никакого отношения к тормозам. при чем тут 4 warning php и открытие сайта в течении минуты не очень понятно, зачем вы о них вообще спрашивали... карту сайта тоже не понятно как вы хотите запретить доступ. отключите ее, зачем тогда она вам, если к ней Google и Яндекс не будут доступа иметь? сделайте ее статической sitemap.xml и генерируйте 1 раз в сутки по крону, если у вас ее генерация сервер укладывает.

и что, теперь ждете Google и Яндекс, и опять тормоза? или еще какого нибудь, ботов много...

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

• Переехал на новый хостинг
• Сменил протокол на https через letsencrypt
• Сначала сделал редирект через htaccess при помощи такого кода

RewriteCond %{HTTPS} OFF
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{HTTP_HOST} ^www.instrumenty\.by$ [NC]
RewriteRule ^(.*)$ https://instrumenty.by/$1 [R=301,L]

[/li]

• Сменил протокол на https через letsencrypt
редиректы настроили однако сервер отдавал 200 а не 301. Оставил все без изменений и сделал редирект всего сервера на https 03.02.2017 (примерно тогда как мне показалось и началось торможение