Yoda

if (ltrim($this->request->server['REQUEST_URI'], '/') == 'sitemap.xml') { $this->request->get['route'] = 'extension/feed/google_sitemap'; return; } Это по моему лишнее. При наличии реврайта в htaccess.

А вот строчку в htaccess не нужно было комментировать. И в seo_pro неплохо было бы добавить вот такое: if (isset($this->request->get['route']) && $this->request->get['route'] == 'extension/feed/google_sitemap') { return; }

Это у вас какой-то адблок - это не страшно, а вот изображений и правда очень много. И судя по всему стоит ограничение на сервере. Поменяйте хостинг и будет все ок.

Права на папки!

Это вот ща обидно было. Настолько ****го бота, даже я бы не смог написать. И это вы еще не видели его в реальной жизни.. А я видел пару фото. Это нечто!

Где пруфы, вы так много глупостей говорите. У меня есть много пруфов, когда после включения сео-про магазин взлетает в выдаче. А у вас сплошное бла бла бла и байки про каноникал. А ничего страшного, что в движке без сео про может быть пару десятков разных ссылок на один и тот же контент? А ничего страшного, что если у вас 20 000 страниц вы получите 400 000 неуникальных урлов? А ничего страшного, что если бот начнет активно ходить по всем этим ссылкам, пытаясь обнаружить каноникал не хватит никакого краулингового бюджета. Не несите ересь пожалуйста с вашим другом, который пишет ночной код. Или предоставьте не единичные факты с графиками изменения позиций и индексации проектов, где вы внедряете вашу ересь!

1 - включите отображение всех ошибок и посмотрите нет ли их где-то по ходу в html 2 - проверьте включен ли у вас json-php модуль 3 - в контроллере карточки товара сделайте var_dump($product_info['name']); или seo_h1 - посмотрите что у вас приходит из базы. По результатам - отпишите Upd - посмотрите что у вас в поле h1 в базе для этого товара. Если кракозябр нет - где-то в коде движка скорее всего он увас на лету трансфомируется, и скорее всего у вас нэ очэнь руске пыхапэ, и скорее всего где-то есть strtoupper(), который необходимо заменить на mb_strtoupper()

Не работает асинхронная загрузка в случае с opencart - надо использовать rel = preload

Не совсем понял. Но я немного не о том хотел сказать. Так или иначе кроме вагона скриптов тот же мега фильтр генерирует очень много лишних оберток для контента, а объединение его скриптов в один общий - не дают желаемого эффекта. В данном случае если говорить про то как все должно быть в идеале. На фронт должна приходить JSON коллекция, из которой выдергиваться 2-3-5 первых значений параметров, а все остальные подгружаться по кнопке показать еще... 27.ua - пример. И в таком формате необходимо подходить практически ко всему контенту. Все что вторичной надобности отдаем только по пользовательскому событию. Тогда это выходит и в концепции, которую продвигает гугл и действительно быстро. Но в 4500 строк JS кода фильтра, я лезть не готов. Проще написать 300 своих, пусть с ограниченным фукнционалом. Но так как надо.

Расскажите, как вы переверстаете вывод megaFilterPro на скажем так 400-500 значений атрибутов. И при это сохраните метрику аналитикс и facebook внешние скрипты. Именно в том виде, в котором это рекомендовано руководствами по внедрению этих скриптов, а не вот этим всем... "мы сейчас все сохраним локально и поставим время жизни кеша в MAX".

Да я и сам умею, тока не до этого в данный момент.

Насколько мне известно от 2 до 15 тыр берут здешние персонажи. Но из тех кто этим занимается, я бы кроме @spectre ни с кем не связывался по тем или иным причинам.

Ну у вас это известная зараза. Надо закрыть прост все потеницальные пути ее проникновения и подчистить от нее все следы. А также запретить php выполнять небезопасные функции.

Потому что то что вы нашли - это следствие. А источник уязвимости в другом месте!

От того что вы его удалите ничего не изменится. Через какое то время будет тоже самое.

Права на файлы папки фиксим!

https://stackoverflow.com/questions/5539169/how-do-i-remove-extra-spaces-tabs-and-line-feeds-from-a-sentence-and-substitute

public function set($key,$value) { /* $status = $this->cache->set(CACHE_PREFIX . $key, json_encode($value)); if($status){ $this->cache->setTimeout(CACHE_PREFIX . $key, $this->expire); } return $status; */ $this->cache->setEx(CACHE_PREFIX . $key, $this->expire, json_encode($value)); // sets key → value, with 1h TTL. } Как то так лечится ваша беда.

Не занимайтесь извращенным сексом - возьмите сразу сервер с L7

Самое логичное - не использовать непонятные сборки.

Давайте с самого начала. Быстрая работа магазина обусловлена несколькими условиями. 1 - достаточными качественными ресурсами сервера 2 - устраненными бутылочными горлышками а именно: отсутствием медленных запросов, отсутствием большого количества запросов, отсутстивем скриптов которые делают вам авто-ddos сервера, как тото же lightning. 3 - правильной корректной настройкой сервеного окружения, по мелочи по мелочи, но тот же уход от apache и переход на nginx+php-fpm + правильный тюнинг оных дают прирост скорости работы до 400-500мс при загрузке каждой страницы. 4 - существуют масса дополнительных методов и трюков, которые позволяют сделать еще больше и лучше, как то изменение хранилища сессий, которое позволяет держать коризну пользователя и самого пользователя залогиненного на сайте долгое время, изменение храналищие кеша. 5 - поисковые боты должны видеть и обрабатывать только тот контент, который им можно. Даже банальные Гугл Яндекс и Бинг, могут легко уложить любой магазин при присутсвии тяжелых страниц. А при условии выполнения 1 и 2 пунктов позволяют в целом избежать использования каких бы то ни было "разрекламированных модулей кеширования. Что касается использования мдуля этого тетрис 1000 в одном, как показывает практика на каждом втором магазине, который я наблюдаю, он кроме избыточных конфликтов не приносит никакой пользы. Вы можете спокойно пользоваться бесплатным решением от @stickpro - которое делает те же задачи, но не вызывая конфликтов и имеет нулевую стоимость Та же самая история с lightning. Польза от него есть только на закешированных страницах и при отсутствии включеной опции прогревать кеш, так как кроме паразитной нагрузки на систему эффекта от нее ноль. На индексацию и рост позиции в поисковых системах целом ни один ни второй модуль не влияют, так как не делают быстрым магазин "на холодную", и боты все равно видят медленные страницы. Что касается увеличения оценки pageSpeed от Гугл. Кроме ускорения непосредствено время загрузки магазина и приведения в порядок отдачи статического контента, необходимо внимательно посмотреть какие требования еще выставляют гугл, и можно удивиться, ведь там есть вещи, которые опорседовано не связаны со скоростью загрузки. Как то... Объединение скриптов, объединение стилей, которые якобы приводят к уменьшению запросов к серверу и соответсвенно к уменьшению простоя браузера во время ренедера. А также в каких-то моментах может потребоваться как реструктуризация контента так и уменьшение количества выводимых элементов на страницу. Это все хорошо и прекрасно, но зачастую избавиться от 200-300-500 значений атрибутов в фильтре невозможно, в megaFilterPro например, каждое значение размечено 5-6 элементами HTML и только один фильтр превышает рекомендуемый лимит гугла. И с подобными ситуациями бороться какими то модулями можно так же как средством от гемороя лечить гангрену. Также надо не забывать про такие вещи как, совершенно разные способы внедрения дополнительных скриптов стилей на странциы магазина, кризисноть работы внешних виджетов типа различных чатов, колбеков и всего прочего (однажды я видел виджет онлайн чата. который весил более 2мегабайт, тащил на себя свой bootstrpa+ jquery) и на голом чистом магазине который давал 98 баллов pagespeed для мобильной версии, убивал оценку сразу до 15. Так что ни один модуль, ни одни красивые обещания авторов этих модулей, не дадут вам действительно быстрой работающей системы. И это я еще очень кратко, не вдаваясь в вопросы борьбы с паразитными ботами, парсингом, ддосом и вопросами оптимизации ускорения и улучшения качества результатов поиска. А также бывают частные случаи, когда кешировать приходится какие-то вещи, на которые даже подумать невозможно, так на одном проекте, которым занимается уважаемый @nikifalex и не даст соврать, кеширование набора настроек магазина дало прирост скорости в 500-600мс.

до 50 000 товаров до 10 000 хостов в день 2гига 2 ядра ssd и нормальное железо базовое. Кроме оптимизации бд необходимо кешировать повторяющиеся элементы. Необходимо перестроить сервер исключить apache. Необходимо корректно настроить php-fpm.

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

опять полезные советы. По первой ошибке - которая A non-numeric value encountered Вам надо найти что там в этой строке и обернуть в (int) По второй ошибке Undefined variable: og_image_width Надо найти почему у вас не уходят эти знаения в тпл. Почему их нет в контроллере header.

Это к авторам модулей.