SmartCJ Support Forum

вместо результатов поиска показывается индексная страница, сильно уменьшилось число релейтед видео, при заданных 20 стало 0-3

разобрался, короче выключайте вот это хуйню:
Search query filter pattern (regexp)
we use php preg-replace function to replace non-valid characters in user input
ie when a surfer searches on your site
a good pattern to start is
/[^\p{L}\p{N}\s]/u

нафига было дефолтом такую залупу там делать

не думаю что какой-то связано

какое например слово не проходит через этот фильтр?

Таже проблема вылезла на всех сайтах после обновления, победил её следующим патерном, может кому-то ещё поможет

Search query filter pattern (regexp):
/[^\pL\pN\s\-]/u

так это ж тоже самое только тире добавлено ..
или в чем разница? что именно не проходило а сейчас проходит и тп?

admin wrote: Mon Jan 26, 2026 4:33 pm так это ж тоже самое только тире добавлено ..
или в чем разница? что именно не проходило а сейчас проходит и тп?

Да, тире добавлено, но самое главное, что не проходили экранирующие кавычки для {L} и {N} , т.е. заработало только без них.

Что б простыню текста не писать тут, можете задать вопрос Gemini, он мне выдал несколько предположений, связаных со Смартом, но если эта у меня и у hrulik часный случай, значит можно проблему пропустить.

<?php

$search = 'test asdf 123';
echo preg_replace("/[^\p{L}\p{N}\s]/u", '', $search) . "\n";

echo preg_replace("/[^\pL\pN\s]/u", '', $search) . "\n";


я протестировал руками
поэтому и спрашиваю как конкретно проверить что б увидеть разницу

можно сюда скопировать предположения?

Как окончательно разобраться с «белым экраном»?

Поскольку у вас PHP 8.1, «белый экран» часто означает, что ошибка подавляется настройками. Попробуйте выполнить этот код, чтобы увидеть реальную причину падения (скорее всего, там будет Warning или Fatal касательно PCRE):

<?php
error_reporting(E_ALL);
ini_set('display_errors', 1);

$test = 'Привет World 123';
$res = preg_replace('/[^\p{L}\p{N}\s]/u', '', $test);

if ($res === null) {
echo "Ошибка PCRE: " . preg_last_error_msg();
} else {
echo "Результат: " . $res;
}
?>

Результат выполнения скрипта на моём сервере:
������ PCRE: Malformed UTF-8 characters, possibly incorrectly encoded

Gemini: А вот и «виновник» торжества! Ошибка "Malformed UTF-8 characters" означает, что регулярное выражение ожидает чистый UTF-8, но получает строку в другой кодировке (например, Windows-1251) или строку с «битыми» байтами.

/[^\pL\pN\s\-]/u - этот вариант хорошо работает сейчас, но мне очень интересно, почему не заработал у меня на сайте сразу первый вариант /[^\p{L}\p{N}\s]/u , т.к. мне скорее всего на много сайтах надо будет это менять, но возможно какой-то фикс сервера сразу решит проблему ?

Gemini: Это отличный вопрос. Если вы планируете масштабировать решение на много сайтов, важно понимать корень проблемы.

Тот факт, что \pL работает, а \p{L} вызывает «белый экран» (Fatal Error) на PHP 8.1, с вероятностью 99% указывает не на проблему сервера, а на особенности обработки строк внутри самого скрипта SmartCJ.

Вот технический разбор, почему это происходит:
1. Конфликт с интерполяцией переменных PHP

В PHP фигурные скобки {} внутри строк имеют специальное значение. Они используются для подстановки переменных. Например: echo "Hello {$name}";.

Если внутри кода SmartCJ (в его ядре) ваше регулярное выражение в какой-то момент попадает в двойные кавычки или проходит через функцию eval(), PHP может попытаться интерпретировать \p{L} как попытку обращения к переменной или константе L или сложной конструкции.

Как это видит PHP: «Ага, тут фигурная скобка {L}, наверное, программист хочет вставить сюда значение переменной, но я не понимаю какой, поэтому падаю в Fatal Error».

Вариант без скобок: \pL не похож на переменную, поэтому PHP воспринимает его просто как текст, и всё работает.

2. Специфический парсер настроек SmartCJ

Многие скрипты (SmartCJ, TDS системы) сохраняют настройки в базу, а потом достают их и "скармливают" функции preg_replace. Если SmartCJ использует свой внутренний санитайзер (очистку), он может считать фигурные скобки { } опасными символами (так как они используются для инъекции кода) и либо вырезать их, либо ломать структуру регулярного выражения перед выполнением.
3. Различия в библиотеках PCRE2 (менее вероятно)

На PHP 7.3+ (и особенно 8.1) используется библиотека PCRE2. Она более строгая. Если где-то в конфиге сервера или скрипта стоит "строгий режим" (JIT strictness), то синтаксис \p{L} может требовать экранирования скобок, то есть \p\{L\}, что очень неудобно.
Можно ли это исправить настройкой сервера?

Скорее всего, нет. Это не баг сервера (nginx/apache) или модуля PHP. Это конфликт синтаксиса внутри конкретного PHP-приложения (SmartCJ).

Чтобы заставить работать вариант с фигурными скобками \p{L}, вам пришлось бы лезть в исходный код SmartCJ (файлы ядра) и искать, где именно он подставляет вашу настройку в код, меняя кавычки или экранирование. Это долго, опасно (при обновлении слетит) и нерационально.
Лучшее решение для тиражирования

Для массового внедрения на сайты используйте именно вариант без фигурных скобок.

/[^\pL\pN\s\-]/u

Это официально поддерживаемый стандартный синтаксис регулярных выражений. Он:

Безопаснее: Не конфликтует с парсерами переменных PHP.

Универсальнее: Работает и на старых, и на новых версиях PCRE.

Короче: Меньше байт в конфиге.

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

я когда это читаю понимаю насколько надо разбираться в теме что б пользоваться LLM..

у вас сразу же написано в чем проблема - "Результат выполнения скрипта на моём сервере:
������ PCRE: Malformed UTF-8 characters, possibly incorrectly encoded

Gemini: А вот и «виновник» торжества! Ошибка "Malformed UTF-8 characters" означает, что регулярное выражение ожидает чистый UTF-8, но получает строку в другой кодировке (например, Windows-1251) или строку с «битыми» байтами."

те файл сохранен не в utf8, веротяно и страницы не в uft8 а сайт например на русском

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

логично или продолжим искать ошибку в смарте?


PS ну и что б совсем не из головы

https://www.php.net/manual/en/regexp.re ... nicode.php

где именно со скобками все и написано