Dotrox

Что и куда вводить руками? У вас SeoPro включён?

И перебор регулярками сгенерированного кода? Это ещё хуже, чем перебор модификаторами исходного кода, ибо модификаторы не срабатывают на каждый запрос. Хотя да, искать станет значительно проще, поскольку искать придётся только вхождение 'http://' и в рамках одного запроса нагрузка будет меньше, чем при обработке модификаторами всех файлов, но перебор регуляркой всего output на лету - это плохая идея.

Если где-то ссылка формируется не через $this->url->link(), то я слабо представляю, как это возможно, потому что даже, если попробовать модификаторами прошерстить все файлы, то нужно ещё знать на что их шерстить (хотя, может вариантов меньше, чем мне кажется). Если в конфигах для обоих версий (HTTP_SERVER и HTTPS_SERVER) вбиты ссылки с https, а проблема осталась даже с фиксом, то, скорее всего, автор модуля где-то тупо вбил в код 'http://'.

Судя по ошибке, вы проблему неправильно сформулировали. У вас не страница корзины по https не работает, а страница корзины содержит ссылку с http, на что брузер и ругается. Ссылка эта в самом модуле быстрого заказа и, вероятно, формируется не совсем правильно, так что никакие сторонние фиксы тут не спасут. Лучшее решение: купить нормальный модуль оформления заказа - Simple. Ну, либо этот расковырять и поправить (но если сами не сможете, то дешевле будет купить Simple).

Вы не указанные, а все смотрите. В этих файлах ошибки только наружу вылезли, а причины могут быть где угодно. С сессией такое обычно из-за нехватки места или прав. А вот вторая ошибка - полтергейст какой-то. Вы наличие свободного места каким образом проверяете, через панель хостинга? А там ведь показывает не сколько реально место на диске, а сколько использовано из лимита аккаунта. То есть, на диске может быть 0, а там показывать и 10Гб свободных. И почистите директорию tmp (заодно посмотрите, появляются ли там какие-то новые файлы).

Ошибка у вас странная. Получается, что где-то в процессе обработки index.php у вас объект конфига превращается в тыкву.Изначально он точно есть, иначе б ошибка вылезла раньше. Вспоминайте, какие файлы вы редактировали.

Да. Но если у вас новая ссылка не "http://domain.com/posuda", то и вторая половина редиректа должна быть другой.

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

А вы уверены, что код появился на странице? Если у вас есть модули, которые модифицируют header.tpl, этот файл есть в кеше модификаторов, а значит без обновления кеша модификаторов вы никаких своих правок не увидите (и Гугл их тоже не увидит). У вас на ОК магазин или что? Если магазин, то любая сторонняя реклама - это плохая идея. Во-первых, таким образом вы уводите людей со своего сайта, а во-вторых, вы снижаете доверие к сайту, потому что, если магазин пытается зарабатывать на сторонней рекламе - логично предположить, что с ним что-то не так.

Поддерживаю! Очень не хватает этой возможности. И с редактированием вставленного кода не очень удобно, что редактируется он только через всплывающее окно. Это было бы ещё терпимо, если б можно было просто переключиться в режим ВВ-кодов и редактировать там всё.

Покажите что у вас в /admin/index.php. И какая конкретно у вас версия ОК?

Скорее, второе. Почему вы решили использовать директиву Redirect? ОК уже использует директивы из модуля mod_rewrite, а Redirect - это mod_alias. Их совмещение может привести к непредсказуемым результатам. Если речь идёт о ссылках на категории, то надо так: RewriteRule ^chashki(.*)$ /posuda$1 [L,R=301] Для товаров ещё проще: RewriteRule ^chashki$ /posuda [L,R=301] И не забывайте, что редиректы должны идти сразу после RewriteBase /

А как вы думаете, если ссылка выводиться вот так: $this->data['home'] = $this->url->link('common/home'); //контроллер <li><a href="<?php echo $home . '&ver=mobile'; ?>">На мобильную версию</a></li> //шаблон Для справки, 'common/home' - это главная страница. Если вы хотите, чтоб пользователь попадал на ту же страницу, где был, надо так: //Контроллер: $route = $this->request->get['route']; unset($this->request->get['route']); $this->request->get['ver'] = 'mobile'; $this->data['page_link_mobile'] = $this->url->link($route, $this->request->get); //Шаблон: <li><a href="<?php echo $page_link_mobile; ?>">На мобильную версию</a></li> И точно так же для ссылки на полную версию, только вместо mobile везде будет full. Кстати, в оригинальном посте вообще гавнокод. Во-первых, ссылка с '&ver=mobile' должна работать только при выключенном ЧПУ, потому что иначе в ссылке, к которой этот параметр приклеивается может не быть '?', который указывает на начало GET параметров и параметр не прочитается. А во-вторых, там обращение ко всем суперглобальным переменным идёт напрямую, хотя в ОК есть $this->request->get и т.д. для всех суперглобальных переменных.

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

Какая ещё статика?! На любом шареде статика на nginx. Кроме того, для 404 (и других ошибок) в Apache есть ErrorDocument. Но он срабатывает только для несуществующих файлов, а если речь идёт про несуществующую страницу в ОК, то о редиректах в Apache нет смысла говорить, потому что уже сработала строка с RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] и дальше в любом случае обработка идёт уже средствами ОК. То есть, если говорить о несуществующей странице (и заранее не было известно, что она не существует), то редирект через Apache просто не получится сделать! А если заранее известно, что страница не существует, то подойдёт обычный редирект с RewriteRule и перебор правил редиректов через Apache в любом случае будет быстрее, чем передача запроса в php и проверки там, ибо Apache написан на C, так что любые задачи будет выполнять на несколько порядков быстрей программы написанной на интерпретируемом php. Плюс, опять же, экономия php воркеров, которые всегда лимитированы. А это уже вопрос к тем, кто их пишет. Кривой код в php встречается не реже, но это не повод обвинять язык, он не виноват, что так привлекает гавнокодеров.

Да. А почему вы изначально использовали RedirectMatch? Такой вариант не часто можно встретить (вероятно, именно из-за нюансов согласования работы разных модулей).

Возможно, дело в том, что за директиву RedirectMatch отвечает другой модуль Apache (mod_alias) и потому она срабатывает параллельно с редиректом для ЧПУ через RewriteRule (mod_rewrite). Попробуйте так: RewriteRule ^(.*)\.html$ /$1/ [L,R=301]

Пора уже в шапке форума повесить объявление о том, что все редиректы должны быть до строки с RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] Вас не смущает, что у вас в заголовках ответа сервера указан такой адрес перехода: Location: http://example.com/342-tovar/?_route_=342-tovar.html ? Все редиректы надо вписывать сразу после RewriteBase /

Скорее всего, у какого-то товара значение этого атрибута не заполнено или там пробел вместо текста.

Ну, всё правильно - оно и не должно так работать. В каждой теме с .htaccess приходиться повторять, что все правки должны быть до строки с RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] Иначе они работать не будут. Редиректы надо размещать сразу после RewriteBase / Перенесите строку с редиректом и всё должно заработать. Откуда задержки? Как раз, по возможности, все редиректы надо делать через .htaccess, потому что это избавляет сервер от необходимости запускать php и как следствие, во-первых, такой редирект будет работать быстрее и потребляя меньше ресурсов, а во-вторых, это экономит php воркеры, потому что, опять же, до php дело не доходит. Другой вопрос, что мало кто умеет работать с .htaccess. При чём, речь идёт о том, что большинство вообще его не понимают и тупо копипастят найденные строки куда попало и в результате правки либо просто не работают, либо вообще приводят к различным ошибкам (типа бесконечных редиректов и т.д.).

RewriteBase / RewriteCond %{HTTPS} off RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{QUERY_STRING} !(.*)service/db(.*)$ RewriteCond %{REQUEST_URI} !^robots\.txt$ RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] Первая строка тут для ориентира, куда остальное вставлять. А всё, что сейчас в файле есть, пусть и остаётся (я про стоковый).

А вы её куда именно вписали? Порядок директив в .htaccess имеет не меньшее значение, чем их содержимое.

Каких кусокв? У вас в ошибках указаны строки 344, 447, 260. Откройте в браузере исходный код страницы и смотрите, что в этих строках.

Логично. Вот так должно всё работать: if(filter_url.search(new_route) == -1) { var query = [new_route]; if(typeof($('#content').attr('data-path')) != 'undefined'){ query.push('path=' + $('#content').attr('data-path')); } var i = filter_url.indexOf('?'); if(i > -1){ query.push(filter_url.slice(i+1)); } filter_url = 'index.php?' + query.join('&'); } А код модуля действительно местами не очень. Ну и, за отсутствие поддержки ЧПУ действительно можно было бы от автора потребовать либо исправлений, либо компенсации.

Эти редиректы так не делаются. Должно быть так: RewriteRule ^armatura-dly-topochnuh/nasosi/(.*)$ /nasosy/cirkulyacionnue-nasou/$1 [L,R=301]