Dotrox

Затем, что у автора ОпенКарт руки из задницы, потому много чего работает криво и некоторые баги живут годами. Думаете, почему все сидят на различных "сборках", а не на оригинальном ОпенКарте? Правда, авторы некоторых сборок вместо исправления багов просто пихают разные "рюшечки" и порождают ещё больше багов, но это уже другой вопрос.

Найдите у себя в шаблоне /admin/view/template/setting/setting.tpl подобный кусок кода: <textarea name="config_mail_alert_email" rows="5" placeholder="<?php echo $entry_mail_alert_email; ?>" id="input-alert-email" class="form-control"> <?php echo $config_alert_email; ?> </textarea> И проверьте, чтоб в name было config_mail_alert_email. Но исправление шаблона и контроллера setting решают только проблему сохранения дополнительных адресов. А вторая проблема в том, что в моделе order дополнительные адреса вытягиваются из config_alert_email. То есть, нужно либо всё же в setting привести всё к config_alert_email, либо тогда уже в местах отправки почты переделать на config_mail_alert_email. Первый вариант мне кажется более правильным поскольку config_alert_email - это стандартное название.

Может, проще будет просто закрыть магазин, чтоб сократить агонию? 17 ноября вышла 83 версия Firefox, в которой появился HTTPS-Only Mode. При включении этого режима браузер всегда будет пытаться открыть сайт по https независимо от протокола в изначальной ссылке, а в случае неудачи посетители вместо сайта получат сообщение о том, что безопасное соединение недоступно. И далеко не каждый посетитель вообще увидит, что можно временно согласится на небезопасное соединение (да и не каждый захочет соглашаться). То есть, вы собственными руками прогоните часть посетителей. И не нужно быть экстрасенсом, чтоб предсказать, что через пару лет такой режим будет дефолтным во всех браузерах.

И вы думаете, что в тех статьях всё правильно только потому, что они на каких-то заборах сайтах? У вас пагинация сейчас, как и вообще все ссылки на сайте кроме оформления заказа - без https. Вы этого не замечаете из-за редиректа, который в конечном счёте таки приводит вас на адрес с https. Но в процессе происходит кодирование, которое и ломает вам фильтрацию. Отсутствие https означает, что у вас в конфигах не везде https, а должно быть везде, где есть адрес сайта (а то некоторые начинают ещё и константы переименовывать с перепугу).

Если вы хотели вывести адрес склада для основного товара страницы, то вам нужна только первая строка кода. Заполнение в контроллере $data['store_address'] даст вам в шаблоне переменную $store_address. А массив $data['products'] - это рекомендуемые товары.

Вот тут вы сильно ошибаетесь Разработчики изгаляются как могут, в частности привязывают ещё и к содержимому конфига. Вот вам пример как раз про фильтр:

Вероятно, искать надо не в оригинальных файлах, а в кеше модификаторов. $data['store_address'] = html_entity_decode($store_detail['store_address'], ENT_QUOTES, 'UTF-8'); $store_address = $data['store_address']; ... 'store_address' => $store_address, Зачем это переливание туда-сюда? Это код из какого файла?

Могу предположить, что у модуля лицензия завязана на содержимое конфига, которое, конечно же, изменилось при переезде, вот лицензия и отвалилась.

Они, вроде, ИонКуб не использовали никогда. То есть, остаётся просто несовместимость с версией пыха или отсутствие каких-то расширений. Но это должно было бы отражаться ошибками в логе. Это меню ведь отдельным модулем? Вы пробовали его полностью удалить и установить заново?

Привязка лицензии к содержимому файла конфига - это очень плохая практика! Есть множество причин для вноса правок в конфиг и при этом никто даже не подумает, что из-за этих правок может отвалится лицензия какого-то модуля. Большинство разработчиков модулей думают только о собственных интересах. В результате у особо "одарённых" рождаются модули, которые вообще при каждом запросе к витрине проверяют лицензию через сервер разработчика. Сервер разработчика не тянет нагрузку и тормозит все магазины с модулем. А при падении сервера разработчика сразу падают все магазины с его модулями (уже было такое). Я сейчас говорю не о данном модуле, а в целом о ситуации.

Не вижу у вас на втором домене никаких проблем. Всё работает, как и должно. Вы просто забыли туда товары и всё остальное вывести.

В таблице oc_setting изменения есть?

Это не ошибка, а что-то просто логирует сессию. Вспомните после установки какого модуля это началось и попробуйте его отключить (вместе с его модификаторами и обновлением кеша модификаторов).

Во-первых, выложите это текстом, а не скрином. А во-вторых, кто-то у вас там уже ковырялся, кто тоже не сильно много понимает.

Так называется система модификаторов ОпенКарта. Потому что авторы большинства CMS до такого идиотизма не докатились. OCMOD, а перед тем vQmod (который был отдельным расширением) - это система внесение правок в код программным путём. То есть, например, автор какого-либо модуля пишет специальные инструкции (которые и называются модификаторами) и при установке модуля окмод эти инструкции применяет к оригинальным файлам движка, то есть вносит правки в оригинальный код и сохраняет изменённый код в своём кеше, откуда он потом и грузится вместо оригинальных файлов. В народе "модификаторами" часто называют всю систему, а не только "инструкции". Поскольку после модификации вместо оригинальных файлов грузятся модифицированные из кеша, после внесения любых правок нужно каждый раз обновлять (повторно генерировать) кеш "модификаторов" (то есть, кеш окмод). А если вносить правки в закешированные файлы, они затрутся после следующего обновления кеша (а оно понадобится, например, при установке или удалении какого-то модуля).

Смотреть в .htaccess. У вас там, вероятно, в редиректах основной домен захардкоден.

Только через задницу: вносить правки в кеш модификаторов, а после завершения тестирования переносить в оригинальные файлы. Появление окмод таки чуть увеличило время необходимое на внесение правок. Судя по скрину, у вас проблема не в этом файле, а в полном отсутствии стилей. Или даже в отсутствии шапки вместе со всем, что в ней было (в том числе и стилями).

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

Править запросы на лету - это плохая идея! И, как намекает выше Чукча, этот код может отвалиться всего лишь из-за появления лишнего пробела (который запросто может впихнуть какой-нибудь модификатор). Кроме того этот код не решает проблему с кешем: магазины используются в ключах кеширования в моделях, если их оттуда не убрать, кеш будет отдельный для каждого магазина. В случае файлового кеша (а не, например, мемкешед) это помимо общей для любого варианта проблемы с его недостаточной эффективностью добавит ещё и вероятность очень приличных тормозов из-за избытка файлов в кеше, количество которых увеличится пропорционально количеству магазинов. Речь же не только о производительности, но и о необходимости каждый раз при добавлении новой категории/производителя вручную проставлять галочки для всех магазинов. Что будет особенно весёлым занятием учитывая, что там нет возможности проставить одним кликом сразу для всех, например, как в привязке товаров к категориям. И ещё более весёлым занятием будет привязка таким образом всех уже имеющихся на момент создания мультимагазина категорий/производителей.

Это часть виджета чата Cleversite.

@Kingfrelance , а что у вас в таблице category_path?

Учитывая, что нужны правки кода в моделях, единственным адекватным вариантом делать это автоматически я вижу: добавить модификаторами в моделях условия для исключения выборки по магазинам и магазинов в ключах кеширования, проанализировать базу на наличие привязки всех товаров/категорий/производителей ко всем магазинам и, если она обнаружится, записать в базу метку для ранее добавленного условия, чтоб оно начало срабатывать. Но остаётся одна маленькая проблема: То есть, в любом случае сначала нужно сделать привязку ко всем магазинам, чтоб затем модуль сделал отвязку. Получается, что модуль не решает изначальную задачу, а только оптимизирует результат. Было бы логично просто добавить опцию в настройки модуля, чтоб можно было принудительно убрать привязку к магазинам безо всяких условий и анализа. Ну, и это таки должно работать минимум для категорий и производителей помимо товаров. Для инфостраниц тоже не помешает.

У вас в таблицах связей товаров, категорий и производителей с магазинами будет 2 миллиона записей (100 тысяч товаров * 20 магазинов) и запросы с участием этой таблицы будут кешироваться только для отдельного поддомена (то есть, например, при запросе товаров с поддомена 1, а затем с поддомена 2, для второго запроса не будет использоваться кеш созданный при первом запросе). Если товары, категории и производители будут общими для всех поддоменов, то правильное решение - это почистить запросы в моделях от выборки по магазину и поубирать магазины из ключей кеша. При таком варианте все уже добавленные и все добавленные в будущем товары, категории и производители автоматически станут доступны на всех поддоменах, а увеличение нагрузки будет нулевое (даже чуть снизится за счёт отсутствия необходимости выборки по магазину). Но есть нюанс: если какой-либо модуль использует собственные модели вместо стандартных, на него это не подействует. Если у такого модуля модель не закублена, её придётся чистить отдельно, а если закублена - выкинуть модуль.

Из того, как вы описали, можно подумать, что вы в настройках магазина для поддомена забыли протокол на https сменить. Но на самом деле поддомен таки открывается и даже base url правильный. Но вот со ссылками полнейшая каша: где-то правильная ссылка на поддомен с https (например, "Подарочные сертификаты" в верхнем меню), где-то ссылка на основной домен с https (например, меню второго уровня в тех же "Подарочных сертификатах"), а где-то ссылки на основной домен без https (например, "Обувь" в верхнем меню и все подкатегории). Это похоже на проблему с кешем. Сделайте следующее (и именно в таком порядке): 1. Убедитесь, что у вас везде в настройках и конфигах ссылки на домены с https. 2. Убедитесь, что везде, где ссылка на страницу вписывается вручную, ссылка вообще не содержит домен. 3. Очистите все кеши (кроме модификаторов). Если у вашего шаблона есть какой-то собственный дополнительный кеш (помимо стандартного кеша Твиг), очистите и его тоже.

Что делают?