viair

chukcha Спасибо за наводку! Накидал кое что, в результате - язык поменялся только для данных товаров и их опций прикреплённых к заказу, всё, что касается методов доставки и оплаты, а так же тексты VAT Total и пр. остались на языке пользователя заданном в FE. В свою очередь, контроллер checkout игнорирует set('config_language') и как я понял забирает код языка из $this->session->data['language']. Поробовал принудительно задать значение для session->data['language'] для checkout , результат - сменился язык для методов достки и оплаты в шаблоне. Есть возможность запоминать язык FE пользователя во временном поле массива сессии в checkout и там же подменять session->data['language'] на свой, и соответственно отменять его в CheckoutConfirm подменяя ранее запомненным значением из временного поля в массиве сессии. Это работает почти как ожидалось, Но, чувствую, что как-то это всё не совсем правильно. Плюс, есть нюанс, т.к язык подменяется после перехода в Checkout, основной шаблон всё-же остаётся на языке пользователя. Какие варианты предложите? Вот вариант который получился: (Кривой) /controller/checkout/confirm.php class ControllerCheckoutConfirm extends Controller { public function index() { // Получаем дефолтный FE язык магазина $this->load->model('setting/setting'); $store_settings_config = $this->model_setting_setting->getSetting("config", $this->config->get('config_store_id')); // Здесь Нужно нативным методом где то-то добыть id языка по коду, который вернулся в $store_settings_config['config_language'] $this->config->set('config_language_id', 3); // <-- И вставить его здесь вместо значения "3" $this->config->set('config_language', $store_settings_config['config_language']); ...................... $this->session->data['language'] = $this->session->data['user_fe_language']; unset($this->session->data['user_fe_language']); } // END index } // END class /controller/checkout/checkout.php class ControllerCheckoutCheckout extends Controller { public function index() { // Получаем дефолтный язык для FE магазина $this->load->model('setting/setting'); $store_settings_config = $this->model_setting_setting->getSetting("config", $this->config->get('config_store_id')); // Получаем текущий (пользовательский) FE язык $this->session->data['user_fe_language'] = $this->config->get('config_language'); // <-- Запоминаем $this->session->data['language'] = $store_settings_config['config_language']; // <-- Подменяем

Ну, в общем-то так я примерно и предпологал. :) Если я правильно вник, все необходимые манипуляции нужно проводить в checkout/confirm контроллере?Вопрос: где конкретно ему стравить айдишник или код языка? Или нужно ещё с самим Order контроллером танцевать?

А что пишет в логе?

Ребята, Всем привет! Столкнулся со следующей задачей, в мультиязычном сайте при переходе пользователем в "route=checkout/checkout" нужно принудительно задать определённый код языка. Цель: передать в контроллер заказа и соответственно залить в базу все сопутствующие данные по нему(заказу), исключив влияние языка заданного пользователем в FE. Какие варианты предложите?

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

Ух, давно я тут не был :) Озвучиваю причину, которая была в тот раз: Как и предполагал Tom , причина заключалась в имени одного из файлов картинок, в нём присутствовали юникод символы а точнее - знаки долготы. После того, как парсер залил графические файлы в папку ресурсов, OC сразу же подавился. В дополнение: К слову, до этого и несколько раз после, сталкивался с ситуацией, когда из-за не корректного имени одного из графических файлов, не подгружался встроенный файл менеджер Opencart. Так-же, была ситуация, когда файловый менеджер OC выпадал и больше не грузился (возможность залить графику для товара тоже исчезала) после не удачной попытки (через него же) загрузки картинок по причине привышения лимита памяти, на пример так "Fatal error: Out of memory (allocated 46661632) (tried to allocate 3720 bytes)....." собственной библиотекой /system/library/image.php. Решалось так: 1) Увеличение memory_limit = 256M; (Был случай с OC2. меньше не прокатило) 2) Зачистка целевой папки от недописанного (иногда случается) файла. 3) Контрольная зачистка кеша.

Хм, Странно.. Тогда почему у меня получается так, что в таблице order_product к определённым айдишникам заказов привязаны товары у которых записи в поле name явно на разных языках? :( Причём видно, что в каждом заказе наименования товаров чётко на языке фронта, под которым клиент оформил заказ. Вот: Или я чего то не понимаю или они что-то намудрили в движке. Есть же поле product_id, почему не вытаскивать товар по его идентификатору и id языка из таблицы product_description?

Ребята, свем доброго времени суток. Нужна подсказка, в наличии мультиязычный сайт (2 языка) движок OC2. Проблема: Есть единый шаблон накладной, который по стандарту для всех заказов должен быть на едином языке. Но, при формировании инвойса, для каждого отдельного заказа OC подставляет язык который был выбран пользователем при работе в фронте. Что соответственно влияет на на наименования товаров и опциии а так же лэйблы почтовых услуг, ваучеров и пр. Задача: в Order контроллере админки, метод invoice, по возможности нативными средствами OC (без доп. запросов к базе) добыть информацию о продуктах и опциях по id нужного языка. Может есть возможность в индексе явно задать язык с которым необходимо работать? Вопрос: Как реализовать? Заранее благодарю :)

Если вам не сложно, укажите где и как сконфигурировать подачу логов по кешу.

Ребята, спасибо за быстрые ответы ! afwollis, все эти варианты проделал еще до того как задать вопрос, не помогли :) Лог - пуст. Стоило заметить еще такую вещь, у какихто 70+ товаров из 2000+ картинки всетаки есть, после того как сносил кэш, они же заливались движком в /image/cache/data/products по новой. Сейчас смотрю еще одна новость, после инсталяции модуля Latest двиг зкешил еще с десяток картинок к товарам которые выгреб данный модуль. Tom ну да, чтото похоже на 1й или 3й вариант. 2й исключаю т.к "предок" магазина работает на другом хосте и сейчас на нем подобных проблем не наблюдается, плюс все имена прописаны транслитом. да парсинг базы и новых ресурсов происходит 2 раза в день. В конфиге кроме основных 2х config.php в чем еще может быть причина ? По идее если бы в установках была проблема то и с загрузкой в целевую папку и в операциях с базой были бы проблемы так ? Судя по всему кешит только те картинки, что заливаются по новой, а все прежние перенесеные с ядром както игнор..

Ребят всем привет ! Есть следующая ситуация : Был рабочий магазин, на Opencart 1.5.1.3 перенес на новый хост, обновил до Opencart 1.5.4. База подсасывается с другого магазина с помощю скрипта. Описания товаров, опции, пути к файлам ресурсов валидные в базу прописываются корректно. Подкачка самих картинок в целевую папку тоже осуществляется. Проблема такова : Не кэшируются картинки товаров. То есть в целевой каталог /image/data/products ресурсы скриптом загружаются. А вот в/image/cache/data/products они почемуто уже не попадают. В бэкэнде список товаров тоже без картинок. Права к обоим папкам стоят : 755 Вопрос: Куда рыть? Какие причины могут быть ? Заранее спасибо !