NotSlow

Так а что не устраивает собственно? Только язык их сайта или локация их серверов, или поддержка, или скорость/недоступность? Цель смены какая? Чтоб не предлагать шило на мыло менять.

Под одной ОС (не важно какой) может быть весь набор версий php (от 5.2 до 8.2) полноценно работающих И не нужно ради версии php менять версию операционки. Чем вам помочь не представляю, не имея никуда доступа, не видя как все настроено и что там происходит. По-мне так проблема может быть на любом этапе и логи надо смотреть вообще все, вплоть до системных и логов mysql. Причем что-то, где может возникать ошибка может эти самые логи даже и не пытаться писать. Вот этот момент с переходом в корзину, а потом обновлением я бы проделал с ctrl+shift+i в браузере и смотрел ответы в первый и второй заход. Может в первый заход там ответ 304, т.е. на уровне браузера вообще это происходит - он и не пытается загрузить актуальную корзину. А при обновлении он как бы плюет на ответ сервера not modified и всеж перескачивает ее. Если вдруг так и есть, то надо разбираться почему. В корзине все должно работать без кэшей (Cache-Control: no-cache заголовок и т.д.). А если всеж в этот первый заход страница корзины именно с сервера скачивается не такой как надо, тогда дело не в этом. Короче при "глюках" первым делом стоит выключать вообще все кэширование на всех уровнях: cloudlare (если есть), web-сервер (nginx например может), php (opcache), cms сама или ее модули какие-то.

То что вы правите display_errors не мешает скриптам где-то глубже внутри править их еще раз Смотрите логи самого ocstore - в system/storage/logs вроде. Можно попробовать принудить его не править эти настройки. Например в php.ini (или в корневой .htaccess или в тот же index.php) добавить что-то типа: disable_functions=ini_set,error_reporting Т.е. даже если будет попытка где-то их изменить, то закончится лишь warning'ом. Который опять же должен будет отобразиться на странице и в логе. Также скрипты могут без доведения до php-ошибок самостоятельно их перехватывать и как-то обрабатывать. И display_errors не поможет. И вообще ошибка ваша также может быть не на уровне php, а на уровне web-сервера - там свои настройки логирования. Короче надо смотреть.

Вы заходите в админку сюда? https://www.smplunderwear.com/admin/ А если зайти в https://smplunderwear.com/admin/ будет ошибка?

Это javascript ошибка, а не серверная. В логах конечно не будет ничего. Жмите Ctrl+shift+i и дальше в консоли браузера разбираться что происходит и что не так

Ну судя по ошибке выключен curl на хостинге этом. Никак не исправить скорей всего. Может специально, а может просто так все подряд поотключали и могут индивидуально включить. Вы бы в поддержке это и спрашивали, тут кто чем поможет? :-\

Возможно эти warning'и совершенно не связаны с not found проблемой. Они появляются именно если попытаться открыть раздел? Какой-то скрипт пытается обращаться в /tmp, который выше уровнем, чем есть доступ у сайта. Надо или скрипт тот править или убрать open_basedir ограничение. Неизвестно это у вас виртуальный хостинг (хостер ограничил и не убрать) или vps/сервер и можно убрать. Ну и чтоб что-то "исправить", вспоминайте что меняли, после чего такое стало. Возможно развернуть backup будет проще и быстрее.

https://forum.opencart.com/viewtopic.php?f=202&t=200896&start=20#p710221 Советуют просто забить... отключить отображение warning'ов Еще находил ссылку та якобы решение: https://github.com/opencart/opencart/blob/master/upload/system/library/cache/file.php Можно попробовать свой file.php переименовать и закинуть попробовать этот, понаблюдать. "не стабильная работа" - это как? только в предупреждениях этих дело или еще что-то?

Сайт вы для людей делаете? Ну так не прячьте, показывайте. Зачем вам тут 19 а может, а попробуйте, а у меня было так... Лучше лично увидеть форму вашу и что там куда сбрасывается... может ничего и не сбрасывается, а в браузере у вас кэш какой-то засел. Может сбрасывается обратно на https? Тогда запросто может оказаться, что у вас в .htaccess редирект имеется http -> https. Вот вы на http вводите форму, отправляете, вас просто кидает на пустую форму по https Короче надо видеть проблему.

https://www.ipserverone.info/knowledge-base/how-to-solve-gmail-error-password-not-accepted-from-server/ Вот это уже пробовалось? Ну и не знаю надо ли говорить, что лучше слать почту через собственный smtp. Так будет быстрее и все под своим контролем. А почту с локального ящика можно все также проверять на gmail и отправлять от его имени там же.

Нет. Ну почитайте же ошибку... У вас сайт "заперт" в каталоге /var/www/marketkismpw/data А какой-то скрипт зачем-то пытается выйти выше, в корень / Проверить место на диске видимо таким чудным образом. И вот собственно возникает ошибка предупреждение. Очевидно выходов всего два - убрать open_basedir ограничение (но видимо это вам делает панель управления или хостинг). Или поправить ту строчку, например так: $disk_space = disk_free_space("/var/www/marketkismpw/data"); Но кто знает что это за скрипт и может ли он однажды обновиться и снова будет та же проблема.

Когда-то давно, борясь с вирусами, я делал php скрипт, который пробегался по всем папкам и файлам, запоминал размер и дату изменения каждого. Добавлял его в cron и чуть какие были изменения он сообщал что и где поменялось. Дальше по access.log было найдено что из вне были обращения к шеллу, скрытому в глубине обычного нормального файла и после чего происходило заражение еще кучи других файлов... короче все реально при желании. Не знаю деталей вашей ситуации, но как вариант так можно: Зайти по ssh и запустить: find [каталог] -mmin -60 покажет все изменившиеся файлы за последние 60мин или например: find [каталог] -mtime -2 за последние 2 дня Файлов может быть очень много, может быть много мусора из папки cache например, тут уж смотрите сами. Можно добавить в конце >1.txt чтоб не километр текста на экране получить, а записать файл 1.txt и потом уже удобно его изучить. Ну и (опять же, не знаю вашей ситуации) принято для "настройщиков" делать копию сайта на каком-то поддомене, без доступа к основному. И конечно же у вас должны быть на руках бэкапы если вдруг что.

Еще как вариант, попробовать понаблюдать из другого браузера... мало ли. Пока нет гарантированного способа симулировать ошибку, можно только гадать. Говорите при повторном заходе ошибки нет больше. У вас кэширующий модуль стоит какой-то? Возможно что в первый заход возникает проблема, а дальше из кэша отдается что-то другое и повторить невозможно. Отключите тоже попробуйте кэш.

Помимо этого что конкретно уже делали? Смотрели логи как выше советуют? Логи и access и error web-сервера, а также логи самого opencart'а. Если ничего необычного, то открываем access.log и ищем случаи GET /ua/index.php?route=error/not_found И смотрим что запрашивалось сразу перед этим запросом. Может найдется способ точно вызвать проблему. Пока из не очень обычного я вижу к примеру что если запросить несуществующее что-то: https://promtovari.com.ua/uaa То открывает по этому адресу 404 ответ opencart'а, а потом происходит какой-то java-редирект на эту вашу https://promtovari.com.ua/ua/index.php?route=error/not_found Как вариант - где-то запрашивается что-то несуществующее, возможно не сама страница, а на нее что-то подгружается 404'е, в ответ приходит вот тот ява-редирект и всю нормальную страницу перекидывает на route=error/not_found Просто фантазии... надо изучать логи для начала.

Есть ли весомая причина использовать сторонний smtp? Чем плохо завести почту на своем домене, на своем же сервере иметь этот "внешний smtp", который будет отправлять от имени вашего почтового ящика. с ip того же где и сам домен. Так и меньше шансов письму оказаться в спаме и работать будет сильно быстрее. Отвалиться/поломаться какраз больше шансов у какого-то стороннего, а ваш (если нормально настроить и не трогать) должен работать как часы.

Согласен. Если б обратился "в фирму", то там бы 3 шкуры содрали за это... тем более в самый сезон. Может цена и отпугивает, многие также сами вполне справляются. Может без разбора, но просто снять помыть сеточки и пропылесосить вполне. Стоит не на рекламу транжирить бюджет, а окучивать места где водятся потенциальные клиенты - домохозяйки часто очень активны в соцсетях и они сами не смогут это все сделать. Главное запугать вот мол, посмотрите чем вы дышите, нужно срочно звонить и заказывать, пока есть время перед началом жары.

Скажу не как спец, а просто как тот кто недавно чистил оба свои кондиционера... Глянул фото и видео что вы делаете... ну такое :-\ чисто свое мнение. Накинуть чехол, попшикать, просушить, взять 500-1000грн и досвидания? Я разбирал полностью, снимал электронику и мотор чтоб ничего не испортить и чтоб оно чуть позже не пошло ржавчиной и начало свистеть (подшипники например). Выдраил весь пластик очистителем. Между каждым ребром вентилятора вручную все вычистил т.к. то что там накапливается никакая химия/пена просто так не возьмет без механического трения. Ребра испарителя и все оставшееся висеть на стене запшикал пенным автомобильным очистителем кондиционера. Потом все смыл напором воды. Собрал, включил - и да... вот это уже "як новий". Хочешь сделать хорошо - делай сам. Да трудоемко, но результат лучше и дешевле. Потому я б к примеру и не позвонил. Но я бы и по рекламе в гугле ничего не искал конечно и к вам на сайт не попал. Почему не звонят те кто ищут... кто знает. Я б на вашем месте не тратился зря на рекламу, а занимался лучше там где реальные люди/домохозяйки (которые точно сами не осилят, а заказать услугу могут) тусят (а не боты и конкуренты) - всякие районные группы/форумы. А сайт - это просто для презентации, чтоб было что показать заинтересовавшимся и было куда дать ссылку. Но специально покупать на такое траффик - деньги на ветер кажется.

0. Обратиться к поддержке хостинга. 1. Не делать ничего по советам из интернетов. Прежде чем что-то советовать нужно видеть конкретную ситуацию. Зачем прятать сайт? Что по вашему "нормально грузиться"? Ошибка сейчас рисуется... кем, cms, сервером или браузером? Пустая страница или бесконечное ожидание загрузки? Исходя из этого уже нужно смотреть что делать дальше. Открыть консоль разработчика в браузере и посмотреть что именно загрузилось, какие были ответы и т.д. Если всеж на сервере проблема, то смотрим все логи - вэб-сервера, самого опенкарта, mysql (если есть). И на даты смотрим, не древние warning'и какие-то, а смотрим ошибки что прямо сейчас были после вашего захода. Может быть совершенно что угодно. Без доступов тут никто ничего не посоветует, кроме всякой ерунды типа поправить права (с чего б они сами поменялись вдруг?) - см. пункт 0. Один из многих вариантов - у вас скрипты (модуль например какой-то) делает запрос к какому-то стороннему хосту, а тот сейчас "лежит", вот лежит и ваш сайт... Но может быть совершенно другое что-нибудь.

Во-первых рассылку чего и кому? Если спам обыкновенный, то помощи не ждите. Если что-то нормальное по своим клиентам планируется, то: Нужно для начала взять то залетевшее письмо и посмотреть его в оригинале, что там происходит в заголовках. Есть ли какой-то "fail"... может быть что угодно и без опыта врядли разберетесь. Хостеру написать надо было еще до того как писать что-то по форумам Что тут кто вам посоветовать сможет, не видя ничего... даже скриншот замалевали.

А может просто плохая связь между вами и хостом с сайтом. Напрмер вы зачем-то взяли хостинг в США... Но если было нормально, а тут вдруг "начали" как говорите, то может просто vpn какой-нть включен? Очень сильно может влиять на скорость загрузки. Короче надо видеть лично, гадать можно бесконечно.

Если правильно понял, то хостинг работает. Тогда самое простое - прописать на время себе домен этот в hosts файл. Ну и зайти как обычно в админку сайта.

Такие вопросы надо начинать решать с изучения логов. Причем почтового сервера, а не логов сайта или opencart'а. На обычном хостинге доступа к ним скорей всего не будет, потому дорога только в поддержку хостинга. На своем сервере/vps можно, если не разбираетесь - просить кого-то кто разберется.

Да, скорей всего вы шлете например на domain.com POST, а там стоит редирект domain.com -> www.domain.com Достаточно открыть access.log и проследить запрос, что конкретно приходит, какой запрос приходит и что дальше происходит.

Если это не какая-то фоновая cron-задача, а в процессе генерации страницы происходит, то это все равно ужасно медленно.

"Появились"... если раньше не было, то можно как минимум по тем же логам найти момент когда именно они появились. Может вспомните, может менялось что-то тогда. И это мы же предполагаем, что вы как минимум контроллируете состояние сервера. Может там CPU под 100% все время и никто не замечает... конечно будут запросы по 10сек Хотя судя по Rows_examined больше миллиона может и нормально все с нагрузкой, а просто очень много строк нужно было в этом запросе обработать. 1) пройтись по всем тем oc_order таблицам, нормально ли что в них так много записей? зачистить лишний хлам. 2) проверить что там с индексами у используемых в запросе полях.