Dotrox

Нет, проблема в тех файлах, которые на скрине выделены красным. Проверьте. есть ли они у вас и какие у них права. И jQuery, судя по первым ошибкам, у вас тоже не загрузился. Попробуйте на всю директорию catalog рекурсивно поставить права 755.

Откройте в инструментах разработчика в браузере сетевую вкладку, обновите страницу и сделайте скрин сетевой вкладки. У вас, кстати, сайт на https?

Откройте консоль браузера и сделайте скрин вместе с ней. И загляните в журнал ошибок. У вас в json ответе, вероятно. выводиться какая-то ошибка php.

Ничего, как и сама версия нас не ждёт. Следующей версией будет тройка. А что нас там ждёт можно посмотреть в соответствующей ветке на Гитхабе. Там, кстати, уже первая альфа. Вы отстали от жизни - это уже в 2.2 есть.

Это уже результат. Но процесс прихода к этому результату был довольно хаотичным. Когда зарелизился 2.0 у меня вообще было ощущение, что на ОК можно ставить крест. Вот так и начинаются "фреймворки"

Как раз наоборот - не работал на HTTP/2 судя из этой фразы. Хром почти год назад удалил поддержку NPN (расширение для выбора протокола), а точнее заменил на ALPN. nginx для работы с ALPN должен быть собран с OpenSSL версии не ниже 1.0.2, а он до сих пор в официальных репозиториях собирается с версией 1.0.1. Мозилла NPN тоже заменила на ALPN, но позже. И эта касается всех вариантов этих браузеров, а не только мобильных. Так что получается, что без HTTP/2 в Хроме у вас просто за один раз все фотографии не могли загрузиться (а у некоторых есть сомнения в пользе от HTTP/2). Но вопрос, почему проблема возникла только после перехода на https, ведь без SSL HTTP/2 не работает, то есть проблема должна была быть всегда. Или вы просто до перехода на https на мобильных не проверяли? Ну да, всё верно: как это происходит, в принципе, с кешированием в ОК - SeoPro кеширует только результат запроса к таблице с ЧПУ.

Вы не одиноки. А секрет в том, что ничем не руководствуются, а просто экспериментируют. Вся вторая ветка - это сплошной эксперимент, результатом которого станет третья версия. Некоторые разработчики делают свои "фреймворки" максимально абстрагируясь от ОК. В нормальных условиях я бы сказал, что это однозначно плохая идея, но в случае ОК с его стабильностью (её отсутствием) всё не так однозначно.

Ну, я могу предположить только два варианта: либо есть ещё один блок location для статики и там кеширования нет, либо вообще весь этот server блок не работает.

Чтоб применить изменения из этого конфига, надо делать рестарт nginx, релоад работает только для конфигов, которые он инклюдит. Только перед рестартом сделайте nginx -t чтоб убедиться, что нигде нет ошибок.

Не ноль, а прекрасный эффект... на локалхосте Это нужно писать не в какой попало конфиг, а в конфиг конкретно вашего сайта - это первое. А второе: proxy_cache и все директивы с этого начинающиеся не имеют отношения к кешированию статики в браузере - это кеш для бекенда, то есть, чтоб nginx получив от бекенда (ОК через Апач в вашем случае) ответ, сохранил его в файл и при следующем таком же запросе уже не обращался к бекенду, а выдернул ответ из кеша. Для кеширования статики достаточно этого блока: location ~* \.(?:jpg|jpeg|gif|png|ico|css|pdf|ppt|txt|bmp|rtf|js|min) { expires 1M; add_header Cache-Control public; root /var/www/andrzej/; } И очень внимательно посмотрите на букву м! Потому что 1m - это 1 минута, а не 1 месяц.

Вы хотите, чтоб я сам вам таблицы почистил?

Эти все ошибки не имеют отношение к проблеме с зависанием. Они из-за того, что у вас модификаторы от шаблона не применились. А зависание из-за того бреда с категориями, который на скрине. Нельзя, конечно, исключать, что и это из-за какого-то модификатора, который не полностью сработал, но более вероятно, что из-за нехватки памяти у вас где-то что-то перепуталось при записи в базу и теперь получается такая каша. Советую просто зайти в базу через phpMyAdmin и вычистить всё из таблиц, которые начинаются с category. Удаление категорий через админку может не решить проблему.

Ну, в таком виде это действительно костыль. Но направление правильное. Если у вас структура тайтла общая для всех городов и нужно только название города подставить, сделайте шаблон в языковом файле и в контроллере через sprintf просто подставляйте туда название товара, город и цену. С названием товара и ценой всё уже ясно, а для города добавьте в админке в настройках магазина дополнительное поле и тогда к нему можно будет получить доступ через $this->config->get(), при чём там всегда автоматически будет значение для текущего магазина.

Если с этим всем точно порядок, тогда думайте какие модули связанные с изображениями ставили. Потому что, если с правами и файлами проблем нет, значит у вас код испорчен.

Такое время не может быть в пределах нормы, в принципе, а тем более, на таких запросах! В этих запросах проблема, скорее всего, в ORDER BY RAND() Очередной пример, когда автор модуля не подозревает, что в магазинах бывает товаров больше, чем в демо. Ну, а в следующих двух запросах должен помочь полнотекстовый индекс на текстовых полях участвующих в запросе.

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

Судя по тому, как долго крутится загрузка главной страницы перед 502, теперь проблема в max_execution_time. Хотя, это не проблема, а симптом, а реальная проблема в причине, по которой время работы так кардинально увеличилось. Вы не могли заполняя категории некоторые перекрёстно назначить родительскими друг для друга?

Они предлагают какой-то непонятный хлам из набора слов. Если есть лишние деньги - купите Адвордс/Директ, а ещё лучше таргет в ВК/ФБ.

Ну, тут вариантов не много: или на подкаталоги и файлы всё же не сделали, или не те права поставили, или у вас просто нет тех файлов изображений, которые ОК ищет.

Циклический редирект?

Вы их рекурсивно ставили?

Ну, та же история - права на директорию image.

Я думаю, вот ответ на ваш вопрос:

Поэтому надо нас пожалеть и дать конфетку в виде бонуса к ранжированию Если кто-то сидит на гавнохостере - это уже его личная проблема. Интернет-магазин - это инструмент для заработка денег, так что можно не поскупиться и добавить пару баксов в месяц на нормальный хостинг. Я, например, всех клиентов при первой же возможности (как только дозреют) перевожу на VDS во Франкфурт. При чём, это выходит даже не дороже местных шаредов: тарифа за $5 с головой хватает на 10к товаров и тысячу посетителей. А вдобавок, Гугл сейчас уже сам хостер, так что давать поблажки за кривых конкурентов было бы глупо с его стороны.

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