Под админом смотрите?

Эти условия и так стоят. Я вот только не помню, начиная с каких версий шестерки. Смотря какая версия 6 у Вас
Кстати, какой поиск имеется ввиду? Текстовый индексируемый, или фильтр-отбор по товарам?

Александра имеет ввиду, что 6.0 - это как бы поколение, а версия - это ещё несколько цифр после, типа 6.0.13.3 ;)

Лучше бы url дали, или хотя бы на сайте обвели этот поиск, так понятнее было бы

Дана подвал не ориентируйтесь )
В разделе "Обновления" видно точно, какая именно версия текущая

Ну вообще "найти" товары можно и текстом и через параметры )


Но я понял, текстовый.

Значит, смотрите, этот поиск - чисто текстовый, он не видит и не знает ничего, кроме текста (страницы сайта, названия всякие, товаров, новостей, и всякие параметры с текстом, ака описания товаров, строковые харакетристики и пр.). Галку "Нет в наличии" или цифру "Количество на сайте" этот поиск не видит. Соответственно, он не может никак понять, есть ли этот товар или нет. Он смотрит на строку поиска, сравнивает с таблицей индексов, видит, что есть совпадение и всё, выдает его в результаты поиска. То есть, оттуда выковырять отсутствующие товары теоретически можно, но так как поиск ищет по своей отдельной таблице, нужно прилично поизвращаться.
В таких случаях лучше либо в фильтр по товарам сделать текстовый поиск, убрав основной индексируемый, ну либо оставить как есть.

Ошибки логической тут по идее нет. Если Вы оставили отсутствующий товар на сайте, Вы это сделали не просто так же, вы хотите, чтобы его все видели с галкой "Нет в наличии" и оставили по нему заявку на ожидание, например. Соответственно, поиск его и выдал, с этой галкой. Покупателю всё видно, всем понятно, что товар такой был и может быть будет, но сейчас его нет, заказать нельзя.

Ведь лучше, когда по поиску какой-то фразы покупатель увидит товар, которого сейчас нет в наличии, чем он увидит строчку "Ничего не найдено". Хоть что-то, чем совсем ничего ;)

Совершенно верно. Это независимые "параметры": галка "Отсутствует" и "0 на складе".

Для системы товар считается отсутствующим и при галке и при остатке 0. Так что, если если регулировка наличия идёт по количеству, не надо галки ставить. Стало 0 = товар отсутствует на сайте. Появилось количество >0 = Товар автоматически стал в наличии

В стрессе и с вызовом нередко получается)) Это полезный навык 😁

На скриншоте надпись "Внимание, файл install.php не удален". Это говорит о том, что у системы прав нет на редактирование файлов. Не удалила install.php, не смогла заполнить config, распаковать demo.zip и т.д.
Иногда бывает, когда установщику вроде показывается, что права есть на управление файлами, но по факту нет. Попробуйте установить 777 на все файлы CMS на хостинге и проверить владельца файлов и группу, где-то может что-то не соответствует

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

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

А! И ещё бывает тупо квота дисковая, место кончилось и записать скрипты не могут ничего, т.к. ОС не даёт )

А, ну или так )
Но вообще да, это настройки конкретного сайта на хостинге, не прописаны по умолчанию директории для записи сессий. Точнее, это даже косячок хостинга, обычно "под ключ" хостинг все эти вещи должен учитывать по умолчанию. А самому всё прописывать приходится обычно когда чистый VPN покупаешь и там ставишь сам всё с нуля, апач, SQL, РНР и домены подключаешь в ручные папки сайтов

Деньги только вперёд возьми ))
Нам он не заплатил. Я убил по несколько часов в разные дни в течение пару недель в режиме "потом оплатим" и всё.
Так что пардон, этим я помогать не буду )

Ага, мебель-северик, я его разбирал на косточки в ТП )
Ребята, можете не гадать, не видя БД, никогда не догадаетесь, в чём там прикол )
Сергей близок )
Ростислав, я же говорил в поддержке обо всех занозах. В частности, там какой-то умник решил в таблицу значений доп.характеристики, которые смотрит фильтр (значения выпадающего списка) засунуть какие-то свои "поисковые индексы". Там 105.000 значений выпадающего списка 🥹

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

id там у строк почему шестизначные, если их всего несколько сотен? Просто нажали "Удалить" в таблице?


База товаров там совершенно невзрачная, тысяч 60 товаров. А вот таблицы характеристик используются совершенно неразумно и неправильно. Наша вина только в том, что мы позволяем создавать характеристику с выпадающим списком и затем позволяем туда заносить по 100К значений (см скрин). Ну если у тебя характеристика "Цвет" и там не 15 типовых значений, а все сочетания радуги от #000000 до #FFFFFF с миллионами значений, то не надо задавать тип "Выпадающий список", ну сделай ты текстовую характеристику... Потом мы видим в базе вот такое, как на скрине этого сайта и потом хоть усрись, но уже двойном-тройной джойн по нескольким милионным таблицам не будут работать за 0.001 секунды. И я не говорю про интерфейс фильтра в браузере, куда в выпадалки заезжали тысячи значений, офигеть как удобно фильтровать...

И если тоже не кидать камни в огород недобросовестных заказчиков и клиентов, а исключительно ради улучшений и справедливости ради, я на этот джойн тоже смотрел исподлобья, не совсем понимая его целесообразность, особенно в этом виде. В коробке, кстати, он чуть по-другому висел, но с каких пор и кто его туда так поставил, я не помню 🤷‍♂️ Надо будет его переделать.
Но это не решит проблему бездумного заполнения системы черти чем в неограниченном количестве.

Я извиняюсь, конечно, за некоторую несдержанность, но опирался исключительно на факты, которыми располагаю 😏 У нас с вами было несколько тикетов, несколько раз тикеты создавались как раз под оплату, и несколько раз и я намекал, и менеджер прямо говорил, что надо закрыть вопрос с оплатой проделанной работы, но все разы это как-то мягонько заминалось с Вашей стороны, создавались новые тикеты, мои рекомендации и решения опускались, и у меня создалось полное ощущение, что что-то идёт не так )

В любом случае, я считаю, что одна из главных проблем в разработке — это когда "к снаряду подходят" разные люди, и каждый не зная что зачем и почему изначально было сделано, пытается что-то наворотить сверху. Классическое письмо Дяди Федора родителям. То хвост отвалится, то усы жмут. 🤷‍♂️
Я настолько знаю, Вам изначально вообще делали какой-то кастомный импорт товаров от десятков разнородных поставщиков из xml, xls и csv напрямую в БД. Затем сверху этого было наделана куча фильтров, поисков и разборов. А потом ещё какие-то индексации кто-то сверху на базу приписал... Тут уж лучше всё-таки определиться с кем-то, кто будет стабильно сайт вести, дать ему полный карт-бланш и доделать уже всё по уму.
Если с Евгением eamat сработались, то это хорошо, он партнёр и разработчик опытный, всё получится )

По такой схеме работы заполнения проблем мы не встречали. Собственно, поэтому ничего и не документировали, т.к. не требуется.
Тут опирались только на здравый смысл: если мы говорим про характеристику с выпадалкой типа "Цвет" или "Размер одежды", где список из адекватного количества значений. Адекватное количество = то, что руками можно забить, глазами окинуть, затем в выпадалке удобно выбрать. Откройте любой магазин, Озон, М-Видео, фильтр любых товаров, там список в какой-нибудь характеристике для подбора товаров сколько галок? Ну 20, ну 30, ну 100 максимум. Больше если, это уже неудобно для скролла даже и выбора в браузере или с телефона. Так вот технически у нас в CMS нет проблем и для нескольких сотен в принципе
Проблемы есть, когда эти значения заносят не вручную, а напрямую в БД, недокументированно, и в выпадалке оказывается 100.000 значений. Это физически невозможно сделать, там просто виснет браузер, когда в админке грузится этот select/option1-option2-option3-option4-***-option9999999
Соответственно, ситуация тоже получается недокументированная 🤷‍♂️

Опять же! Я и Ростиславу говорил несколько раз и Евгения внимание хочу ещё раз обратить, что если мы имеем сотни-сотни тысяч и миллионы записей в нескольких разных таблицах, то как не крути, множественные запросы в БД чисто физически не смогут исполниться за доли секунды.

Вышеуказанные в теме запросы обрабатывают миллионы строк в цикле и 1.5 секунды - это адекватное время. Это нормально.
И как раз на такие случаи помимо кеширования (в котором всё быстрее 1.5 секунд) у нас в CMS есть прекрасный инструмент lazy. Добавляем параметр lazy=defer в тег show_search и всё, сайт открывается за 0.2 секунды и пока пару секунд подгружаются шрифты, баннеры и прочие картинки, 1.5 секунды совершенно незаметно фоном грузится и фильтр. Визуально сайт открывается как пуля.
Я не знаю, почему нужно из принципа сражаться , чтобы фильтр грузился в потоке основного источника html и тормозил всю страницу...

Уф... Понятно

👍 Но, опять же, проблему с кучей смысловых дублей это не решит, за исключением того, что на int можно индекс поставить. А вот если придумать инструмент, когда одному id значения характеристики можно соотносить кучу аналогичных "Круг", "Круглый", "Окружность" и при поиске они бы все выходили по одному id, это было прям хорошо. Но как это администрировать не понятно, и как изначально заносить и соотносить...
Это да, но за исключением случаев, когда кто-то хочет у каждого значения каждой характеристики фильтра иметь циферку "Сколько будет найдено товаров по этой галке". А у нас тот же Степан эту величину клянчил долго для своего фильтра, сам её везде совал, и вот она аукивается вот так на больших разнородных таблицах. Т.к. для вывода фильтра один шиш надо перебирать всю базу предварительно

TrackMax - это китайский бренд и шин и телефонов?

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

Да похоже на локалку, я тоже смотрю смотрю

У нас доступ ко всем файлам есть, конечно, но на бесплатном и тестовом шаблон править мы не всегда охотно бросаемся )
Там заголовок характеристики должен быть скорее всего, который не поставили, а двоеточие не убрали. Да, в шаблоне можно поправить

Дмитрий, не путайте как раз ещё методы обращения к БД и получаемые результаты ;)

Киньте глаз на документацию https://www.diafan.ru/dokument/full-manual/developers/includes/database/
Где начинается:

DB::query_result () - просто запрос и просто ответ в одну переменную, как его БД отдаст, обычно, когда нужно просто получить быстрый, точный конкретный результат при LIMIT 1, например, получить id или name
DB::query_fetch_array () - это будет уже массив, где поля БД - индексы массива, когда надо получить строку из БД
DB::query_fetch_all () - это будет двумерный массив, где будет куча строк из БД на первом уровне порядковые номера строк от 0,1,2,3 и пр, а в каждом элементе уже вторая вложенность с индексами из названия полей БД
DB::query_range_fetch_all - то же самое, что выше, но не все, а можно указывать range, типа limit 100, 100


То есть, не DB::query_result ;))))

Дальше! Вот так не надо:

Всегда указывайте маску (%s, %d, %h, %fи пр.) и выносите переменную за скобки. Так Вы от sqlinjection застрахуетесь, система за Вас всю фильтрацию сделает )
Как у Александры

НО! Александра, зачем маска %h? ))
%h - это для текстовых переменных без HTML, то есть, чтобы в передаваемой в запрос строковой переменной почистились всякие теги, если они есть. Эту маску нужно использовать, когда передается строка и там не было ничего кроме символов и цифр.
- например в таком запросе да, надо %H
А если у нас заведомо числовая переменная и числовое поле БД, то надо маску %d - digit, цифры

- вот так, тут кроме цифр ничего не пролезет

И ещё момент!
Поле name1 - здесь 1- это номер языковой версии для переводимого поля.
Если на сайте два языка, в таблице будет name1 и name2 в БД.
Если 3, будет name1, name2, name3 и т.д.
Мы же не будем отбирать каждый раз name1 или name3 для каждой версии?
Поэтому в запросах переводимые поля можно запрашивать просто в квадратных скобках: [name] и система автоматически подставит 1 (или иной индекс текущего языка в системе)

То есть, итого:

Рабочее-то рабочее, но фен-шуй лучше не злить ))

Бывает, ставят галку "Использовать email как логин", но продолжают вводить admin

Скорее просто совпадение, программистской связи никакой между этими событиями

Даже интересно)
Перекинь мне доступы посмотреть что там за магия

Ага, и то и то вывел
36М там в POST_MAX_SIZE