А в настройках модуля поиск пробовали менять критерии поиска? Количество символов, строгость соответствия и т.д.?

Это не всегда, но помогает.

Данные разнятся в 30-60 раз. Кто про что? 3-5 секунд задержка всегда была. Даже тут на форуме. Иногда сразу ответ публикуется, а иногда только через 5 секунд.

Да, можно нажать повторно, потому как непонятно. Но в новых версиях CMS при отправке формы добавляется параметр disabled. Можно в качестве одного из вариантов попроще поставить на него оформление:
На старых версиях надо disabled самому добавлять. В случае Максима действительно речь о минутах, а не о секундах. Скорее всего тут идёт какой-то запрос и не приходит ответ. Смотрите action.php модуля. Вся обработка там. И JS-файлы модуля - тоже. Там обработка ajax.

Я так понимаю, в логах в этом случае можно посмотреть информацию по ошибкам.

Конечно может. Вы email-уведомления отключали, чтобы CMS письма не пыталась отсылать? Проверяли как без этого работает? Логи на стороне сервера смотрели?

Система-то работает. Она же отправляет данные и ответ возвращает. Проблема только во времени. Значит скорее всего циклически повторяется какое-то действие или запрос. И на это действие не приходит ответ. Это может быть запрос соединения, попытка отправки данных на другой сервер и т.д..

Как вариант - развернуть копию сайта на локалке и посмотреть как на локальной машине будет отправляться. Чтобы проблемы с сервером исключить.

В поддержке много таких обращений. Как правило, после корректной настройки SMTP-аутентификации у всех всё работает. Если не работает, то чаще всего либо протокол не указывают, либо порт не тот.

Дополню, что в примере используется cookie. В "коробке" ссылка на скрипт, обрабатывающий куки через Jquery, есть. Но по-умолчанию доступен только для пользователей категории администраторы. Поэтому можно файл /themes/functions/show_js.php вынести в кастомную тему и уже в нём подключение скрипта вынести за рамки условия (строка 53): сделав вот так:Тогда код, представленный выше, будет работать в полном объёме, запоминая выбор пользователя.

Гарик дополнил про обновления (важное замечание). Да, когда-нибудь /themes/functions/show_js.php может и обновиться. И Вы при такой реализации не получите обновлений. Файл будет, но приоритет будет получать файл в /custom. Поэтому лучше подключать эту библиотеку всё же отдельно в шаблонах до файла со скриптом, написанным выше.или способом, который советует ниже Гарик.

А никто ж не продаёт. Просто спросил. И с передачей дешевле 6K захочешь - не купишь. Разве что Михаил в меценаты заделался.

Точка с запятой - это разделитель характеристик, | - разделитель параметров характеристик. Также может присутствовать дополнительный разделитель внутри каждого параметра, например alt и title у импортируемых изображений.

; и | идут по умолчнанию. Остальные зависят от настроек в описании импорта. Так что разделителей может быть вообще несколько, например:

... ; image_1 | image_2 | image_3 & alt & title ; ...

Добавим, когда я до неё доберусь.

Ну я бы не сказал, что это совсем не задокументировано Аннотации по месту читайте, там много интересного. Например, сообщается, что для редиректов можно также указать код редиректа (не только 301).

; и | используются по-умолчанию в файлах экспорта. Поэтолму в качестве доп.разделителей их использовать нельзя. Я обычно & использую.

По поводу отчёта - смысла сообщать что 300 загружено нет, т.к. будет загружено всё содержимое файла. Если будут ошибки, система о них сообщит (перечислит проблемные). Так что это уже есть.

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



Я планирую проработать этот момент, чтобы оставался минимум информации по позиции, которая вызвала проблему.

Тогда отчёт об ошибках импорта будет доходчивым и компактным. Плюс сам раздел импорта будет дорабатываться. Сейчас, например, нельзя скопировать рабочее и настроенное описание импорта, чтобы использовать его в качестве "рыбы". И в загружаемом файле нужно чётко отслеживать последовательность полей (столбцов). Это тоже на повестке. Мысли сделать так, как на скриншоте ниже.

Зависит от настроек. Основной момент - будет ли совпадение и если, да, то что тогда делать. Настройки тут:



Установите на локальный сервер CMS, укажите опцию с заполнением товарами при установке. Удалите все категории, кроме двух, в них оставьте по 3 товара в каждой.

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

Через час будете знать больше, чем знают разработчики.

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

Такого, конечно, не планируется. Но возможность вручную быстро определить порядок следования характеристик в импортируемом файле может существенно сэкономить время. Представьте, Вам партнёр (сеть какая-нибудь) даёт свой файл с базой товаров, в котором 50000 позиций. Характеристик десятка по 3 на позицию. Вот всё это переваривать, переставлять местами в файле, который и редактор таблиц "повесить" может. Это геморрой.

Поэтому пока на стадии обсуждения, но в перспективе инструмент, представленный на скрине выше. Т.е. из файла можно будет скопировать шапку, сам его не редактируя, подогнать в CMS описание импорта под него и потом импортировать, указав только нужные параметры (столбцы) в произвольном порядке без соблюдения их очерёдности.

Если другой производитель пришлёт другой файл с другим порядком следования параметров и несколькими лишними параметрами, то ничего править не придётся.

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

Мы этот процесс на лето запланировали. Посмотрим как пройдёт.

Мы просматриваем, программисты - нет. Мы только передать можем. Но тут какой смысл передавать, если Вы уже в вишлисте запостили ошибку 23 числа. Её сразу на карандаш взяли, она серьёзная.

Это становится традицией на форуме. Написать в ТП, получить ответ, содействие и т.п. в течение 2-5 дней, скажем. Потом прийти на форум и написать что ничего никто не решает, ТП помочь отказывается, вопрос уже 2 недели висит и т.д.. При этом 1000 раз уже говорилось, что программисты форум не читают, только вишлист, им некогда.

Romaromk, cитуацию в ТП Вы изложили по существу 30-го числа, сегодня. В вишлисте Ваше обращение учтено, у него статус обрабатывается. Исправление будет в ближайшем обновлении.
Откуда этот пессимизм и громкие упданические высказывания в стиле жёлтой прессы? Позитивнее нужно быть.

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

Сейчас всё собирается в архив с очередной версией комплексно и заливается в ЛК. Процесс автоматизирован, поэтому за 5 минут его не поменять. Но мы изменим его в ближайшем будущем.

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

Может кому интересно будет, откуда ноги растутНичего подобного. Смотрите в ракурсе проблемы. Запросите https://p.fast.ulmart.ru/p/gen/346 - получите 301 редирект.



Ещё на заре сайтостроения, когда у всех были модемы и всё было дико медленное и не было никаких CMS, часто советовали указывать в URL, указывающих на папки, слеш на конце. Потому что при этом сервер сразу понимал, что там каталог, а не файл и становилось одной проверкой меньше. Экономилось несколько миллисекунд.

По запросу выше apache получает ссылку без слеша, проверяет каталог-не-каталог и понимает, что каталог. Соответственно, как учили, ставит слеш и с 301-ым редиректом отправляет дальше.

В Вашем случае URL передаётся в CMS. Она смотрит на настройки, там пусто. Срезает слеш, тоже, как учили. И понеслось ERR_TOO_MANY_REDIRECTS.



Чтобы они не бодались, надо кому-то одному запретить проявлять инициативу. После обновления (которое выйдет) CMS будет принимать от сервера результат без инициатив. Сейчас при любой настройке этого параметра все URL воспринимаются системой как страницы (это же написано в аннотации к настройке). И при указании окончания как .php получится аналогичная картина, только без срезки слеша, поэтому редирект не зациклит.



После обновления CMS будет принимать результат от сервера с поправками и не будет обрабатывать ссылки на каталоги (т.е. будет чёткое разделение каталог/файл). Будет вот так:



Т.е. будет как на первом скриншоте, что является нормальной ситуацией. Будет один 301-ый редирект, но не будет зацикливания. В том случае, если ссылка на каталог будет без слеша на конце.

Если будет со слешем, то редиректа не будет.

Кстати, посмотрел статистику у себя. Тоже присутствует папка /userfls в индексе. С подпапкой изображений, доступных в каталоге.



Они могут и должны индексироваться - это часть контента, попадающая среди прочего и в Яндекс-картинки. Так что тут только И это не полумера, а единственно верное решение избежать индексации каталога.

Я что-то фразу недопонял. Это баг Яндекса или что? Ссылка есть на новость про это или иную информацию?

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

Теперь его надо редактировать, убирая всё ненужное.

Про rows_rel.php соглашусь.

Всем желающим опробовать или уже использующим модуль, советую чрезмерно сильно не увлекаться и учитывать такой параметр как "краулинговый бюджет".
На форуме не так давно высказывали обеспокоенность в связи с индексацией ссылок вида ...cart/?... и тратой этого самого бюджета.

Всё бы ничего, однако, на прошедшей конференции в своём докладе Дмитрий Шевцов разобрал конкретный случай одного из своих клиентов, у которого фильтр товаров с возможностью множественного выбора создавал аналогичные страницы.

Он привёл сравнительную таблицу, в которой увеличение числа параметров товаров, участвующих в генерации, на несколько единиц вызывало многократное увеличение числа сгенерированных страниц, счёт которым переходил с тысяч на миллионы и рос по экспоненте. Результат он также продемонстрировал - снижение общего числа страниц в индексе в 4 раза. Оптимальной Шевцов (по его мнению) назвал цифру ~3500 страниц в индексе.

Считаю, что к этому стоит как минимум прислушаться и иметь ввиду. Всё конечно зависит от величины проекта и массы других моментов. Но тем не менее.

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

Фильтр выводится, например, на странице тегов (https://мужскойвыбор.рф/tags/t-obraznye-stanki/). Или на странице производителей (https://мужскойвыбор.рф/shop/fatip/). Это не всегда нужно. Можно добавить возможность убирать фильтр там, где он не нужен.

И Вас! А также и всех остальных посетителей форума!

Всем удачи в новом году!

Степан, на всякий случай напомню Вам хорошую поговорку: "Лучшее - враг хорошего". Остановитесь!

Всё, что можно менять вручную, находится в доп.параметрах страниц. Всё остальное формируется автоматически.

Ольга, в разделе "Обновление CMS" проверьте наличие свежих обновлений. Если обновление доступно, попробуйте обновить CMS.

Перед обновлением обязательно сделайте бэкап сайта на всякий случай, очистите корзину в админ-панели (если там что-то есть), в параметрах сайта очистите и отключите кэш.

После обновления в разделе админ-панели "Модули и БД" > "Восстановление БД" запустите проверку базы данных.