Dotrox

Значит для ссылок домен берётся из конфига, а не из $_SERVER. Что у вас в /catalog/controller/startup/startup.php? И проверьте, нет ли его в кеше модификаторов.

Куда б он не стучался, он вам файлы отредактировать не может, если там проблем не показало. Кстати, а в админке у вас проблем с base нет. Я на это нормально реагирую, если не утверждать, что любые другие решения - костыли.

Да, я тоже подумал, что в эти 1-2 недели, когда появилась проблема, как раз и мог быть переход на https.

Это и есть $base. Всё, что в контроллере в виде ключей массива $data - в шаблоне превращается в переменные. Смотрите дальше на $server. И не забывайте про кеш модификаторов. В оригинальных файлах проблем может и не быть.

Здесь ничего не надо менять. Идите в контроллер шапки и смотрите, почему у вас переменная $base передаётся в шаблон пустой.

Раз уж вы это на админке проверили, то тогда и вопросы будут по админке. У вас админка на поддомене работает нормально, не перекидывает на основной домен?

Где вы такой бред услышали? Прежде всего, не может быть 404 то, что 301, а редирект - это 301 (если правильный тип). 404 - это исключительно "страница не найдена"! Если есть риедирект, то в конце концов робот попадает на страницу со статусом 200 и в случае редиректа со статусом 301, запоминает, что теперь у этой страницы новый адрес.

Нет, вообще не приходили где-то пол дня после обновления, потом начали приходить нормально. Если у вас они в спам приходили, возможно, дело в политике каждого отдельного сервиса и в моём случае с Gmail - он их просто отклонял.

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

Первый файл в списке точно заражён, потому что в языковом файле ничего подобного быть не может априори. Остальные два, где php.cmdshell.unclassed - вероятно, тоже. А вот с остальными надо смотреть: base64 там может использоваться просто для кодирования/декодирования данных апи Инстраграм.

На каких почтовых сервисах вы это тестировали? В теории, отдельный почтовый сервис может в качестве средства борьбы с фишингом в случае несовпадения реального адреса отправителя и адреса прописанного во From выводить реальный адрес вместо прописанного.

Это не ошибки, а именно то, ради чего я и просил добавить ту строку! Вы это на поддомене открывали (надо именно на поддомене)? Если на поддомене, то все вопросы к хостеру, потому что у вас тут [HTTP_HOST] => womens-jacket.ru А должен быть поддомен.

После последнего обновления перестали приходить уведомления на почту.

Если вы это ставите на локальную машину, то просто возьмите XAMPP и не мучайтесь. А если это VDS, то начните с удаления винды :)

Аргмуент один - прирост скорости и разница может быть достаточно заметной. А контраргумент - весь гавнокод может посыпаться, ибо много чего про что раньше говорилось "не используйте это - оно устарело", "не делайте так - это неправильно" - в семёрке просто поубирали/поизменяли. Плюс ionCube: на текущий момент актуальная версия 9, где, вроде, есть какая-то поддержка php7, но полноценная поддержка 7.0 и 7.1 будет только в десятой версии, которой пока нет. И неизвестно же, какая версия у вас сейчас на хостинге, а там и девятой может не быть. И это только касательно лоадера, а значение имеет ещё и версия энкодера, которым файлы кодировались. Но на это стоит обращать внимание только, если у вас есть модули под ionCube.

Видимо, да. Вроде, всё правильно: оба домена направлены на одну директорию, в админке второй магазин есть, но ОК не распознаёт второй магазин при заходе по его домену. Ну, как вариант ещё - дело может быть в сервере, который неправильно передаёт или не передаёт текущий хост и потому ОК всегда выдаёт дефолтный магазин. Можете добавить в index.php это: print_r($_SERVER); И посмотреть, что выведется на поддомене.

Что-то не то вы сделали с мультимагазином. У вас абсолютно все ссылки на поддомене ведут на основной домен. Похоже, что вы поддомен на директорию ОК направили, но в админке ОК магазин для этого поддомена не создали и ОК его не обрабатывает. Соответственно, у вас сейчас нет мультимагазина - у вас есть один магазин на двух доменах. Вот так делать вообще нельзя. Там должно быть ЧПУ только текущей страницы, в данном случае - "jacket-rostov".

Мне кажется, если вы не знаете в каком виде у вас ссылки на страницу выводятся, то быстрее будет, если вы просто дадите ссылку на поддомен.

Да. Вообще, такая цена - это как раз без сложностей, потому что ещё дешевле - это уже бесплатно :) А chukcha мастер в SQL, лучше него всё равно никто не сделает (да и дешевле согласятся разве что школьники, которые вам базу завалят :) ).

В данном случае html - это условие поиска, то есть, не трогать точки перед html.

У вас .htaccess общий для всех магазинов, там не может быть вписано доменов. Должно быть так: RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ https://%1/$1 [R=301,L] И "RewriteBase /" должно быть перед редиректами, то есть сразу после "RewriteEngine On". Но вашей текущей проблемы это всё не касается. С выключенным SeoPro проблема осталась? И вы не ответили на это:

Если модуль заказа не пытается использовать https, то проблема не в вашей голове, а в голове автора модуля.

Если в phpinfo GD есть, то библиотека уже подключена. И если мобильная версия работает через мультимагазин (два домена на одной директории), то и настройки php у них общие.

В 2.1 при редактировании этого модуля не передаётся store_id, так что там надо самостоятельно допиливать.

Оно при переходе редиректит или у вас все ссылки на сайте ведут на основной домен? Попробуйте для начала отключить SeoPro. И покажите, что у вас в .htaccess.