Yesvik

Если речь про количество товаров в списке категории - смотри строки с 282 по 312 http://www.assembla....ory.php?rev=397 (для удобства включи нумерацию строк) Для себя я делал эти значения кратными количеству заданному в админке.... Так логичнее, кода меньше, править проще и ссылка на страницу с дефолтным количеством строится без параметра limit ... Вместо строк с 282 по 312 у меня так: $default_limit = (int)$this->config->get('config_catalog_limit'); $factors = array(1,2,3,5,8); $this->data['limits'] = array(); foreach ($factors as $factor) { $default_limit_factor = $default_limit * $factor; $this->data['limits'][] = array( 'text' => $default_limit_factor, 'value' => $default_limit_factor, 'href' => $this->url->link('product/category', 'path=' . $this->request->get['path'] . $url . (($default_limit_factor != $default_limit) ? '&limit=' . $default_limit_factor : '')) ); } В массиве $factors задаётся нужное количество коэффициентов...В итоге если в админке указать количество товаров на странице равное 12 и массив $factors содержит коэффициенты (1,2,3,5,8) получим 12, 24, 36, 60, 96 Аналогично сделал и в списке товаров по производителю, в поиске и в списке спецпредложений...

Возможно знают телепаты...

У тебя manufacturer_id не в $_POST а в $_GET...Если модуль написан не ногами - то вот так $this->request->get['manufacturer_id'] ты получиш manufacturer_id.

Доступ к закрытому разделу форума в котором обсуждаются вопросы связанные с развитием ocStore.

Вот как это сделано в 0.2.2 http://www.assembla.com/code/ocstoreru/subversion/changesets/82 Да

С точки зрения синтаксиса оба варианта правильные.

1. в данном случае это не ошибка... и даже существуют рекомендации запрещающие использование закрывающего тега ?> http://framework.zen...formatting.html 2. в стилях исправил font на font-family http://www.assembla..../changesets/379 3. добавил открывающий тег <tr> http://www.assembla..../changesets/377 В переводах исправил опечатку http://www.assembla..../changesets/378 Спасибо...

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

Проблема возникает только когда не задан префикс таблиц.Так проблем не должно быть http://www.assembla..../changesets/376 upgrade.zip

Не хочется что-бы ocStore сильно отличался от OpenCart...В ocStore включаются решения проблем локального характера с которыми разработчики OpenCart'а точно не будут заморачиваться. Эту проблему решают официальные разработчики, так что будем ждать решения от них... если не решат - тогда включим это решение.

Собрать статистику по каким страницам идёт трафик и построить редиректы вручную.

Можно

Нет.

Какой смысл ставить 1.5.1.3 если есть 1.5.2.1? Если думаете что seo_pro будет редиректить ссылки от xt:commerce - то это не так...

Ищи что такое UTF-8 BOM

У админки свой конфиг...

В ошибке написано обратное и я верю этому сообщению больше чем Вам.

https://opencartforum.com/files/file/162-%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D1%8C-html-%D0%B4%D0%BB%D1%8F/

В файлах config.php надо указать правильный логин и пароль к базе

На 3 сообщения ниже цитируемого - всё подробно написано

Вот такой вариант не будет обламываться на битых изображениях и не будет изводить сервак кучей запросов... + "ленивая" загрузка изображений сделает количество запросов ещё меньше чем в 1.5.1.3filemanager.zip

Не всё так просто как мне показалось... весь сыр-бор пошёл из-за битых изображений. В 1.5.1.3 скрипт упирался в битое изображение и не обрабатывал следующие... поэтому сделали отдельную обработку каждого изображения и в итоге получили удвоение количества HTTP запросов. Что-бы как-то снизить нагрузку - дописали "ленивую" загрузку изображений, но если тебе нужно изображение в конце списка и ты быстро прокручиваеш изображения в низ - могут возникать те-же проблемы... попробуй взять из репозитория последнюю версию и поэкспериментировать.

Проблемы в filemanager нет...Во первых POST запросов там нет, там GET запросы... Во вторых - сделана попытка решить проблему одних серваков и создана проблема для других. На всех не угодиш... В 1.5.1.3 проверка наличия и генерация миниатюр выполнялась в одном запросе... в итоге находились сервера с тормозной ФС и скрипт обламывался по времени исполнения... что-бы избежать эту проблему - обработку каждого изображения вынесли в отдельный запрос и теперь нашлись серваки которые обламываются по количеству запросов. Как по мне - алгоритм работы filemanager'а в 1.5.1.3 более правильный и ложил я на проблемы рахитских серверов. Думаю разработчики это быстро поймут и будет откат к старой версии.

В 990-ой ревизии filemanager не правили...Дай ссылку на обсуждение проблемы

Точно... при отсутствия префикса у таблиц может возникнуть ошибка.Я когда тестил без префиксов ошибка вылезала только на oc_return... Спасибо что напомнил.