Dotrox

Верхнее меню = главное меню. В чём вы видите проблему, если всё работает именно так, как и должно?

А где вы такое вообще видели? Атрибута max-width не существует, это можно добавлять только через стили. И второе - у родительского блока должны быть размеры и ограничения содержимого. Что-то конкретнее смогу подсказать только увидев сайт.

Если хотите, чтоб картинка была адаптивной, не задавайте ей ширину, а поставьте max-width: 100%; Тогда она будет подстраиваться под родительский блок.

Да.

У вас таки другая версия шаблона. Тут изначально на странице ссылки пагинации ведут на этот модуль, потому пагинация и слетает при комментировании кода. Вообще, у вас там с вёрсткой какая-то жуть творится (доктайпа нет, содержимое head в body, незакрытые теги). Плюс, есть куски js, которые по несколько раз повторяются, например, тот, который в конец страницы воткнут (я так понимаю, это бесконечный скролл товаров), в нём ещё и ошибка: autoscroller.loading = ; Вероятно, там из php должно было значение подставится, но не подставилось.

Вероятно, у вас другая версия шаблона или конфликт с чем-то. Надо на сайт глянуть.

Если этот код у вас действительно закомментирован, то ссылки пагинации не должны подменяться, но должна быть ошибка js поскольку выше есть вызов этой функции. Посмотрите в консоли браузера: если ошибка есть - значит ссылки ещё раньше подменяются модификаторами (или оно так изначально в шаблоне), если ошибки нет - значит у вас используется код не из этого файла.

Ссылка не должна так выглядеть. Если она так выглядела изначально, значит у вас другая версия модуля и нужно заново разбираться.

Да, но есть несколько строк, которые зависят от версии ОК. RewriteRule ^sitemap.xml$ index.php?route=feed/google_sitemap [L] RewriteRule ^googlebase.xml$ index.php?route=feed/google_base [L] Это актуально для версий 1.5 - 2.2. Начиная с 2.3 должно быть так: RewriteRule ^sitemap.xml$ index.php?route=extension/feed/google_sitemap [L] RewriteRule ^googlebase.xml$ index.php?route=extension/feed/google_base [L] RewriteRule ^download/(.*) /index.php?route=error/not_found [L] Это актуально только для версии 1.5. Для версии 2.0 должно быть так: RewriteRule ^system/download/(.*) index.php?route=error/not_found [L] А для версий 2.1 - 3.0 так: RewriteRule ^system/storage/(.*) index.php?route=error/not_found [L] При чём, что в оригинальном ОК (до версии 3.0), что в ocStore в файле .htaccess, который идёт в комплекте ошибка - указан редирект для версии 2.0!

Может, для начала попробуете выкинуть из .htaccess весь лишний хлам? Кстати, после вот этой строки: RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] В принципе не должно быть никаких редиректов. В лучшем случае они просто не будут работать, а в худшем - будут работать так, что лучше б просто не работали.

А где вы такое откопали? Посмотрите в этой теме примеры редиректов через .htaccess. У вас здесь действительно одного слеша в конфиге не хватает или это вы накосячили, когда имя домена прятали?

Это бесполезно. Ошибка 500 говорит о том, что у вас фатальная ошибка php (либо в .htaccess перемудрили). Смотрите логи ошибок сервера и вспоминайте, что делали перед появлением ошибки.

Это реально костыльный способ - вот что это! В этой теме кучу раз обсуждались редиректы через .htaccess, почему вы выбрали именно этот костыль? Потому что там тоже должен быть редирект. www с точки зрения браузера - это другой домен, а браузер не будет грузить файлы с чужого домена при обращении по https.

Что-то вы путаете. В админке появляются только те, которые загружены через амиднку, как уже выше написал @Tom . Помните какие именно?

Модификаторы отображались в админке или они лежали в system? Что вы делали перед тем, как они перестали работать?

Значит вы через админку ничего не загружали. А что вы загружали в system?

А там вообще нет файлов или нет каких-то конкретных, появление которых вы ожидаете? Если вообще нет, проверьте права. Если нет конкретных, то не факт, что они там вообще должны быть: там появляются только модифицированные файлы.

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

Нет. Вы мозги включить пытались? Что меняется при переходе на https? Ссылка. Так с чего вы вдруг решили, что надо название констант тоже изменить? Нет. Разве я писал, что у вас проблемы с .htaccess? Лимит на телепатию закончился, покажите сайт.

Вы плохо посмотрели то, что процитировали, а именно вот эту часть: Если не поможет, тогда надо смотреть на сайт вживую.

Сразу видно, что вы не знакомы с философией Дэниэля В двух словах: DRY для него - это матюк, что отлично видно во всём коде ОК. Объясняет он это просто: без лапши гавнокодеры новички не разберутся с кодом ОК.

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

Очень просто быть: найти в файле шапки шаблона ссылку на шрифт и поправить протокол. Ну, а если планируете шаблон в будущем обновлять, то ничего не трогать, а пойти к автору шаблона и сломать ему руки просветить, что бывают магазины использующие https, а потому не надо в ссылках на внешние ресурсы использовать http. После чего ждать пока он не выпустит обновление, где это исправлено.

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

Тогда это просто независимые магазины и можно было даже не упоминать, что они на поддоменах. Яндекс поддерживает региональную привязку, так что с ним никаких проблем быть не должно. А для Гугла лучше было бы делать на отдельных доменах. Он разбивку на регионы в пределах одной страны, в принципе, не поддерживает, а в случае поддоменов может что-то неправильно понять и загнать поддомены под фильтр. В вашем случае каждый из магазинов и так получается самостоятельной единицей и непонятно зачем вообще поддомены.