Форум

Решил свою выше описаную проблему созданием второго правила обработки:
array(
"CONDITION" => "#^/news/([0-9a-zA-Z_-]+)/.*#",
"RULE" => "section_code=$1",
"ID" => "",
"PATH" => "/news/index.php",
),

Всё работает, но насколько правильный такой подход, можно задавать несколько правил для одного файла?

Думаю, что для настойки ЧПУ Битрикса нет особого смысла глубоко изучать PRCE (Perl-совместимые регулярные выражения) в части тонкостей обработки текстов и проблем там возникающих, и как их решать. А, достаточно ознакомиться с основами и со всевозможными примерами разбора url-адресов с помощью масок.

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

Думаю, что можно потому, что бывает лучше написать два-три понятных правила, чем объединить их через ИЛИ и сделать одно громоздкое непонятное правило, но на все случаи жизни, которое непонятно как потом менять. Но, нужно учитывать, что более длинное правило, если условие подходит, применяется первым в Битриксе, вроде как.

Тут в темах писали, если я правильно понял, что Битрикс сортирует все правила (условия) сначала по алфавиту и длинне так, чтобы применить более длинные правила первыми, как более частные, а короткие в следующую очередь, как более общие. Таким образом, более длинное правило для элемента ^/news/([0-9a-zA-Z_-]+)/([0-9]+)/.* попробует примениться первым и, если условие не подходит, то попробует примениться правило для раздела с ^/news/([0-9a-zA-Z_-]+)/.*

Имею, ввиду, что в случае, если будет написано одно и тоже разными способами, нужно исходить из длинны правила, и писать всё единообразно для страницы детального  и страницы просмотра раздела. Например, думаю, что из двух правил для раздела и детального просмотра, имеющих условия ^/news/([0-9a-zA-Z_-]+)/.* и ^/news/([\w-]+)/([\d]+)/.* не понятно, какое из правил сработает первым, как они будут отсортированы автоматически. Возможно, что до страницы детального просмотра дело не дойдёт, поскольку длинна обоих правил 26 символов и оба начинаются с /news/, то правило для раздела будет применяться чаще (или всегда?) первым.

Получается, если правило для детального просмотра элемента написано ^/news/([\w-]+)/([\d]+)/.* то и правило для просмотра раздела нужно писать аналогично ^/news/([\w-]+)/.* чтобы правила не перемешивались при автоматической сортировке, а по длинне первым пробовало примениться более длинное правило.
Или уж, писать для просмотра элемента ^/news/([0-9a-zA-Z_-]+)/([0-9]+)/.* тогда и для раздела ^/news/([0-9a-zA-Z_-]+)/.* т.е. придерживаться единообразия внутри раздела, как я понимаю важнее, чем стараться сократить количество самих правил за счёт использования ИЛИ в условии и непредсказуемо удлиняя их, сбивая сортировку правил.

Да, вы верно поняли. Только один момент уточню, что соритровка условий производится при изменении их через админчасть, в том числе и когда добавляется через визредактор компонент с ЧПУ. Короче, если битрикс добавляет/изменяет ЧПУ-правило, то он производит также и сортировку всего массива ЧПУ-правил по длине условия (CONDITION) от большего к меньшему. А уже непосредственно при обработке ЧПУ-запроса просто перебирается массив правил из /urlrewrite.php в той последовательности, в которой они там находятся. И поиск длится до первого совпадения.
Т.е. если вы вручную изменили массив ЧПУ-правил в /urlrewrite.php и разместили запись с условием "#^/news/([0-9a-zA-Z_-]+)/.*#" выше #^/news/([0-9a-zA-Z_-]+)/([0-9]+)/.*#, то до второго условия дело никогда не дойдет.

Не работает, т.к. у вас наверно физически существует файл /statiy/detail.php? Т.е. до обработки адреса ЧПУ дело не доходит вовсе.