Yesvik

Если разные языковые версии магазина продвигаются в разных поисковиках, как дать ссылку на страницу с нужным языком? Чем тут может помочь robots.txt?Пробывал сделать два варианта: domain.tld/en/, domain.tld/ru/ и т.д. en.domain.tld, ru.domain.tld и т.д. оба варианта кривые до безобразия, пока остановился на варианте с доменами третьего уровня.Хотелось бы услышать мнения/решения опытных собаководов владельцев магазинов на OpenCart.

Опиши точнее что значит "пропадают товары"?Какая версия OpenCart? Как правило "_" используется в качестве разделителя слов. Некоторые поисковики воспринимают слова разделённые "_" как одно слово. При использовании в качестве разделителя "-" все поисковики воспринимают слова раздельно. Учитывая что вхождение ключевика в URL имеет значительный вес при ранжировании, а точное совпадение с поисковым запросом более релевантно - я бы не стал пренебрегать таким советом даже с учетом того что 100% подтверждения, описанному поведению поисковиков, нет.

Я выкладывал два варианта экспорта: 3 и 11 апреля, с каким вариантом возникала ошибка?

В OpenCart всё происходит примерно так:Сначала подгружается файл с английскими фразами, потом поверх него подгружается файл с фразами нужно языка. Если какая-то фраза в подгружаемом языке не задана - то она остаётся на английском языке. Сравни файлы английского и русского языков и найдёш где у тебя затерялся перевод для products

А можно точный текст ругани почитать?

Да, это остаточные явления борьбы с пробелами в алиасах, до которых руки ещё не добрались.Получается следующая засада: Если в алиасе есть и пробелы и подчерки, и в настройках включено "Заменять пробелы на "_" в SEO-url", то при формировании ЧПУ пробелы заменяются на подчерки... А при обратном преобразовании даже те подчерки которые изначально были в алиасе заменяются на пробелы. В итоге - ничего не работает. По хорошему надо поставить контроль чтобы всякие глупости в алиасы не писали, а не корректировать алиасы при формировании ЧПУ. Старайся придерживаться таких правил: В алиасах не должно быть пробелов, а вместо подчерка ( _ ), с точки зрения SEO, желательно использовать минус ( - ).

Выкладываю архив с исправлениями которые обсуждались в этой теме yml.zip

Меня собственно интересует вопрос - не напрягает то что надо Zend Framework использовать? ZF конечно можно покрамсать и оставить только нужное, но всё таки...

Есть один финт ушами с помощью которого можно организовать бесплатную отправку SMS. Суть метода в использовании Google Calendar. Календарь Гугла умеет отправлять SMS'ки-уведомления о событиях занесённых в календарь. Используя API Гугло-календаря можно программно создавать события с уведомлением по SMS. Время события устанавливается на 1-2 минуты вперёд и через пару минут, когда наступает созданное событие, Гугл радостно извещает владельца календаря SMS'кой. Если текста много - приходит несколько SMS'ок. Войну и мир я не отправлял, но сообщения из 3-4 SMS'ок приходили без проблем. Если я не ошибаюсь, Гугл отправляет до 500 SMS в день. Я пока эксперементировал - отправил не меньше сотни и все SMS'ки на Билайн приходили моментально. Кроме уведомлений с помощью SMS, Гугло-календарь поддерживает уведомления на email и алерты которые появляются на экране если в момент наступления события в браузере открыт Гугло-календарь. Ещё приятным моментом является то что все события остаются в календаре и всегда можно посмотреть хронологию событий. Единственной ложкой дёгтя в этой бочке мёда является то что проще всего с Гугло-календарём работать с помощью Zend Framework'а и что-бы не изобретать велосипед прийдётся где-то на путях положить Zend Framework. Такой вариант интересен? Я не говорю что сегодня или завтра реализую этот метод для OpenCart, но если такой вариант отправки SMS интересен - займусь написанием как появится время. Если кто-то захочет самостоятельно реализовать такую отправку SMS - могу поделиться кодом своих экспериментов.

Можно сделать более гибкий вариант... в массив informations добавить идентификатор статьи. В файле catalog/controller/module/information.php найти foreach ($this->model_catalog_information->getInformations() as $result) { $this->data['informations'][] = array( 'title' => $result['title'], 'href' => $this->model_tool_seo_url->rewrite(HTTP_SERVER . 'index.php?route=information/information&information_id=' . $result['information_id']) ); } и изменить так foreach ($this->model_catalog_information->getInformations() as $result) { $this->data['informations'][] = array( 'id' => $result['information_id'], 'title' => $result['title'], 'href' => $this->model_tool_seo_url->rewrite(HTTP_SERVER . 'index.php?route=information/information&information_id=' . $result['information_id']) ); } После этого во вьювере можно каждому элементу списка поцепить свой класс. В файле catalog/view/theme/НАЗВАНИЕ_ТЕМЫ/template/module/information.tpl найти строку <li><a href="<?php echo str_replace('&', '&', $information['href']); ?>"><?php echo $information['title']; ?></a></li>и изменить так <li class="info_<?php echo $information['id']; ?>"><a href="<?php echo str_replace('&', '&', $information['href']); ?>"><?php echo $information['title']; ?></a></li> Теперь стилями можно изголяться как угодно...

Зачастую "Оплата наличными" применима только к методам доставки "Самовывоз" или "Доставка курьером", а метод "Доставка курьером" применима только в пределах определённых городов...А что если добавить привязку методов доставки к регионам и к группам пользователей, для методов оплаты - привязку к методам доставки и группам пользователей? Тогда можно организовать такой сценарий оформления заказа: Покупатель выбирает регион доставки и в зависимости от группы пользователей получает список доступных методов доставки или сообщение "Извините, в данный момент мы не доставляем в регион ХХХ" После выбора метода доставки, в соответствии с группой пользователя - покупатель получает список доступных методов оплаты. Привязка к группе пользователей может понадобиться, например, для оптовиков... В таком варианте админ магазина самостоятельно сможет задавать правила зависимостей методов доставки и оплаты.

В строке $output .= '<yml_catalog date="' . date("Y-m-d H:m") . '">';неправильно указан формат, должно быть так: $output .= '<yml_catalog date="' . date("Y-m-d H:i") . '">'; Это не последняя ошибка которая у тебя возникнет. Почитай эту тему

"слишком много" - это сколько?Скопируй в корень сайта прикреплённый файл, и выполни его набрав в адресной строке браузера domain.tld/imgrename.php после того как увидиш Ok! - удали файл imgrename.php, и желательно удалить или очистить директорию /image/cache/data/ Пробелы будут заменены на подчерк в именах файлов и в БД. imgrename.php

Если пробывал именно так, то естественно не получится из-за синтаксической ошибки... пропущена закрывающая скобка.Попробуй так: $output .= '<picture>' . str_replace(' ', '%20', $img_v) . '</picture>' . $eof;или так: $output .= '<picture>' . str_replace(' ', '+', $img_v) . '</picture>' . $eof; А лучше всего - никогда не использовать пробелы в именах файлов.

Ща тебе хомяка ещё раз покажут... и правильно сделают. Телепаты определяющие что в какой строке - в отпуске, потому что устали от подобных вопросов.

Я вообще-то доверчивый товарищ... надеюсь вопрос о Денвере это был не прикол.Название Денвер произошло от произношения сокращения ДНВР (Джентельменский Набор Веб Разработчика). Весьма удобный набор для ленивых и начинающих... Вот что пишет автор Денвера: Подобные наборы принято называть WAMP (Windows, Apache, MySQL, PHP)Сокращение WAMP появилось как аналогия от LAMP (Linux, Apache, MySQL, PHP)

Попробуй такой вариант https://opencartforum.com/topic/2463-устранение-дублей-страниц-товаров-и-категорий/page__pid__16052

WAMP

А чего ты переживаеш за индексацию? Если ты не измениш псевдонимы у товаров и у категорий, то все старые урлы будут переадресованы на новые со статусом 301. Я прекрасно понимаю как болезненна смена URL - потому и сделал редиректы 301. Даже если товар был в одной категории и ПС заглотили ссылку, в дальнейшем можно спокойно перенести товар в другую категорию и на старые ссылки сработает редирект 301... главное что-бы псевдонимы категорий и товаров не менялись. Даже если ты не использовал псевдонимы и у тебя ссылки вида /index.php?route=product/product&path=25_28&product_id=42 - есть два варианта: 1. включить SEO но не прописывать псевдонимы и тогда будет работать контроль ссылок с редиректами на URL в котором path будет всегда один и тот-же; 2. включить SEO и прописать псевдонимы - тогда тоже будет работать контроль, но редиректы будут на ЧПУ; На любой из вариантов поисковики отреагируют лояльно. Проверка правильности URL использует алгоритм формирования ЧПУ, так что отдельно редиректы выдернуть не получится... Ну и в крайнем случае, можно не обновлять магазин полностью, а прикрутить только новый алгоритм формирования ЧПУ. В readme.txt расписано как это сделать.

Мне абсолютно безразлична родословная файла russian.phpВ ошибке конкретно написано что изменить заголовки не удалось, потому что заголовки уже отправлены при выводе в браузер, который начался в первой строке файла \catalog\language\russian\russian.php Я погорячился написав что перед <?php пустая строка... Возможно перед <?php есть пробелы или файл сохранён с BOM

В начале файла catalog\language\russian\russian.php пустые строки перед <?php

В архиве файлы для ocStore 0.1.9, как устанавливать на предыдущие версии описано в readme.txt

Пока у товара не будет однозначной привязки к какой-то категории это не реализуемо.Например, товар принадлежит к категориям /desktop/ и /desktop/mac/. Из какой категории брать набор атрибутов?

Если "товар принадлежит к категории cat1 и субкатегории sub1" как определить что надо формировать ЧПУ site.ru/cat1/sub1/product1, а не site.ru/cat1/product1? И вообще... смотрел вариант формирования ЧПУ который я предложил? Чем он тебя не устроил?

Новый вариант SEO URL