Поиск товара по ID в бекенде и фронтенде

4

В последнем обновлении SS появился функционал поиска товара по ID в строке поиска по товарам в бекенде. Теперь при вводе ID товара он появляется в выпадающем списке - https://yadi.sk/i/9Y-kJX5hH4jM.... Однако если не кликать на товар в выпадающем списке и вместо этого перейти к результатам поиска (клавишей Enter), то в перечне товаров товар не показывается - https://yadi.sk/i/_rDhfmy0VxnV.... Менеджеры подтупливают. Также товар по-прежнему не ищется во фронтенде по ID - https://yadi.sk/i/5gvXyO2zZH-3....


Предлагаю:

1) Доработать функционал поиска товаров в бекенде: чтобы в перечень товаров в админке товар с точным вхождением по ID также добавлялся.

2) Доработать штатный функционал поиска товаров во фронтенде, чтобы в результаты поиска по товарам можно было включить (опционально) поиск товара по ID - https://yadi.sk/i/aRJiG_7DazAO....


По пункту 2: В идеале: чтобы была опция включения автоматического перехода к товару при точном соответствии ID товара запросу. Такая опция реализована в плагине "Поиск PRO", но по ряду причин, не связанных с данной темой, плагин "Поиск PRO" использовать не всегда уместно.

18 комментариев

  • +1

    Также есть дополнительно пожелание: если в бекенде при поиске товаров курсор стоит в строке поиска по товарам и в результате ввода запроса в выпадающем списке появляются ссылки на товары (https://yadi.sk/i/9Y-kJX5hH4jM...), то сейчас при попытке открыть товар с помощью клавиш "↓ + enter" осуществляется не переход к товару (как это было бы посредством клика ЛКМ), а вместо этого меняется поисковый запрос на название товара и загружается перечень товаров с результатами поиска по "новому запросу". Мелочь, но неудобно.

  • +2
    replicant replicant 8 января 2021 16:05 #

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




    У себя давно реализовал еще на 5 и 6 версиях поиск по ID во фронте, но результаты полевых испытаний поиска по малочисленным ID's не особо меня порадовали. Например мне надо найти ID = 78 и есс-но выдает массу из 1781, 478, 781-789 и т.п. Пришлось запрос в mysql подрезать, чтобы не лайкалось лишнего. Затем я это отключил и оставил только поиск по артикулам по точному совпадению от начала. Артикулы видно в бекенде в отличие от ID. Если чего-то не видно, то какого *** смысла по этому искать-то? Нужно же результаты поиска как-то быстро оценивать визуально. Бекендный поиск по артикулу не переделывал и оставил как он и был и результаты поиска по артикулу 412 на скриншоте (тут бы тоже камень кинуть), но в принципе не напрягает и пусть там лишнее выдается. Во всплывающей подсказке 2 товара, по Enter переходит на 4, т.к. запросы разные делаются в одном поисковом сеансе. Ох уж эти кодеры.

    Короче, если WA за это возьмутся, то косяков жди 100%. Всё страшнее и страшнее дальше обновляться. :)
    • +1

      А какой вообще практический смысл в поиске по ID во фронте...?

      • +2
        replicant replicant 8 января 2021 16:13 #

        Никакого. Просто было такое ещё со времен древних SS 3.09 кажись, а люди привыкли и просили реализовать в новом движке такое же. В итоге сами от идеи потом отказались, когда к артикулам привыкли т.к. артикулы видны в таблице товаров.

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

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

        Ищет по артикулам и названиям товара и прекрасно. Телепаты и ID товара видят сразу наверное. Им-то хорошо. А что делать остальным обычным людям? Например, артикул и/или название видят и покупатель и менеджер магазина, ну и дальше понятно уже что с этим делать.

        • +2

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

          • +3
            replicant replicant 8 января 2021 16:29 #

            Поддерживаю на все 100%. Идея странная. Первое, от чего я напрягся, это пересечение с поиском по артикулам. Коды артикулов же могут быть какие угодно и цифровые в том числе. Попадос!

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

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

          • +3
            replicant replicant 8 января 2021 16:51 #

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

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

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

          • +1


            А какой вообще практический смысл в поиске по ID во фронте...?

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

            - они могут быть неудобными (много символов, буквы, цифры. итп)

            - они могут (редко) повторяться у разных поставщиков для разных товаров 

            - артикул у товара может просто-напросто отсутствовать

            Поэтому вывод для пользователя ID товара под видом "Код товара" - нормальная практика. Он всегда есть, формируется автоматически, всегда состоит из цифр и покупателям удобно его называть менеджерам при возникновении каких-либо вопросов/проблем по товару.

            • +1

              Ну т.е. берется нечто и используется так, как захотелось, а потом под эти фантазии выдвигаются дополнительные требования. Штатная ситуация, в принципе-то...  95% монстрообразных неповоротливых систем строятся по такому принципу.

              • +1

                Во-первых, не "требование", а "предложение". Требования пишутся не на форумах, а в заявках в ЛК.

                А во-вторых, я не увидел от вас не единого весомого аргумента почему, по вашему, ID товара не стоит использовать в качестве кода товара, показываемого покупателю.

                Если бы в вебасисте в редактировании товара было 2 поля "Артикул магазина" и "Артикул поставщика" - я бы, возможно, с вами согласился, что мои действия выглядят нелогичными. Но в вебасисте есть только 1 поле "код артикула". И туда приходится выгружать артикул поставщика. Но что если он имеет такой вид: "AW363-359ku". А другой товар имеет артикул "AV363-359cy". Вы бы захотели показывать покупателю такие артикулы и просить называть их по телефону при наличии вопросов по товару?

                • +1
                  Vaslav Vaslav 9 января 2021 08:19 #

                  Ничто не мешает вам создать поле "Артикул поставщика".

                  А по поводу аргумента, почему использовать ID в качестве кода хуже, чем... любой другой вариант, всё очень просто: его нельзя редактировать в случае чего, что иногда может иметь значение.

                  • +1
                    replicant replicant 9 января 2021 09:29 #

                    Даже у одноартикульных товаров нет необходимости создавать второе поле. Оно там уже есть. Просто оно display:none в интерфейсе и всё. Легким движением руки и с помощью магии CSS все проблемы решаются сразу. Плагин есть для интерфейса, который это поле открывает меняя свойства элемента, но и до его появления многие сами поле открывали с помощью плагина Тонкой настройки или иным способом. Зачем это поле вообще надо было скрывать для меня до сих пор загадка.



                    Поиск товара в бекенде по-умолчанию и простой поиск на фронте ведется по трём полям.
                    1. Артикул (в оригинале Код артикула)
                    2. Код товара (в оригинале Наименование артикула)
                    3. Наименование товара
                    Примечание: Поля 1 и 2 можно использовать в произвольном порядке и другом качестве в зависимости от личных предпочтений. Для этого на модели своего проекта достаточно сделать пару тестовых прогонов с примером товара, чтобы понять как удобнее будет.

                    Результаты вот (на фронте будет аналогичная выдача)



                    Поиск по ID товара в такой реально существующей картине, по-моему, уже избыточен, если не будет отключаемым.
                  • +1

                    А по поводу аргумента, почему использовать ID в качестве кода хуже, чем... любой другой вариант, всё очень просто: его нельзя редактировать в случае чего, что иногда может иметь значение.

                    разве это проблема? Зачем редактировать код товара? В каких случаях у вас это имеет значение?

                  • +1
                    replicant replicant 8 января 2021 18:42 #

                    У меня одноартикульные товары и даже в таком сетапе можно жить. Артикул от поставщика, если он есть, забивается в код артикула (код товара на скрине). Артикул свой ставится в наименование артикула (просто Артикул) и выводится на фронт для людей в том числе как более простая сущность для чтения/запоминания. В бекенде видно оба значения сразу в таблице товаров. Иногда значения этих полей совпадают, когда нет кода от поставщика, а иногда отличаются.


                    Поиск по артикулам охватывает эти оба поля по-умолчанию.

                    Когда-то была мысль использовать ID как некую связующую сущность, но "не взлетело".

                    Даже, если Артикул совпадает с ID товара, то это просто так получилось. Никакой связанности тут нет, а если и делать их одинаковыми, то поиск по артикулу = поиску по ID. Значит в каком-то специальном поиске по ID уже и смысла нет, т.к. всё сведено сразу к артикулу равному ID ещё на подлёте.

                    Единственное для чего используются ID - это формирователь URL. Ко всем URL на конце добавляется автоматом ID как уникальный идентификатор, чтобы избежать повторяемости URL, т.к. часто транслитный автомат не подходит и пишем свое, например, skovoroda, а их там несколько, но автомат делает skovoroda-4156 и всё пучком. Человек заполняет только пространство между началом и концом URL.

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

                    Мне любопытно какую именно цель преследовали разработчики, прикручивая поиск по ID в последнем обновлении. Либо это часть будущего какого-то грандиозного плана, либо очередные грабли с обновленной поролоновой ручкой.

                    • +1
                      replicant replicant 8 января 2021 19:17 #

                      Как можно ждать чего-то хорошего от людей, которые поиск по форуму делят на три части, а на уровне кода движка запрещают покупателю в ЛК смотреть свой собственный комментарий к заказу. Конечно хорошего много делается, но местами прямо ***** слов не хватает.

                      Лучше бы баг с затиранием телефона зарегистрированного покупателя во всех сделанных заказах пофиксили.

                      Но мы ведь надеемся, что светлое будущее наступит. :))) Ладно. Время покажет. Посмотрим на этот поиск позднее под микроскопом.

                      Всем всего хорошего в этом чЯте. :)

                    • +3
                      Дмитрий Дмитрий 9 января 2021 11:10 #

                      Поиск по id однозначно не нужен. 

                      Если решать проблему подстановки артикула поставщика - то это должно быть отдельные поля. У большинства поставщиков свои внутренние артикулы. Соответственно у одного товара может быть три поставщика с своими артикулами. И да, может быть один заводской артикул - как артикул производителя. (а иногда например товар один и тот же, а заводских артикула два, но это более маловероятная ситуация.)

                      Решается это по сути полями характеристик. Нужен поставщик - сделали характеристику "поставщик1 - артикул1"

                      • +1

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

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


                        -----

                        Webasyst, поясните, для кого это обновление - https://yadi.sk/i/T0jZlLnLXMtc...?

                        Кто им будет пользоваться?

                        — Если для менеджеров - то функционала явно недостаточно.

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

                      • +1
                        marsianin marsianin 9 апреля 2021 23:34 #

                        Полностью согласен с автором темы с некоторыми оговорками.

                        Для начала нам нужно понять, для чего вообще нам нужен этот функционал?

                        Лично нам этот функционал нужен исключительно для удобства идентификации товаров при общении менеджеров с клиентами. 

                        Почему стандартное поле «артикул» нам не подходит для решения данной задачи? 

                        Если мы хотим пользоваться штатным импортом CSV, то для работы с прайсами поставщиков оно должно быть заполнено артикулом поставщика. Но дело в том, что артикулы у каждого поставщика разные и не всегда их удобно диктовать менеджеру по телефону - гораздо удобнее продиктовать цифры.

                        Какие у нас есть варианты в данном случае (вывести цифровые идентификаторы)?

                        1) вывести во фронтенде тот самый «id товара». И пользоваться добавленным недавно функционалом поиска товаров в бэкенде по id товара. 

                        У этого варианта есть 3 недостатка и этот вариант сразу отпадает: первый большой недостаток заключается в том, что для товаров, у которых значение id близится к 0 (например от 1 до 1000) есть большая вероятность, что такие же цифры будут встречаться где ни будь в описании товара и поиск будет некорректно отрабатывать. Например , если у товара id = 1, то такой поиск вероятно вообще не будет работать). Второй недостаток (поправимый) это то , что на текущий момент поиск фронтенда не ищет по id товара. Т е если возникает такой случай, когда менеджер хочет назвать клиенту id товара, для того что бы клиент мог найти его через поиск фронтенда, и не сможет этого сделать по той причине, что поиск фронтенда не ищет по id товара. Ну и третий недостаток это то , что не всех товаров этот код будет одинаковой длины.
                        2) Второй вариант: Его сейчас используем мы у себя в магазине. При любом сохранении карточки товара, плагин, купленный в магазине плагинов, записывает в штатное поле "Артикул"  сгенерированное в соответствии с настройками плагина значение. Например у нас этот шаблон такой $product_id + 100000. Т е для товара, с product_id = 1  , в поле "Артикул" запишется 100001. 

                        На текущий момент это рабочий вариант решения проблемы,  с одним недостатком: Поле Артикул будет занято этим кодом. Соответственно, артикул поставщика некуда вписывать. А значит и штатный импорт CSV невозможно использовать.


                        Лично я вижу 2 оптимальных способа решения данной проблемы:

                        1) поиск должен искать во фронтеде и бэкенде, но не по ID товара, а по заданному пользователем шаблону, который в свою очередь связан с тем же ID товара математической формулой. Например это ID товара + 100000 . В таком случае каждый магазин сможет настроить для себя код товара нужной длины, что бы эти значения не пересекались с какими либо другими цифрами в описании товара и поиск работал корректно. В идеале код товара должен однозначно идентифицировать товар.

                        Алгоритм работы поиска будет следующим: при вводе в строку поиска цифрового значения, скрипт пойдет по обратному пути и высчитает ID товара путем вычитания из вписанного в строку поиска значения тех самых добавленных 100000 (это значение можно будет изменить в настройках поиска). Если получится значение >0 то будет производиться поиск в БД по полю ID товара так же как это делается сейчас. Например, в нашем случает, если мы введем в строку поиска значение 100001 то алгоритм поиска сначала рассчитает ID товара (100001 - 100000). Рассчитанный ID товара будет = 1. И  в результаты поиска будет добавлен товар с id =1. 


                        2) второй вариант решения проблемы: создать отдельное штатное поле: код товара, в который можно будет вписать любой код вручную, и по этому полю будет искать поиск.

                        Из этих двух вариантов лично я выбрал бы первый, что бы не плодить кучу полей в бд.

                        Добавить комментарий

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