Yesvik

Честно говоря надеялся на кардинальные изменения. Надежды не оправдались, прийдётся продолжать работать рашпилем...

Да, отличается. Для ссылок на страницы товаров всегда один и тот-же путь, независимо от того где выводится ссылка на страницу товара. Кроме этого контролируются ссылки на входе и при запросе по дублирующейся ссылке выполняется редирект на основной URL со статусом 301. Никак. Дублей не бывает важных и не важных, дублей просто не должно быть. Какую категорию укажеш в качестве основной, та и будет использоваться при построении URL. Не экспериментируй на боевом серваке, потренеруйся на кошках копии. seopack - это расширенный пакет исправлений и дополнений для работы с ЧПУ Список изменённых/добавленных файлов с краткими пояснениями. system/library/response.php - Замена на ЧПУ ссылок типа route=information/contact, route=information/sitemap и т.д + главная страница без index.php?route=common/home system/library/pagination.php - Ссылки на первую страницу в постраничной навигации без параметра &page=1 catalog/model/tool/seo_url.php - Изменения связанные с построением и контролем ссылок типа route=information/contact, route=information/sitemap catalog/controller/product/special.php - Изменения для валидности (замена & на &) catalog/controller/product/search.php - Изменения для валидности (замена & на &) catalog/controller/product/product.php - Изменения для валидности (замена & на &) catalog/controller/product/manufacturer.php - Изменения для валидности (замена & на &) catalog/controller/product/category.php - Изменения для валидности (замена & на &) catalog/controller/module/special.php - Изменения для валидности (замена & на &) catalog/controller/module/latest.php - Изменения для валидности (замена & на &) catalog/controller/module/featured.php - Изменения для валидности (замена & на &) catalog/controller/module/bestseller.php - Изменения для валидности (замена & на &) catalog/controller/information/information.php - Формирование хлебных крошек с использованием ЧПУ catalog/controller/feed/google_sitemap.php - Убраны повторы ссылок на страницы товаров catalog/controller/common/seo_url.php - Разбор и контроль ЧПУ для ссылок типа route=information/contact, route=information/sitemap и т.д. admin/view/template/setting/setting.tpl - Убраны параметры seo_url_replace и seo_url_auto, добавлен seo_url_postfix. Можно указывать желаемое окончание ЧПУ. admin/view/template/module/seo_url_form.tpl - Форма шаблона добавления/редактирования псевдонимов для для ссылок типа route=information/contact, route=information/sitemap и т.д. admin/view/template/module/seo_url.tpl - Шаблон модуля SEO URL Manager (построен на базе модуля deadcow_SEO) admin/model/module/seo_url.php - Модель модуля SEO URL Manager admin/language/russian/setting/setting.php - Изменения связанные с удаленными и добавленным параметрами настроек. admin/language/russian/module/seo_url.php - языковой файл модуля SEO URL Manager admin/controller/setting/setting.php - Изменения связанные с удаленными и добавленным параметрами настроек. admin/controller/module/seo_url.php - Контроллер модуля SEO URL Manager .htaccess.txt - Добавлено правило для редиректа domain.tld/index.php на domain.tld/

Честно говоря я не понимаю зачем добавлять .php Могу ещё понять тех кто использует .htm или .html - наследие прошлого и желание представить страницы статическими. Лично я считаю что никаких окончаний лучше вообще не использовать, точнее окончанием должен быть слеш. Все стараются в URL засунуть ключевики и и разбавлять их мусором из всяких буквенных окончаний я бы не стал. Это решение не приемлемо. Я напишу свой прибамбас с аяксом который будет использовать те-же правила транслитерации и будет контролировать уникальность псевдонимов. Дай ссылку или приведи примеры псевдонимов и формируемых ссылок для категории и её подкатегорий.

Вообще-то тот вариант что я выкладывал был заточен под то что страна происхождения вписывалась в поле SKU, как у тебя там появились шт. - не понятно...Будет ошибка. Закомментируй эту строку.

Попробую вкратце пояснить происходящее. У Гугла нет особого отношения к интернет-магазинам. Разгадка кроется в rel="canonical" и дублях страниц. Атрибут rel="canonical" был анонсирован Гуглом в начале 2009 года, если я не ошибаюсь то вместе с Гуглом о поддержке этого атрибута заявили Яху и Майкрософт. Яндекс делал заявки о том что тоже будет поддерживать rel="canonical", но насколько мне известно, по сей день так и не поддерживает. При этом надо понимать что даже для ПС поддерживающих rel="canonical" наличие этого атрибута не является директивой, а просто принимается к сведению. rel="canonical" надо использовать как крайнюю меру, когда технически убрать дубли не получается. Простой пример: на сайте страница товаров имеет 3 ссылки (а если товар отображается в нескольких категориях - то ещё больше). Паук приперся на сайт и начинает... обхаживать дублирующиеся ссылки! Да он отиндексил страницу на которой указана каноническая и принял это во внимание, и в выдаче будет каноническая страница... но индексирование Вашего сайта идёт в 3 раза медленнее! А для Яши, мало того что медленно индексируется сайт, так ещё и одна страница с разными адресами - дублирующийся контент. Теперь понятно почему медленно? почему с Гуглом проблем нет? UPD: Кстати штатный google_sitemap.php - злобное чудовище отдающее все дубли. Можеш скачать seopack, там есть google_sitemap.php в котором обрезано формирование повторов.

Я извиняюсь, но Вы когда-нибудь торговали железом? Вам знакома специфика этого бизнеса? Вам известна динамика цен? Подорожание случается очень редко, в основном цены движутся вниз! Будут ли у Вас покупать если Вы не будете двигать цену за рынком? Догадываетесь что будет с Вашим складским запасом если не имеете прайс-протект? С учетом динамики цен и низкой маржи - очень быстро получите огромные остатки по космическим ценам.

Согласен. $parts = explode('_', $key, 3); if (sizeof($parts) == 3 && $parts[0] == 'model') { $model = $parts[1].'/'.$parts[2]; $this->get('load')->model($model); } Но как по мне - регулярка в данном месте логичнее. А преждевременная оптимизация - зло.

Надеюсь сегодня успею выложить копмлект для более расширенного управления псевдонимами.Если и на нем не заведётся - прийдётся разбираться что и как у тебя установлено.

У меня небольшая загвоздка...В новом варианте seo_url я убрал в настройках 2 пункта. Замена пробела на подчерк и добавление слеша в конце ЧПУ. Добавил поле для ввода окончания ЧПУ. Это поле можно оставить пустым или указать любое желаемое окончание ЧПУ, например, / или .html и т.д. Но остаётся открытым вопрос с заменой пробелов на подчерк... Заменять на лету не совсем корректно и работает только при соблюдении определённых условностей. Если я добавлю процедурку которая по нажатию кнопочки пройдётся по всем псевдонимам и приведёт их в порядок (заменит пробелы на минус) - это будет нормальным решением? Это решение временное, пока не допишу формирование псевдонимов при создании/редактировании категорий/товаров/производителей/статей с соответствующим контролем правильности написания псевдонима при ручном вводе. Пошел писать исправлялку, но жду пожелания или другие варианты решений этой загвоздки.

Я в первые дни знакомства с OpenCart посмотрел профайлером что к чему и мне стошнило, взял банальный CacheLite с раскидыванием по разным дирам - земля и небо... только с удалением там немного через банальное отверстие получается. Дело в том что если категорий мало то в кеше болтается пару десятков файлов и существующее решение не напрягает, но если начинаеш активно пользовать кеш или категорий много - без кеша быстрее работает. Я пока отложил эту тему, но обязательно вернусь к ней.

Да что там тестить? Есть куча мест где тормоза на порядок круче регов. Например кешер с glob'ом - это не просто тормоз, это якорь закопанный в землю...

Ну вот... дай палец и руку отхватят.Я говорил что поправлю синтаксис... потому что сам алгоритм решения задачи - кошмар. В catalog\controller\product\product.php уже всё есть. Вот строка которая получает информацию о товаре: $product_info = $this->model_catalog_product->getProduct($product_id);среди прочего там есть и количество, на основании этого количества и формируется $stockБери $product_info['quantity'] и обрабатывай как тебе надо.

Все настройки в файле admin/view/javascript/ckeditor/config.js Можно включить ресайз, закомментировав строку: config.resize_enabled = false;Если надо указать фиксированную высоту - добавь строку: config.height = '500px';

Точки с запятой, пробелы расставь. И как ты вызываеш метод getCount()? Выложи оба файла - исправлю синтаксис...

Ну так вырезай из дампа все таблицы форума.

То что шаблоны написанные для ocStore с таким патчем не будут совместимы с OpenCart без этого патча - не говорит об обратном... и шаблоны "из коробки" будут работать.

Корзина действительно не нужна поисковикам, также как и поиск, личный кабинет и т.д.Я для тестов автоматом собрал и затолкал в модуль кучу пар запрос->псевдоним... А вообще каждый сам будет добавлять/удалять пары запрос->псевдоним так как сочтёт нужным.

У тебя был какой-то прибамбас создавший таблицу oc_admin_info_files, при переустановке ты все таблицы снёс вот и ругается. Сливал дамп только с данными или есть старая структура?

Ошибку нашел, исправил, но у меня уже почти готовы новые заморочки с ЧПУ... Произвольные окончания, ЧПУ на ссылки типа route=account/account, route=checkout/cart и т.д. Выкладывать исправления или новый вариант?

А какие ссылки формируются в постраничной навигации?

Поделись информацией, почему было "ge"?

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

opencart_1.4.0_rus_0.4 а что это? где можно посмотреть?

controller.php мне не нужен, проблема не в этом файле, а в admin/language/russian/catalog/category.php Кстати файл controller.php должен быть в ANSI, не мучай его...

А откуда тогда пурга про Японию? Япония и прочая пурга прописаны в коде модуля который включен в стандартных версиях... Определись что именно у тебя установлено.