Yoda

Просто добавьте в роботс Disallow: /*mfp Бот пытается пройти по всем вариантам комбинаций фильтра. Мало того что вы дубли страниц плодите, еще и сервер подгружаете.

Это вот бесплатно и работает.

Метрика и jivo и так грузятся асинхронно Тут похоже вывод через google tag manager

SPF DKIM DMARK

а что у вас там в innodb_flush_log_at_trx_commit ?

Регулярно сталкиваюсь - это у вас все плохо! Где-то на стороне хостера блокируется бот или айпи. Бежать! Менять! Оптимизировать!

все зависит не только от диска. Если к примеру взять очень большую таблицу, и внее делать insert и это mysql а не mariadb и таблицы innodb, то пересчет индекса - это напрямую мощность процессора, который зарезан на vps, а никак не скорость дисковой подсистемы. Это раз. Два чем больше памяти может пользовать база - тем ей легче. А еще, судя по всему, если вы говорите про mysql8, она у вас задеплоена через докер из ISP панели, и есть большая проблема с базами которые работют в докере, у них реально очень большой лаг с производительностью, используйте родную базу и будет все хорошо.

все зависит не только от диска. Если к примеру взять очень большую таблицу, и внее делать insert и это mysql а не mariadb и таблицы innodb, то пересчет индекса - это напрямую мощность процессора, который зарезан на vps, а никак не скорость дисковой подсистемы. Это раз. Два чем больше памяти может пользовать база - тем ей легче.

Ну кроме того, что гугл в принципе не индексирует ваш сайт.

Как это поможет с проблемами mysql в 5.6+ ? Чушь а не модуль Если это 1.5.5 - не заработает он там кривой и его надо забирать с более свежей версии типа 1.5.6 вместе с драйверами и общим классом базы.

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

Это не поможет библиотека GD пересохраняет плохо - вам необходимо внедрить imagick

Если у вас будет скомпроментирована файловая система, получить доступ в базу - это как два пальца об асфальт.

https://github.com/marcbelmont/cnn-watermark-removal

А где их еще хранить ?

Сессии являются простым способом хранения информации для отдельных пользователей с уникальным идентификатором сессии. Это может использоваться для сохранения состояния между запросами страниц. Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для получения имеющихся данных сессии. Отсутствие идентификатора сессии или сессионного cookie сообщает PHP о том, что необходимо создать новую сессию и сгенерировать новый идентификатор сессии. Сессии используют простую технологию. Когда сессия создана, PHP будет либо получать существующую сессию, используя переданный идентификатор (обычно из сессионного cookie) или, если ничего не передавалось, будет создана новая сессия. PHP заполнит суперглобальную переменную $_SESSION сессионной информацией после того, как будет запущена сессия. Когда PHP завершает работу, он автоматически сериализует содержимое суперглобальной переменной $_SESSION и отправит для сохранения, используя сессионный обработчик для записи сессии. По умолчанию PHP использует внутренний обработчик files для сохранения сессий, который установлен в INI-переменной session.save_handler. Этот обработчик сохраняет данные на сервере в директории, указанной в конфигурационной директиве session.save_path. Сессии могут запускаться вручную с помощью функции session_start(). Если директива session.auto_start установлена в 1, сессия автоматически запустится, в начале запроса. Сессия обычно завершает свою работу, когда PHP заканчивает исполнять скрипт, но может быть завершена и вручную с помощью функции session_write_close().

Оптимизировать магазин, начиная от базы, заканчивая конфигом nginx.

Скажите, а зачем вы эту дичь вашу сюда занесли?

Дружище, у меня в кейсе порядка 500-600 очень быстрых проектов, среди которых магазины с несколькими миллионами товаров и посещаемостью в полсотни тысяч уникальных посетителей в день. Так вот.Я тебе обстоятельно заявляю Gtmetrix - никакого отношения не имеет к гуглу. И к Яндексу. Это исключительно приблуда, которой сеошники-аферисты раззодят клиентов. Так что с такими советами. ДАЖЕ НЕ ДУМАЙ СПОРИТЬ С УВАЖАЕМЫМИ ЛЮДЬМИ! Иди сходи на профильные форумы, на коворки фрилансы, и там разводи кроликов. А если хочешь со мной поспорить, вступить в дискуссию, покажи проект к которому ты имел дело и там есть хотя бы 10к хостов в день, потом может и поговорим! А то развелось нищебродов-специалистов с кейсами ниже плинтуса. И да ЧСВ - это мое все.

Вы не постные тексты пишите - а реально расскажите, что за качеством следит дирекция! И ни один кейс не проходит мимо контроля(ну по крайней мере у меня так с вами, за что и ценю)! Это намного важнее "щедрых акций". Нормальному интернет-магазину рупь-туда рупь-сюда в месяц погоды не делают. Намного важнее кроме быстрых серверов и пингов. а) стабильность б) время реакции и качество саппорта!

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

Я с вас со всех худею дорогая редакция. Откуда столько глупостей в голове? 1. Если падает сервер и не срабатывает sheduled task - надо просто менять сервер. 2. Любые хранимые процедуры, триггеры и таски в базе - в конечном итоге оборачиваются некой головной болью при смене окружения, особенно если используется shared хостинг. 3. Нет принципиальной разницы это cron скрипт php, cron команда mysql или bash скрипт. Это все серверные пережитки и они все обладают одним большим недостатком - при смене окружения, паролей в базу, пользователя базы, про них можно случайно забыть. 4. Если делать совсем дубово в рамках идеи opencart - надо делать какой то шедаллер в виде событий при инициализации генераций страниц с файлом или записью базы содержащими временную метку последнго успешного события. Если вы уверены в своих силах и втом, что вы не забудете перенести кроны - крон. Если знаете как решить потенциальные проблемы с пользователем, от которого работюат триггеры и процедуры - делайте в базе. В том или ином виде задача решается однозначно и малыми костами. Просто кому то удобно за 10 минут скрипт сваять, а кому то в базу пару запросов воткнуть. Единого верного решения здесь быть не может. Следуйте принципу write less do more и будет вам счастье!

UPDATE table SET table.field = table.field + 3 не годится? Ну и если правильно погуглить то видим по заросу cron mysql query Первая же ссылка на стаковерфлоу и очень простое решение задачи personally find it easier use MySQL event scheduler than cron. Enable it with SET GLOBAL event_scheduler = ON; and create an event like this: CREATE EVENT name_of_event ON SCHEDULE EVERY 1 DAY STARTS '2014-01-18 00:00:00' DO DELETE FROM tbl_message WHERE DATEDIFF( NOW( ) , timestamp ) >=7; and that's it.

школоло лайнэдж детектед. Лучший гарант - репутация. Когда при вопросе о предоплате, нет аргументов. В репу школавеб текст кидало = школавеб не получит заказов!

А толку от него. sql запросы ограничены, просто взять и взять пихнуть в индекс базу не выйдет. Конфликтов с любым дополнением не оберешься. Любой фильтр в целом на категории до 5к товаров настраивается и с mysql базой. Как и любой магазин до 200-300к. Менять архитектуру хранилища, жертвуя совместимостью имеет смысл только в очень специфических случаях, когда вы будете уверены, что в любой момент сможете помочь клиенту со сторонними расширенями. Проблемы с индексацией начинаются где-то с 100к товаров, и зачастую их решение - это какие то не то что костыли а КОСТЫЛЮГИ! Чтобы подружить любой фильтр - надо как минимум написать самому фильтр. Поэтому там где не надо 50к товаров в одной категории, разворачивать сфинкс под каталог - это просто садить на иглу потенциального заказчика. Намного утилитарней, проще и эффективнее, сделать сводные таблицы (исключив лишние джоины) и расставить правильный порядок таблиц в запросе, как в фильтре у маэстро @SooR, так как в итоге это решение, в котором может разобраться любой разработчик.