Не работает поиск по артикулам. Есть решение

Добрый день!

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

Например: артикул 382. Есть 8 цветов, для каждой заведена своя карточка товара. http://miltex.su/search/?query=%D0%92%D0%B5%D1%82%...

Если набрать в поиске "382" высветится только 5 цветов. http://miltex.su/search/?query=382
Почему другие три цвета не высвечивает?

Что пробовала:
- заново удаляла и добавляла на сайт эти позиции, все равно не высвечиваются!

2 ответа

  • 1

    В разделе Магазин - Настройки - Поиск товаров обновите индексную базу для всех товаров.

  • 1

    Не дождавшись ответа пошел экспериментировать на живом магазине. Взял первый попавшийся под руку товар, попробовал его найти - не нашел. Хорошо... Запустил переиндексацию. Подождал 1 час 28 минут, снова попробовал найти тот же товар. Нашел. Завел новый товар. Тоже смог его найти. Это уже хорошо. Стало быть после каждого добавления товара не обязательно перестраивать индекс.

    Так а когда ж его надо перестраивать? Ведь как ни крути, а он или ломается или не обновляется в каких-то случаях... Вам известно в каких? Ну хотя б приблизительно? Эта информация, на мой взгляд, необходима, т.к. неработающий поиск может прямо влиять на конверсию магазина. Или самому экспериментировать и искать бреши в этом процессе?

    Еще вопрос: можно ли запускать перестройку индексов по cron у?

    Теоретический вопрос: что случится если перестройку индекса запустят 2 администратора, каждый со своего компа?

    Спасибо.

    • +1

      При редактировании единичного товара в админке индекс корректно перестраивается для этого товара.

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

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

      Можно обновлять по крону. Есть такая команда:

      /path/to/your/php /path/to/your/cli.php shop searchIndex

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

      • +1

        Леонид, спасибо, в общих чертах понятно. Но рискну предположить что не все так гладко в этом королевстве. Делаю такой вывод потому как при редактировании товаров используются исключительно штатные инструменты, а индекс кривой... Есть пара соображений в этом направлении, но сначала поэкспериментирую, а по результатам отпишусь. Но и вы подумайте при случае... Есть тут какая-то бяка. "Чувствую... Я всегда чувствую." (с) Джентельмены удачи :)

      • +1

        Леонид, подскажите, есть какой-то программный способ убедиться в целостности индекса? Ну или скрипт какой-нить для поиска товаров, чтоб не руками в интерфейсе несколько десятков товаров искать...?

        • +1

          Убедиться в целостности индекса?.. Сделать бэкап, пересоздать индекс и сравнить с бэкапом? Наверняка будут проблемы с изменившимися id... Чёрт его знает. Ничего лучше в голову не приходит.

          Скрипт для поиска: нет ничего проще. В приложении developer что-то вроде:

          wa('shop', true);
          
          function canBeFound($product_id, $query) {
              $c = new shopProductsCollection('search/text='.$query); // UPD исправлено
              $found_ids = array_keys($c->getProducts('id'));
              return in_array($product_id, $found_ids);
          }
          
          if (canBeFound(26499, 'лампочка')) {
              echo 'Нашли!';
          } else {
              echo 'Не нашли.';
          }
          
          • +1

            Пардон, с хэшем коллекции напутал. Не search/query=, а search/text=

            query - это для поиска LIKE'ом.

          • +1

            Упс.... Могут изменяться ID товаров? Обалдеть.... Целую подсистемку переписывать придется....

          • +1

            Леонид, по каким местам распиханы индексы и все с ними связанное? С сожалением должен констатировать, что мои эксперименты результата не дали. Но однозначно могу сказать, что в течение 3 месяцев штатного использования магазина индексы поломались. И я намерен понять причину :) Хочу бэкапить раз в час все необходимые элементы. Отсюда и вопрос: что мне нужно бэкапить чтобы в случае поломки индекса медленно и планомерно докопаться до причины? Все менеджеры были крепко взяты за выпирающие части тела, и в случае проблем с поиском тут же будут докладывать в любое время суток, в этом я не сомневаюсь :)

            • +1

              Индекс хранится в двух табличках: shop_search_index и shop_search_word.

              Данные для индексирования берутся из: shop_product, shop_product_skus, shop_type, shop_product_tags, shop_tag, shop_product_features, shop_feature, shop_feature_values_*

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

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

              • +1

                Т.е. все есть в БД... Отлично. Ну тут все относительно несложно... Учитывая что импорт из CSV неидеален, и есть нюансы, о которых я писал достаточно давно, то все массовые операции я делаю сам, ибо цена ошибки слишком высока. Безусловно, с тех пор технология несколько видоизменилась и упростилась, но не настолько чтобы доверить ее ненадежным товарищам :) А ручное добавление товара практически исключено. Редактирование же логгируется. Ну далее все просто... Берется менеджер за те же самые части тела, или за более чувствительные, и проводится опрос с особым цинизмом, в результате которого воспроизводятся все произведенные в админке манипуляции... Ну в общем опыт есть, не переживайте :) Вот только б индекс поломался... Но почему-то в этом я не сомневаюсь. подождать только надо. По моим прикидкам - не более 3 месяцев :)

                Касательно "поисковый индекс оказался не затронут". Думаю, тут вы ошибаетесь... Тот товар который утром попался мне под руку был создан в прошлом году, а редактировался в середине апреля. Могу ошибаться, но перестраивал индекс я, кажется, в самом конце апреля... Ну я к чему... Я к тому, что проблема-то не в том, что при каких=то ситуациях что-то не попадает в индекс... Мне кажется, есть ситуации, при которых индекс ломается напрочь. Смотрите, Мария и удаляла товары, и создавала - все без толку. Т.е. даже при создании товаров штатаным ручным способом (что я делал сегодня утром) новые позиции туда не добавлялись. Индекс мертв. Но вот что его умерщвляет - с этим будем пробовать разобраться. Я не впревые сталкиваюсь с такой ситуацией, что поиск не работает. Просто раньше я не акцентировал на этом внимание. А сейчас вот задумался.

Добавить ответ

Чтобы добавить комментарий, зарегистрируйтесь или войдите