Yoda

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

Насколько мне известно от 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.

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

Поменяйте select на автокомлит и будет вам счастье. Судя по всему у вас не скрипт магазина тормозит, а непосредственно рендеринг выпадающего списка в браузере.

mytop ваше все! Так как неизвестно какие кривые руки писали профайлер. И на каком уровне он обрабатывает запросы. Также смотрите в код - если у вас где то на товары перебираются из php-массива принадлежность к категориям - то это даже 20 x 10 000 итераций. Что может убивать производительность на уровне самого php.

И мне расскажите, какие данные и как их юзать? Как это повлияет на индексы в базу, количество сессий, наплыв ботов, производительность сервера?

Это вы сейчас серьезно? 21 век на дворе.Илон Маск. Оптимизация таблиц - это оптимизация таблиц - ваш кеп! Человек спрашивает как оптимизировать базу. А вы ему phpmyadmin скрины. Ну это полный факап. Для топик стартера: Почитайте это: https://habr.com/ru/company/oleg-bunin/blog/309328/ и это: https://habr.com/ru/post/20246/

Глупый соввет - не SERVER_NAME - а HTTP_HOST Так как SERVER_NAME - это немного не то! По факту. Делаете вот такой файл robots <?php $https = 'http'; if ((isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == '1' || $_SERVER['HTTPS'])) || (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && (strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https') || (!empty($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] == 'on'))) { $https = 'https'; } $server = $_SERVER['HTTP_HOST']; $host = $https . '://' . $server; $text = " User-agent: * Disallow: /*route=account/ Disallow: /*route=affiliate/ Disallow: /*route=checkout/ Disallow: /*route=product/search Disallow: /index.php?route=product/product*&manufacturer_id= Disallow: /admin Disallow: /catalog Disallow: /download Disallow: /system Disallow: /*?sort= Disallow: /*&sort= Disallow: /*?order= Disallow: /*&order= Disallow: /*&limit= Disallow: /*?filter_name= Disallow: /*&filter_name= Disallow: /*?filter_sub_category= Disallow: /*&filter_sub_category= Disallow: /*?filter_description= Disallow: /*&filter_description= Disallow: /*?tracking= Disallow: /*&tracking= Disallow: /*?mfp= Disallow: /*&mfp= Clean-param: tracking Sitemap: $host/sitemap.xml "; header("Content-Type: text/plain"); echo $text; exit; ?> Сохраняете это как robots.php в корень. В htacess прописываете RewriteCond %{REQUEST_URI} !robots\.txt RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] Радуетесь! И не слушайте советчиков, которые рассказывают про то что руками сайтмапы. На 50-100 поддоменов пусть сам сайтмапы руками в вебмастере регистируют.

Это не оксторе - это admin/admin либо дырявые модули шаблоны. Смотрите еще в модификаторы модификатор ocstore в списке. А так же /admin/controller/design/image.php и /catalog/controller/affiliate/image.php. Также запустите айболит. Также там могут валяться файлы вида seo.php. Также может лежать в папке tool/Image imgwm.php.

Кроме времени жизни сессии - необходимо не забывать про session.cookie_lifetime. Подробнее тут: https://www.php.net/manual/ru/session.configuration.php Практически никто не учитывает факт того, что пользовтель может закрыть браузер!

Если мы говорим про jpg png - то они остаются старыми. Если мы говорим про webp- у них просто странные. Но ПОДЧЕРКИВАЮ персистентные урлы. И то что сюда мракобесы в комментарии набежали и рассказывают про проблемы с дальнейшей индексацией - то фейл!

Если не сложно покажите в личку. А лучше в телеграм стукнитесь. Это совершенно не так, так было давно на четвертой версии. В пятой учтено очень много косяков, по удобству управления сервером и простоте использвоания - мало чем отличается от обычного хостинга. Сейчас предостаточно хостингов с нормальным саппортом - пример @rassigor с firstvds и настройкой modpagespeed за считаные минуты - меня очень приятно удивил. Также опять же возвращаесь к его опыту, я знаю какое количество нестандартных вопросов ему закрыли. У меня совершенно другая информация. И достаточно большой кейс негативных инцидентов связанных как с непосредственно этим человеком, так и с последствиями его работы. Если интересно - могу лично рассказать. А то сейчас начнется холивар. Вы серьезно так думаете? Это хлеб что ли.. 2000 за две строчки кода? И предложение решений у которых есть более простые, зачастую бесплатные и качественные альтернативы? Мне всегда казалось, что нельзя обижать маленьких, воровать у бабушек. А в итоге что получается... Наработали себе авторитет. Наделали каких-то непонятных реализаций и пошло бабло. При этом информаия о любой альтернативе, воспринимается как попытка залезть в карман. унизить и так далее. Не буду давать оценку этим действиями. Я думаю что здравые люди все итак понимают. Но даже если взять данный прецедент - посмотрите суть. В силу того что восприятие программистов у меня идет через призму владельца магазина, а не как коллег, и в силу того что в свое время был очень богатый опыт взаимодействия с очень многими "авторитетными" персонажами и отсюда и с фриланса, у меня есть скромное понимание, как это все работает и как делать, чтобы работало хорошо. Я четко обозначил ситуацию. Вместо настройки версии php - нужен просто нормальных хостинг с нормальной панелью. Все.. Не нужно никому платить никаких денег за настройки корявого сервера. В конченом итоге сервер без панели - это наркоманская игла. Ты оказываешься привязан к занятым-деловым сисдаминам и зажат в рамки и сидишь у них в зависимости. Как бы там ни было - такая ситуация вредна для бизнеса. Переезды-заезды настройка - это все в наше время делают хостеры. Просто это все уже давно в пакетах у нормальных контор. И что в итоге.. Смотрите. Я указал решение проблемы. А в ответ ведро грязи. И если кто-то думает, что продавать модуль для robots.txt, вставлять специально дыры в код, или для вставки кода JivoSite, рассказывая потом сказки про мифический "ночной код", или одну строчку jpegoptim.... bla bla - это хорошо? То просто я так не думаю. И самое главное даже в этой ситуации... Вот вам лишний раз подтверждение Не кажется как то неудобно вышло?

А вы сможете сделать так, чтобы sphinx искал iphone7 и iphone 7 как одинаковые вхождения. И ещё... А что вы такого делаете за пять тысяч, чего не может бесплатно isp manager? Опять хотите на неведении заработать?