Dotrox

В оригинальном ОК нет og_url, потому я и спрашивал. И он всегда под рукой: https://github.com/opencart/opencart

Если б была стандартная, я б не спрашивал, как og_url формируется. После того, как вы сказали, что стандартная, я проверил ocStore и таки да, оно добавлено там. ocStore резко упал в моих глазах. При чём, og_image то там нормально через document выставляется. А og_url смахивает на какой-то сознательны саботаж.

Просто оторвать руки тому, кто это писал. По нормальному, ссылка должна формироваться в контроллерах страницы через $this->url->link() и передаваться в шапку через дополнительный метод в document (по аналогии с тем, как тайтл, например. устанавливается). Но, если хотите простой вариант, то хотя бы так: $data['og_url'] = $server . ltrim(str_replace('ocstore', '', $this->request->server['REQUEST_URI']), '/') $server - уже устанавливается в начале метода index после проверки текущего протокола (а потому нет необходимости проверять ещё раз и тем более подставлять ссылку прямо из конфига). ocstore - название вашей директории. Лишние слеши в начале удаляются через ltrim. Хотя этот вариант менее дырявый, чем оригинал, но тут остаётся недостаток в виде возможности попадания в ссылку различного мусора, например utm меток.

У Гугла нет понятия региональных (регионы одной страны) доменов! Вот это самый важный пункт, с которого нужно начинать обсуждения региональной привязки у Гугла. Гугл предполагает, что могут быть отдельные версии сайта для разных стран, но не в пределах одной страны. И проблема именно в этом: нет возможности дать понять Гуглу, что все поддомены - это версии одного сайта для разных регионов. https://support.google.com/webmasters/answer/182192?hl=en#2 Он, конечно, возьмёт во внимание, что у одного поддомена в контактах указан Киев, а у другого - Харьков, но есть вероятность, что один из этих поддоменов он вообще целиком под фильтр запихнёт увидев практически идентичный контент. Ну, и по опыту могу сказать: Гугл отлично знает в каком я городе (о чём постоянно напоминает мне строкой под выдачей), но я уверенно могу сказать, что не вижу никакого преобладания местных магазинов над киевскими (и не только), хотя у меня тоже миллионник и магазинов полно. Хотя, конечно, сайты, который выбивают местных из ТОП10 (и даже из ТОП20 довольно часто) - это Розетка и другие подобного масштаба, так что ничего удивительного в этом нет, но это лишь доказывает, что чуда не будет и региональная привязка не спасёт, если по остальным параметрам сайт существенно отстаёт. Что действительно имеет сейчас смысл для Украины, так это украинская версия (и Розетка ещё в начале года подсуетилась): тут и с Гуглом никаких проблем - языковые версии он отлично поддерживает и в пределах одной страны, и это просто возможность получить украиноязычный трафик, где конкуренция сейчас довольно низкая, так что есть шансы попасть в ТОП10 даже по ВЧ запросам без лишних извращений.

Raensul, как формируется содержимое $og_url?

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

Я говорил о реализации этого через модуль, а не о самих текстах. А через модуль идея не очень хорошая потому, что вы замучаетесь с таким вариантом. Да и не факт, что из коробки модуль позволяет такие большие тексты использовать. Изначально, оно там предназначено для коротких сообщений. Если вы всё сделаете правильно, он это вообще не будет считать дублем! Яндекс поддерживает региональные версии сайтов. То есть, если вы правильно обозначите для него, что это всё один сайт, но версии для разных регионов (а вам нужно именно этого добиться), то никаких извращений с уникальными текстами не понадобится. Вам в метатегах только названия городов нужно менять (ну, и телефон, возможно), а для этого сойдут шаблоны. php функция sprintf + модуль GeoIP, который умеет выдавать сообщение под текущий город. Ну, и немного ручной работы. Условно, это будет выглядеть как-то так: $data['title'] = sprintf('Купить кофеварку в %s', $this->progroman_city_manager->getCityName()); Только реально там никаких текстов прямо в коде (как у меня в примере) конечно же не будет: сам шаблон из языкового файла, название товара из соответствующей переменной. Вместо $this->progroman_city_manager->getCityName() может быть $this->progroman_city_manager->getMessage('__key_name__'), а сам __key_name__ и его значение для каждого региона заданы в админке модуля.

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

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

Именно это. Я очень надеюсь, что именно такой эффект и получится, но я на 100% уверен, что Твиг он влепил, чтоб привлечь свежую кровь, иначе по своей неотступной традиции он бы написал собственный шаблонизатор.

То есть, без ЧПУ магазин определяется правильно? Какая у вас версия ОК и какую систему ЧПУ вы используете? Вам в любом случае нужно сначала добиться правильного определения магазина, а затем уже разбираться с макетами, если проблема с ними всё же останется.

Забудьте пока о макетах. У вас сейчас, в принципе, магазин на поддомене не определяется - именно в этом проблема. Посмотрите, там сейчас все ссылки, где полный адрес, указывают на основной домен - это значит, что у вас на поддомене открывается основной магазин.

Нет, это не он. У вас здесь есть путь к директории admin (и то не хватает слеша вначале), а дальше просто непонятная приписка с .htpasswd. Полный путь должен выглядеть так: /bla/bla-bla/admin/.htpasswd - сравните с тем, что у вас сейчас. Ну, во-первых он не полный, ибо должен начинаться со слеша, а во-вторых, почему вы решили, что это вообще там нужно? У вас .htaccess уже лежит в директории, которую нужно запаролить.

Внимательно проверьте, что вы вписали при создании этого магазина (первый пункт) - там обязательно должен быть слеш на конце.

Да.

Не собака, а кто-то, кто слабо понимает, как обрабатывается .htaccess. Все редиректы должны идти до блока RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css) RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] Ну, и в принципе, редиректы, которые должны шаблонно перенаправлять все страницы сайта лучше размещать вообще сразу после RewriteBase /

Вот это неправильно. Здесь должен быть путь к .htpasswd, а у вас здесь что (внимательно посмотрите)? И почему require с маленькой буквы? Назначение последней строки вообще непонятно.

Значит сервер оказался ещё кривее, чем предполагалось. Пинайте хостера.

И не увидите, при чём вообще ничего - ошибки 500 туда не попадают!

Белый экран - это ошибка 500. Добавьте в index.php в начало: error_reporting(-1); ini_set('display_errors', 1); ini_set('display_startup_errors', 1); И смотрите, что напишет.

Вы могли и ничего не пропустить, а просто кривой сервер и не менее кривой ОК не смогли найти общий язык. В /catalog/controller/common/header.php перед установкой значения для base есть проверка на HTTPS и там есть вот такое условие (среди прочего): $this->request->server['HTTPS'] == 'on' Так вот, реально значение server['HTTPS'] может быть не "on", а "On" и в результате ОК не понимает, что используется HTTPS. Решение простое: обернуть $this->request->server['HTTPS'] в strtolower (что и должно было бы быть изначально), но проблема в том, что такое условие есть не только здесь, например, мне сразу в голову приходит модель изображений. файлменеджер в админке (да и сама шапка админки), система ЧПУ. То есть, если дело именно в этом, то придётся облазить ещё кучу файлов, чтоб всё поправить. Более простое решение - просто прописать в конфигах везде https, чтоб оно использовалось независимо от того, насколько ОК кривой.

Думаю, вам стоит пинать на хостинг в данном случае: нехватка памяти, нехватка необходимых библиотек.

Я же написал, что в .htaccess, который в директории admin. А как - путём добавления этой директивы.

Ну, так Дэниэль же выкинул оригинальный кешер и обещает в 3.1 собственный

Учитывая, что у вас всё равно отдельный .htaccess для директории admin, можете просто добавить туда RewriteEngine Off Это полностью отключит mod_rewrite и исключит все проблемы, которые могли бы быть вызваны им. В админке ЧПУ в любом случае не используется.