Yesvik

Все псевдонимы должны быть уникальными

Эта тема реально достала перед глазами маячить... По коду похоже что изначально было задумано общее для всех товаров управление признаком изменения количества на складе, а потом это управление было сделано персональным для каждого товара.... а в модели забыли изменить. Короче ищем в файле admin/model/sale/order.php строки if ($this->config->get('config_stock_subtract')) { $order_query = $this->db->query("SELECT * FROM `" . DB_PREFIX . "order` WHERE order_status_id > '0' AND order_id = '" . (int)$order_id . "'"); if ($order_query->num_rows) { $product_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_product WHERE order_id = '" . (int)$order_id . "'"); foreach($product_query->rows as $product) { $this->db->query("UPDATE `" . DB_PREFIX . "product` SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_id = '" . (int)$product['product_id'] . "'"); $option_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_option WHERE order_id = '" . (int)$order_id . "' AND order_product_id = '" . (int)$product['order_product_id'] . "'"); foreach ($option_query->rows as $option) { $this->db->query("UPDATE " . DB_PREFIX . "product_option_value SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_option_value_id = '" . (int)$option['product_option_value_id'] . "' AND subtract = '1'"); } } } } и меняем так $order_query = $this->db->query("SELECT * FROM `" . DB_PREFIX . "order` WHERE order_id = '" . (int)$order_id . "'"); if ($order_query->num_rows) { $product_query = $this->db->query("SELECT op.*, p.subtract FROM " . DB_PREFIX . "order_product op JOIN `" . DB_PREFIX . "product` p ON (p.product_id = op.product_id) WHERE order_id = '" . (int)$order_id . "'"); foreach($product_query->rows as $product) { if ($product['subtract']) { $this->db->query("UPDATE `" . DB_PREFIX . "product` SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_id = '" . (int)$product['product_id'] . "'"); $option_query = $this->db->query("SELECT * FROM " . DB_PREFIX . "order_option WHERE order_id = '" . (int)$order_id . "' AND order_product_id = '" . (int)$product['order_product_id'] . "'"); foreach ($option_query->rows as $option) { $this->db->query("UPDATE " . DB_PREFIX . "product_option_value SET quantity = (quantity + " . (int)$product['quantity'] . ") WHERE product_option_value_id = '" . (int)$option['product_option_value_id'] . "' AND subtract = '1'"); } } } }

Ошибка вероятно в том что для категории и подкатегории заданы одинаковые псевдонимы

В шаблоне у которого хочеш отключить CKEditor находиш примерно такие строки <script type="text/javascript" src="view/javascript/ckeditor/ckeditor.js"></script> <script type="text/javascript"><!-- <?php foreach ($languages as $language) { ?> CKEDITOR.replace('description<?php echo $language['language_id']; ?>', { filebrowserBrowseUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserImageBrowseUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserFlashBrowseUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserUploadUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserImageUploadUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserFlashUploadUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>' }); <?php } ?> //--></script> и удаляеш ихСтрока <script type="text/javascript" src="view/javascript/ckeditor/ckeditor.js"></script> подключает CKEditor Строки CKEDITOR.replace('description<?php echo $language['language_id']; ?>', { filebrowserBrowseUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserImageBrowseUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserFlashBrowseUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserUploadUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserImageUploadUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>', filebrowserFlashUploadUrl: 'index.php?route=common/filemanager&token=<?php echo $token; ?>' }); заменяют textarea с id description<?php echo $language['language_id']; ?> на CKEditorЕсли у тебя в шаблоне одно текстовое поле - то удаляеш и подключение и замену, если несколько текстовых полей и ты хочеш отключить CKEditor только для одного текстового поля - то подключение оставляеш, а удаляеш только строки замены для этого поля

Если интересует моё мнение - то [цена] и [акционная цена] нафиг не нужны. Цену в тайтлах и дескрипшенах используют только демпингующие магазины. Если цена по рынку или выше то высока вероятность что покупатель увидев цену в поисковой выдаче даже не зайдёт в магазин... А ведь этого покупателя в магазине могли бы заинтересовать другие товары и он мог-бы их купить... А для сигнальных товаров или для товаров по которым проводится акция со снижением цены можно тайтлы и дескрипшены руками прописать. И ещё... я не знаю быстрого алгоритма формирования вменяемого дескрипшена. Реализовать формирование тайтлов по таким шаблонам - можно, но сейчас свободного времени совсем нет...

Вот это я и хотел увидеть... Из за этого и не выбирается основная категория.

Мне кажется что не совсем корректно говорить о закрытии ссылок в отдельно взятом модуле. Решение закрывать ссылку или нет должно зависеть не от того где ссылка отображается, а от самой ссылки... Я условно разбиваю страницы на 4 типа: Списки товаровпо категории по производителю по категории + производитель Страницы товара Информационные страницы Прочие Перечисленные списки товаров не конечные и дополнительно могут уточняться с помощью фильтра по опциям и ценам. Ссылки на страницы списков товаров без учета опций и цен - формируются в виде ЧПУ /category /manufacturer /category/manufacturer у этих страниц meta robots - index,follow Если список фильтруется по опциям и/или ценам то параметры фильтрации передаются GET параметрами добавленными к ЧПУ, например /category?option=val&price=val /category/manufacturer?price=val Аналогично GET параметрами в URL включаются параметры сортировки списка, количество товаров на странице и номер страницы... Наличие GET параметров в URL я использую как признак по которому запрещается индексирование страницы (у этих страниц meta robots - noindex,follow) URL страниц товаров формируется в виде ЧПУ с учетом иерархии относительно основной категории. Индексация этих страниц - разрешена (meta robots - index,follow). Но если при просмотре списка товаров использовалась фильтрация по опциям, то в ссылках на страницы товаров присутствует GET параметр option=val (этот сделано специально, мне так надо) и для таких страниц указывается meta robots - noindex,follow Информационные страницы почти все закрыты для поисковиков, открыты только карта сайта, адреса магазинов, о доставе и оплате плюс ещё некоторые специфические страницы. К прочим относятся все страницы HTTPS, корзины, аккаунта, поиска и т.д. - все эти страницы запрещено индексировать. Тайтлы и дескрипшены комбинированных страниц со списками товаров (производитель + категория) формируются путём добавления наименования производителя в начало тайтла и дескрипшена Для того что-бы в ЧПУ страницы товара присутствовала информация о производителе - в начало псевдонима товара добавляю производителя. ЧПУ получается таким: /category/subcategory/manufacturer-product На странице товара, кроме описания товара, присутствует описание производителя Вроде ничего не забыл и описал основные моменты схемы построения магазина.

xrgb покажи структуру таблицы product

Времени посмотреть что вошло в ocStore v1.0.1 нет, но в репозитории это дополнение есть и по идее должно было попасть в релиз. Если в настройках ocStore v1.0.1 присутствуют пункты как на картинке - значит это дополнение не актуально.

Надо быть внимательнее, у тебя не многобайтная функция.

Если не сталкивался - значит у тебя сервак настроен так что проблем не возникает.Суть проблемы: https://opencartforum.com/index.php?showtopic=3770&view=findpost&p=25674

Неоднократно обсуждалось и неоднократно я пояснял почему это возникает. Вариантов решения тоже предлагалось достаточное количество. Один из вариантов решения проблемы включен в релиз ocStore. Мне этот вариант не нравится, но данную проблему решает.

А зачем ты создал на сайте "папку оцсторе потом аплоад"... из папки upload надо заливать все файлы в корень сайта и устанавливать...

Сделано деление фразы на слова и поиск по словам. фраза делится только по пробелам, так что если в базе написано dir-300 то по фразе dir 300 - найдёт, по другому -нет.

Это не на форуме надо искать, а в мануале mod_rewriteЕсли магазин установлен в корень сайта : RewriteBase / Если магазин установлен в папку, например /shop : RewriteBase /shop

Был опыт по выкорчевыванию ссылок из Гугла... могу сказать что не нужные ссылки из индекса вылетают быстрее если по ним отвечать статусом 410, а не 404. Со статусом 410 - несколько тысяч ссылок вылетело из индекса за неделю, а до этого больше месяца был статус 404 и ссылки выпадали очень вяло.

Зачем закрывать? Всё абсолютно нормально... Гоша увидит статус 404 и сам уберёт ссылки из индекса. Если ссылки заняли какие-то позиции и хочется эти позиции сохранить - тогда надо разбираться с редиректом.... сам скрипт на редирект не влияет, скорее правила редиректа писал с ошибкой. А вообще есть желание написать что-то типа seo_history - таблицу в которую скидывать старые версии ЧПУ при изменении, а перед тем как выдать 404 искать ссылку по этой таблице и в случае успеха - редиректить на текущую версию ЧПУ... но это только планы, времени заняться этим - нет.

Добавить языковую переменную не достаточно, надо ещё в контроллере эту языковую переменную передать во вьювер...Полный маразм и раздражает не по детски, но так уж сделано... В catalog\controller\product\product.php надо добавить $this->data['text_product_info'] = $this->language->get('text_product_info');и только потом в шаблоне <span><?php echo $text_product_info; ?></span> <?php echo $product_info['sku']; ?><br />Только логичнее text_sku, а не text_product_info

Так сделай вывод в шаблоне как считаеш нужным. <?php echo $product_info['sku']; ?>

Эти поля предназначены для внутреннего использования и не отображаются на странице товара в публичной части. SKU - универсальный идентификатор товара (не обязательно артикул, это может быть составной идентификатор учитывающий характеристики товара, штрихкод и т.д.) UPC - Штрихкод. Размещение - Местоположение товара на адресном складе.

Перечитай ещё раз. Ещё раз повторюсь, при использовании ЧПУ проблем не увеличивается и не уменьшается. Сначала попробуй закрыть, а потом предлагай. Большие буквы желательно не использовать.Вместо подчеркиваний лучше использовать дефис (точнее - минус). Пробелов в URL быть не должно. Окончание - по большому счету не критично, но я предпочитаю указывать. В модуле SEO URL для ocStore 1.x я сделал так что-бы у категорий был в конце слеш (точнее не только для категорий товаров, а для всех URL у которых только route и path параметры), а для остальных страниц можно указать окончание (я предпочитаю .html)

Если для тебя не существует авторитетов, например Google и Яндекс - то никто не может запретить тебе переходить дорогу на красный свет и заплывать за буйки...

Если иерархия каталога позволяет и нужна ссылочная иерархия - то все строится примерно так: У товара должна быть основная категория и категории в которых отображается товар. URL всегда строится относительно основной категории независимо от того в какой категории он отображается. Если придерживаться идеи ссылочной иерархии - то каждая подкатегория является уточняющей родительскую категорию и в качестве основной надо выбирать категорию с максимальным уровнем вложенности. В данном случае категория /алкогольные-напитки/ обобщённая, а подкатегория /водка/ уточняет разновидность алкогольных напитков. Поэтому для товара смирнов-номер-21 в качестве основной надо указывать категорию /алкогольные-напитки/водка/, а /алкогольные-напитки/ это категория в которой товар отображается. При этом у товара всегда один URL /алкогольные-напитки/водка/смирнов-номер-21 . Это наиболее распространённый алгоритм, и главное не переусердствовать с количеством уточняющих категорий.... Бывают более сложные ситуации которые не вписываются в прямолинейную иерархию каталога, но это отдельная история и каждый случай надо рассматривать персонально. В таких случаях как правило жертвуют ссылочной иерархией и ссылки на товар приводят к виду /смирнов-номер-21. Хотя и тут можно улучшить информативность URL... Например мне нравится такая схема: для списков товаров по товарным группам /категория/ /категория-подкатегория/ /категория-подкатегория-подподкатегория/ и т.д. для списков товаров по производителю /производитель/ /производитель/категория/ /производитель/категория-подкатегория/ /производитель/категория-подкатегория-подподкатегория/ и т.д. для товаров всегда такое ЧПУ /производитель-наименвание-товара.html Как правило товар более тесно связан с производителем нежели с категориями каталога и поэтому можно смело завязать производителя с наименованием товара. В итоге получаются информативные ЧПУ позволяющие вставить ключевые слова и не создавать дикую вложенность.

Я уже писал на форуме что такое rel="canonical" и с чем его едят. Искать ссылки времени нет, поэтому всё излагаю своими словами и могут быть некоторые неточности/неоднозначности. Все прекрасно знают как поисковики относятся к уникальному контенту и не любят дублей. Вся эта "любовь" поисковиков имеет десятилетнюю историю. В былые времена продвигали сайты до безобразия незатейливо - брали одну страницу и дублировали несколько сотен раз по разным URL, получая соответствующий профит.... Поисковикам такой расклад не понравился и они начали вводить алгоритмы для борьбы с таким маразмом. Этот маразм побороли, но вылез побочный эффект - некоторые страницы на сайтах имели разные URL и это не всегда связано с желанием обмануть поисковик, но поисковики жестко относились к таким моментам и страницы либо вылетали из индекса либо понижались как страницы с не уникальным контентом. В начале 2009-го года (кажется в феврале) Гугл объявил о поддержке rel="canonical". Гугл рекомендовал использовать этот атрибут как крайнюю меру, когда другими способами не удаётся избавиться от разных URL. Этот атрибут не является директивой, что-бы умники не пытались злоупотреблять... Гугл сверяет контент страниц и если признаёт их одинаковыми или близкими по контенту, то принимая решение какой URL включать в индекс, может учесть атрибут rel="canonical". На практике - если страницы идентичны то в индекс попадёт каноническая ссылка. Не хочу сейчас обсуждать заявления о том что надо привести все URL товаров к виду /product и будет счастье. Это заявляет тот кто не пробывал это сделать и не знает что в результате получит другие грабли, например, с меню, с хлебными крошками и т.д... Сразу перехожу к Яндексу. С 2009-го года Яндекс обещал что будет поддерживать rel="canonical", но только обещал... На протяжении двух лет Яша безжалостно выкидывал страницы из индекса или понижал в выдаче не взирая на атрибут rel="canonical". Если я не ошибаюсь, 23 мая 2011-го года Яндекс объявил о поддержке атрибута rel="canonical", но как обычно надув щёки ничего не поясняет как он будет учитывать этот атрибут. А теперь почему я недолюбливаю rel="canonical"... допустим у каждого товара по 3 URL - не вижу ничего хорошего в том что поисковику прийдётся индексировать в 3 раза больше страниц. Поэтому самый правильный вариант - сделать так что-бы у каждой страницы был один URL. Именно это и было сделано в верси SEO URL который был включен в версию ocStore 0.1.9 Эта версия SEO URL не только формировала уникальные ЧПУ, а так-же делала уникальными URL с обычными GET параметрами, контролировала входящие запросы и делала переадресацию со статусом 301 на выбранный формат URL (это для того что-бы не проседали позиции если поисковик уже заглотил кучу ссылок в разных форматах). Что произошло у smarteg К формированию ЧПУ отнёсся крайне беспечно и в итоге получил полное безобразие, например, /алкогольные-напитки/водка/?product=2234 и /алкогольные-напитки/водка/смирнов-номер-21 (ума не приложу как такое могло приключится... разве что были добавлены/изменены модули с бардаком в формировании ссылок) После 23-го мая 2011-го года поимел грыжу от Яши. Это вылезли особенности поддержки Яндексом атрибута rel="canonical". Предполагаю что Яша просто выкинул из индекса страницы URL которых не совпадал с каноническим, а канонические URL по каким-то причинам не включил в индекс или не успел включить... Подозреваю что как и в случае с WWW и без WWW, склейкой занимается паук-зеркалировщик, а он приходит крайне редко и можно ожидать его от нескольких месяцев до полугода. Надо более плотно анализировать ситуацию что-бы точно ответить что произошло и как этого избежать. Самый правильный выход из положения - сделать что-бы у каждой страницы был один URL. При наличии нескольких URL на одну страницу ничего хорошего в отсутствии канонических ссылок - нет и возможно все "радости" ещё впереди... Например, продвигаеш страницу с каким-то URL, а поисковик решил включить в индекс эту страницу с другим URL... радует?