Настройки поиска (Страница 33 из 42)

Я понял, вы переключили в полнотекстовый режим поиска и поэтому у вас не находится по артикулу.
Я объясню почему, это связано с ограничениями полнотекстового поиска.

Плюс полнотекстового поиска

• поиск ведется по словам, поэтому они не обязательно должны находиться рядом. (ищем: "Диван красный", находим - "Диван замечательный красный")

• допустимы неточные окончания(это реализуется нашими средствами) (ищем: "Диваны красные", находим "Диван замечательный красный")
  

Минусы:

• В настройках к MySQL устанавливается минимальная длина слова, попадающего в индекс.
  Значением по умолчанию является - 4.  Соответственно в полнотекстовый поиск не попадают слова менее 4х символов.

• Спецсимволы (не буквы и цифры), являются разделителями слов.

То есть "TY-160/3R" - не попадет в поисковый индекс, т.к. MySQL разбивает его на 3 слова:
1. TY
2. 160
3. 3R

Все эти слова менее 4х символов, соответственно они не попадают в полнотекстовый индекс.

В вашем случае возможно использовать только поиск по like, чтобы искать по идентификаторам типа TY-160/3R

Нужно посмотреть на развернутый текст ошибки, чтобы понять ситуацию.
Включите опцию "Подробно отображать информацию об исключениях" в разделе Управление->Настройки системы в админ. панели.

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

Но если вам необходимо подгрузить комплектации в списке товаров, то необходимо добавить еще следующую конструкцию в начало шаблона list_products.tpl

{$list = $this_controller->api->addProductsOffers($list)}

Данная конструкция массово загрузит комплектации сразу ко всем товарам в списке.

Сейчас это можно сделать с помощью CSV, через колонку Фото. Т.е. необходимо залить папку с фото на сервер, и в CSV для каждого товара прописать путь к фотографиям относительно корня сайта. Вы можете увидеть эталонный CSV, если сделаете экспорт.

Но у нас сейчас на тестировании уже находится модуль, который будет позволять быстро загружать массово фото к товарам, для случая если имена файлов изображений точно равны одному из параметров товара (Артикул, Название, URL имя, Категория, Бренд, ID, XML_ID). Срок публикации данного функционала до 5ти дней.

Первый вопрос очень абстрактный, соответственно могу лишь ответить на него так: За внешний вид шаблонов отвечают CSS, разметка HTML, шаблоны Smarty. Если у вас есть навыки работы с данными вещами, то однозначно вы сможете сделать абсолютно все-что захотите с шаблоном. Если - нет, придется обратиться к специалистам.

Насчет редиректа, его можно делать на разных уровнях (через htaccess) или на уровне PHP.
Если через htaccess, то верно все делаете, вот есть хороший материал на этот счет. Не забудьте только убедиться у вашего хостинга, что включен модуль mod_alias для apache, чтобы это работало.

Если через PHP, то можно составить примерно такого содержания файл

<?
$redirect_map = array (
  'ОТНОСИТЕЛЬЙ ПУТЬ НА СТАРОМ САЙТЕ' => 'ОТНОСИТЕЛЬНЫЙ ПУТЬ НА НОВОМ САЙТЕ',
  '/ventilyaciya/reshjotki/plastikovye' => '/ventilyaciya/reshjotki-plastikovye',
  '/ventilyaciya/reshjotki/welevye' => '/ventilyaciya/reshjotki-welevye',
  '/ventilyaciya/reshjotki/kruglye-diffuzory' => '/ventilyaciya/reshjotki-kruglye-diffuzory',
);

if (isset($redirect_map[$_SERVER['REQUEST_URI']])) {
    $domain = 'http://ВАШ_НОВЫЙ_ДОМЕН.RU';
    header('location: '.$domain.$redirect_map[$_SERVER['REQUEST_URI']], null, 301);
    exit;
}

Сохранить данный файл в корень, например с названием redirect.php, и подключить его в точке входа вашего старого движка (обычно index.php) с помощью конструкции require('redirect.php'); в самом начале файла.

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

Если с категориями все не так сложно, можно видоизменить маршрут

        //Просмотр категории продукции
        $routes[] = new \RS\Router\Route('catalog-front-listproducts', array(
            '/catalog/{category}/',
            '/catalog/'
        ), null, t('Просмотр категории продукции'));

Примерно таким образом (перечислив все идентификаторы категорий, чтобы обойти конфликты с другими маршрутами):

        //Просмотр категории продукции
        $routes[] = new \RS\Router\Route('catalog-front-listproducts', array(
            '/{category:(demo-produkty|elektronika)}/',
            '/catalog/'
        ), null, t('Просмотр категории продукции'));

То с формированием Урлов для товара придется переделать его стандартный маршрут, примерно на такой:

        
        //Карточка товара
        $routes[] = new \RS\Router\Route('catalog-front-product', 
            '/{category:(demo-produkty|elektronika)}/{id}/', null, t('Карточка товара'));

И переделать метод getUrl у объекта \Catalog\Model\Orm\Product, необходимо дописать передачу
параметра category в маршрут, так как стандартно там передается только id

Но правда могут повылазить проблемы в непредсказуемых местах, ну и производительность будет немного меньше, если у вас слишком много категорий, так что пробуйте.

На практике мы делали однажды подобную работу для одного клиента, выгоды никакой не получили абсолютно для поисковой выдачи.

В интернете - не существует однозначного ответа каким должен быть урл, со слешем в конце или без (http://imperacms.ru/articles/seo/url-so … avilno.htm),
а соответственно можно выбрать как один вариант, так и второй. Мы выбрали вариант со слешем в конце.

URL без слеша в конце - это неизвестный для системы URL, поэтому система возвращает 404. Система однообразно ведет себя для всех неизвестных адресов, а именно отдает 404.

Если он вам нужен, вы можете создать правило в .htaccess.
Не думаю, что он нужен всем, так как адреса внутренних страниц вручную никто не набирает вслепую,
а поисковики берут те адреса, что представлены на сайте. Соответственно никакой проблемы - нет.

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

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

Если вам необходим больший объем данного поля, вы все правильно сделали, что увеличили его индивидуально для себя.

Это можно сделать:
1. просто в базе, тогда это будет до первого обновления модуля "Блок фотографий",
2. можно сделать с помощью дополнительного модуля (рекомендуемое решение), и обработки в нем события инициализации ORM объекта Photo\Model\Orm\Image

Примерно таким обработчиком (handlers.inc.php):

<?php
namespace ВАШ_МОДУЛЬ\Config;

class Handlers extends \RS\Event\HandlerAbstract
{
    function init()
    {
        $this
            ->bind('orm.init.photo-image');
    }

    /**
    * Модифицируем ORM объект - "изображение"
    * 
    * @param \Photo\Model\Orm\Image $image - объект "изображение"
    */
    public static function ormInitPhotoImage(\Photo\Model\Orm\Image $image)
    {
        $image->__servername->setMaxLength(255);
    }
}

Не забудьте переустановить модуль "Блок фотографий" (ссылка в настройках модуля), после активации вашего стороннего модуля. Система в этом случае сама изменит длину поля в базе.

3. Можно сделать с помощью создания image.my.inc.php, у которого изменена длина поля в стандартном описании полей. (не рекомендуемый способ)

При импорте из CSV данные попадают в базу в том виде, в котором они есть. В данный момент CSV реализован, как низкоуровневый инструмент чтения/записи данных в базу.

Просто замените двойные кавычки на " перед импортом с помощью автозамены.

1С предусматривает такой механизм, поэтому мы его поддерживаем, здесь однозначности - нет, для кого-то это все-таки "нужная" номенклатура, которая пришла с сайта.

Этот функционал рождает ряд вопросов, что если в заказе есть товары и которые были выгружены из 1С и те, которые не были выгружены из 1С. (выдергивать товары из заказа - невозможно, так как это влияет на стоимость и другие параметры заказа).  А вообще не выгружать такой заказ - тоже не правильно. Опишите, подробнее, как вы видите реализацию?

Нет, все не совсем так.
В 1С выгружаются все заказы, которые удовлетворяют заданным в настройках модуля обмена условиям, а именно статусам.

1С позволяет принимать заказы с товарами, которых нет в базе номенклатуры.  В этом случае в документе "заказ" должно отображаться название товара и цена, но товар не будет связан с номенклатурой в 1С.