rb2

В оригинальном опенкарте нет понятия основной категории. Из существующих разработок понятие главной категории вводится только в SeoPro, насколько знаю. Дальше - вопрос взаимодействия модуля импорта-экспорта с SeoPro (знает ли он про него или нет).

А что в этой структуре нестандартного?

Попробуйте переключиться на стандартный шаблон и посмотреть, как там отображается. Желательно также отключить все vqmod расширения (и очистить vqmod кеш) при проверке.

Надо понимать разницу. Responsive - условия отрабатываются на клиенте. То есть решения о том, какое из CSS правил применять, принимает броузер. Чем хорошо? Меняешь размер окна или масштаб текста - меняется и "раскладка страницы". Чем плохо? Ну, может не все броузеры умеют. Второе "плохо" - броузеру достаётся вся куча хлама и всё, что он может - просто по-разному её отображать. Нельзя раз представиться мобилкой и получать 100k страницы вместо 1.5MB. То, что в этом топике -- отрабатывает и принимает решение на сервере (решения, предложенные cmd, Baco, топикстартером). На сервере можно понять что-то и сразу принять решение: то ли отдавать одинаковый контент и разные CSS-ки к нему (подход, очень похожий на responsive), то ли вообще разный контент разным устройствам. Например, кол-во данных на странице, отдаваемое мобильным устройствам, может быть раз в 10 меньше, чем список или кол-во текста, отдаваемое десктопам и планшетам. Оформление вместо графики может использовать цвета или мелкие картинки в data-uri (уменьшая кол-во http-запросов между броузером и сервером). Картинки и превьюшки - отдаваться в размерах типа "до 320 пиксел" вместо чего-то вроде 500x500 или 800x600 - а это в 4 и более раз меньшая площадь и соответственно существенно разные размеры передаваемых файлов.

Если без изысков - модуль оплаты банковским переводом подойдёт. Там пишем инструкцию для покупателя, что счёт он получит после проверки. Дальше ручная работа по проверке заказа. И комментариями к заказу или обычной эл.почтой реквизиты или счёт отсылаются. Готовой кнопки по формированию счёта и отсылке там нет, конечно.

Третий раз повторю: нет.Или покажите. Возможно, это ошибка.

У всего пути до товара должны быть прописаны "seo keyword" - у категорий, подкатегорий (и так далее) и товаров. Будет где-то пропущено - и всё, не построишь красивую ссылку. Проверьте.

Каких предупреждений или окон? Если разрешено покупать при отсутствии на складе - то разрешено. И нет проверок и предупреждений в корзине.

То есть примерно всё. Т.к. сайту-визитке нужен только раздел статей, если правильно понимаю.Если бы топикстартер без проблем мог(-ла) выпилить ненужное - думаю, вопрос бы не задавался. И даже не возник бы. Поэтому перечень возможных граблей при переделке вполне уместен и как раз хорошо отвечает на вопрос. Может результатом как раз будет чеклист по обрезанию. Хотя мне статья из песочницы на хабре вполне объёмной и обстоятельной показалась - её недостаточно?

Посмотрел, подтверждаю - на oc1564 только на отображение влияет эта галка. Сам подсчёт не блокируется. В ocStore (версия с Github, `myopencart/ocstore`) это пофиксено. В девелоперской ветке Opencart на гитхабе (`master`, репо `opencart/opencart`, AKA v2.0) тоже пофиксено. Топикстартеру: а в чём проблема, что именно в старых советах по убиранию подсчёта вам не подходит?

Если я правильно понимаю ход вашей мысли, то все эти всевозможные модули для трекинга заказов свои данные хранят где-то в астрале, а не в БД и делают это не точно таким же способом, какой вы придумали реализовать? То есть ну нигде нет ничего похожего на отдельное поле для трек-номера или ссылки и какого-то отчёта по незавершённым заказам?

Полно. Не чини то, что хорошо работает. У некоторых магазинщиков цель - продавать, а не постоянно обновляться.

https://www.google.com/search?q=opencart+tracking+number https://www.google.com/search?q=opencart+%D1%82%D1%80%D0%B5%D0%BA%D0%B8%D0%BD%D0%B3+site%3Aopencartforum.com Думаю, полезно научиться пользоваться поиском.

Ничем не плохо, cmd предлагал то же самое на предыдущей странице (месяц назад). Там чуть более глобально (через TPL - и включай что угодно, включая перекраивание и укорачивание HTML), здесь - только через CSS. Когда этого может оказаться недостаточно? Когда возникает потребность сделать именно разные приложения: меньше трафика, меньше яваскрипта с аяксом и "одностраничными приложениями" (в целях большей отзывчивости и совместимости со ВСЕМ зоопарком мобильных устройств), иногда и с другим UI и совсем другим UX, навигацией и т.п. в мобильном и десктопном приложениях. (Markimax-а просьба воздержаться от комментариев - позиция понятна, от десятикратных проповедей ничего не изменится.)

Попробовал. 1. 404 2. home page Какие угрозы безопасности это несёт?

Ну правильно, на мой взгляд, меняется. С дурацкой вёрстки на нормальную :) Скорей всего какая-то нормализация при преобразовании производится, чтобы валидный результат выдавать. Но если очень хочется сохранить именно авторский вариант - выше уже предлагали. Не переключайтесь в режим просмотра. Я, кстати, тоже никогда нигде визуальными редакторами не пользуюсь, всегда отключаю/переключаю. И ничего, жив. И не борюсь ни с чем ежедневно.

Без понятия. Я не работал с RTL языками, никакого опыта с возникающими там проблемами нет. Иврит и арабский пару раз встречал (и даже с опенкартом), но никто не жаловался. Даже не подозревал о таких проблемах. Поэтому пока альтернатив жёсткому выбору RTL/LTR для поля адреса не знаю. Ну и ещё стоило бы проверить, как введённое отображается в той же почте или базе данных, а не только в броузере.

Ну как какой? Хостинг свой настраивать. Где-то через `php.ini` в папке домена это решается, где-то через `.htaccess`, где-то в панели управления хостингом, где-то запросом в службу поддержки.

Вы перевод слова "required" знаете? ;)

http://stackoverflow.com/questions/15659390/ckeditor-automatically-strips-classes-from-div I found the solution after much digging, if you go into config.js and set: CKEDITOR.config.allowedContent = true;it stops the editor messing around with things then.

Для требуемых элементов можно в CSS указать `direction:ltr;`. Для тех двух элементов, которые указаны на скриншоте: #register input[name="email"], #register input[name="postcode"] { direction: ltr; }

В отсутствии языкового файла. Скорей всего какой-то модуль только с английским поставлялся, а для используемых языков модули почти никто не фиксит перед установкой.

По умолчанию в языковых файлах как раз ISO-формат даты и не встретишь. Если в ocStore он такой по умолчанию - это только потому, что я люблю ISO-формат, а мой перевод для 1.5.x был использован в ocs101 и оттуда тянется. Поэтому в модуле надёжнее было бы чётко указывать требуемый стандартом формат даты-времени.

Да и первая сработает. Можно любую использовать.

$mail->setTo( $this->config->get('config_email') . ',' . $this->config->get('config_alert_emails') ); или $mail->setTo( array( $this->config->get('config_email'), $this->config->get('config_alert_emails') ) ); Естественно, в таком виде все получатели будут видеть всех адресатов такой "мини-рассылки".Использование BCC в библиотеке опенкарта не предусмотрено - если надо bcc, придётся допиливать или использовать вызов `mail()` напрямую.