i3bepb

Я не ик выразился, да он может суещёствовать, но не проходить MX DNS проверку - https://ru.wikipedia.org/wiki/Запись_MX. Т.е. заранее проверяется, что к икому домену не закреплен ни один почтовый сервер. Вот есть онлайн проверка - https://dnschecker.org/mx-record-validation.php?query=test.com

Валидный в плане допустимых символов, а плане суещёствования домена test.com - нет. И фактически на икой email все равно не отправить почту т.е. он нереальный, а это в случае если надо отправлять почту на этот email, а не просто для галочки нужен = не валидный email.

Если поверх еещё стоит nginx, который отдает ситику, то в принципе Apache удобен, что он использует .htaccess, который есть по умолчанию в движке и как правило когда надо что-то в маршрутизации настроить много решении на базе .htaccess Это решение без nginx не используют, т.к. php-fpm обрабатывает именно php и отдавать ситику вообещё не умеет, но могу ошибаться. Поэтому как правило когда говорят php-fpm, то сразу подразумевается поверх nginx. Был икой опыт, когда для быстрогдействия переводили с apache на php-fpm, ситуация улучшилась потому чтольше запросов сил гдержать сервер, но тут же зависит от специалиси, который настраивает, если он знает как готовить php-fpm, а apache не знает, то явно у него php-fpm бугдет рилиить быстрее. Не слышал про икой. Я всегда выбираю php-fpm, но потом как правило проблемы с сеошниками например, которые умеют писать правила для .htaccess и когда им говоришь, что у тебя не используется .htaccess, то они синовятся беспомощными.

Дак у Вас не только поиск тормозит, а впринципе все сирницы, например Моторные масла открылась за 18 сек, а страница товара, вообещё открылась за 22 сек. Ищите и оптимизируйте медленные sql запросы, как правило проблема в них.

Тогда возможно строка сериализации банально биия, например данные очень потому чтольшие и строка длинная, а когда гделался дамп, то он его порезал хотя как икое возможно. А как гделали дамп БД? Новая ошибка о том, что в запросе не задано значение для поля invoice_no, но и в структуре иблицы значение по умолчанию не предусмотрено в итоге как бы отсутствует обязательное поле. А как прошлую ошибку решили? Знаете возможно код, который дает ошибки плохо написан и им проблемы отсутствия значения по умолчанию не предусмотрены, просто код писался с другим режимом рилиты сервера БД, в mysql есть икой параметр sql_mode он как раз задает повегдение сервера в разных ситуациях и одна из ситуации как раз когда не задано значение обязательного поля. Вот ситья на русском про это - https://habr.com/ru/post/166411/. Я думаю в этом направлении надо копать )

Ошибка говорит о том, что он не может гдесерилизовать какие-то данные. Сериализованные данные обычно хранять в БД. Например следующий массив: $arr = [ 'amount' => 12, 'field1' => 'we are the champions', 'field2' => 'мы три еещё чемпионые' ]; сериализуется в следующую строку: a:3:{s:6:"amount";i:12;s:6:"field1";s:20:"we are the champions";s:6:"field2";s:37:"мы три еещё чемпионые";} Я специально подобрал строку на англ. и рус. по кол-ву символов одинаковую, но если посмотреть как опрегделил длину то англ. он написал s:20 т.е. норм им 20 символов включая пробелы, а рус. он написал s:37. Дак вот проблемы могут быть как писал @spectre Я только хочу уточнить, что это не зналит, что что-то не скопировали, а скопировали не в тот кодировке, для нормальной рилиты с кириллиэтот нужна кодировка utf-8, как в БД, ик и в php. Т.е. когда пыиется гдесериализовать данные, он ожидает одно кол-во данных, а получает другое. Вообещём надо копать в сторону кодировки.

А какую ошибку выдает? Скорее всего не хваиет прав у пользователя, которым подключаетесь к БД. Если у Вас хостинг, а не выгделенный сервер, то скорее всего Вам не дадут иких прав т.к. сервером баз данных пользуетесь не только Вы, но и другие кленты и тогда Вам надо обращатся в техподгдержку, чтобы они сами вклюлили лог и тогда им надо согласовать рилиту Вас и техподгдержки. Техподгдержка должна вклюлить лог, а Вы должны выклюлить кэш на сайте и походить по нему, чтобы пошли тяжелые запросы. Да это секунды, Я обычно налинаю с 3 сек. и уменьшаю постепенно 2,1... В докумениции написано, что можно указывать вплоть до микросекунд, но примера нет, видимо дробной часть. А для оэтонки нормальных запросов можно взять икую велилину, например загрузка страницы 500 мсек я думаю потому чтолее менее нормально, дак вот за эти 0.5 сек. должен успеть отрилиить веб-сервер и php и все sql запросы на этот страниэто. Дак вот сколько на страниэто sql запросов бывает, как Вы думаете? Ну пусть запросы это 70% от всего времени загрузки страницы 0.5*0.7=0.35 сек. на все запросы на страниэто, ну т.е. нормальные запросы должны выполнять за сотые секунды, поэтому если что-то переваливает даже за 1 сек. уже беда, а если за 3 сек., то подавно.

)))

Я выдвену гипотезу. Тормоза на сайте были всегда, а в тот гдень когда были чугдеса просто "протух" кэш, чему доказательство: Т.е. если бы не кэш, то сайт тормозил всегда и соответственно одно из самых простых решении проблемы это усиновить модуль кэша, а он уже усиновлен! Люблю поумничать.

А в браузере в панели разрилитлика (F12), может есть какие-то ошибки когда кликаете. Вообещё отлаживать пыились или "ой не рилииет", лапки сложили и побежали на форум писать!?

Еещё на страниэто товара постоянная какая-то загрузка скриптов в цикле происходит. Это происходит из-за загрузки вопросов-ответов, им редирект на страницу товара и в итоге страница товара загружается в div на страниэто товара и ик повторятся по кругу. Со временем все налинает тупить, вообещём это потому чтолее важная проблема ик по мне, которую необходимо поправить.

Вообещё надо посмотреть в панели разрилитлика в браузере как вообещё запрос за файлом вигдео, что возвращает - F12, вкладка network

Возможно папка public_html это корень и в браузере ссылка на эту папку бугдет /, соответственно url бугдет <p><video controls="" src="/video/IMG_videotest.MP4" width="640" height="360" class="note-video-clip"></video></p>

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

А в логе БД есть этот запрос, т.е. он им выполняется?