1. «Код» категории с точки зрения системы это ее идентификатор. Идентификатор по своей сути должен быть уникальным (идентифицировать конкретную категорию). Эта логика ядра системы.

2. То, как этот идентификатор используется расширениями ядру не принципиально, если это «использование» не нарушает пправило из п.1

Поэтому вопрос о том, что «категории работают не правильно» здесь не правомерен.

На текущей «логике» ядра базируется функционал многих плагинов и самостоятельно править ядро, за счет внесения каких-либо правок него, равносильно стрельбе в собственную ногу. Делая так далеко вы не уйдете.

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

Теперь конкретнее, о задаче: за отображение «красивых путей» в адресной строке отвечает, например, плагин URLEditor. Соответственно менять «логику» надо именно в нем. Среди прочего он позволяет использовать для обработки URL пользовательские функции. Здесь на форуме уже не раз обсуждалась его работа и настройка.

В частности, здесь на сайте решена подобная задача, и используется для некоторых разделов. Суть аналогична тому, что предложил CrazyFreeMan. Коды категорий записаны с учетом иерархии.

Пример для раздеа «документация»: docs → docs_ext → docs_ext_themes. А за счет функции обработки в url мы видим путь docs/ext/themes/page_alias.

Если бы проверять пути то возможно это решение и затронет алиасы (дубликаты страниц) и не прийдется надеятся на CANONICAL URL

А при чем тут CANONICAL URL ?

Замена проверки путей вместо названия никак не затрагивает алиасы.

Возмем к примеру две разные реализации замены:

1. Меняем в таблице cot_pages-> page_cat на page_path.

В этом случае если нужно значение page_cat, то берем его не из cot_page -> page_cat, а из cot_structure -> structure_code

2. Не удаляем cot_pages - > page_cat, а добавляем cot_pages - > page_path.

В этом случае с алиасами вообще останется все как прежде.

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

К прмеру у меня так же стала задача сделать 3 категории и внутри их по 3 категории с одним названием категории но нельзя (проверка на уникальность)

Пришлось писать так parent-1 -> parent-1_sub1, parent-1_sub2, parent-1_sub3, parent-2 -> parent-2_sub1, parent-2_sub2, parent-2_sub3 и потом в своем коде парсить explode('_', $cat)  хотя читабельней структура parent_1 -> sub1, sub2, sub3  parent_2 -> sub1, sub2, sub3 Но тогда в базе для записей вместо категории нужно добавить/заменить путь и проверять его. Потому как не разобрать когда у страницы указана page_cat категория sub1 и sub1 а кто родитель не известно :) 

Думаю подумать нужно. 

В пятых, совершенно не принципиальный вопрос (проще говоря, хотелка), который решается изменением кода категории (УВ2 clinics/moscow на УВ1 clinics-moscow или УВ2 clinics/54895-moscow) и совершенно ни на что не влияющий.

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

#42625 Kort:

Не надо никаких иссей. Во-первых, из-за одного пожелания такие дела не делаются.

Просто не происходило до широкого обсуждения, тем более с знающими Cotonti людьми. Я выступаю с позици пользователя и удобства работы с системой. Пускай выскажится большая часть разработчиков. А кто тогда принимает решения по Issues?

#42625 Kort:

В третьих, никто не просчитывал последствий.

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

Во-первых, из-за одного пожелания такие дела не делаются.

.......

В пятых, совершенно не принципиальный вопрос (проще говоря, хотелка).

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

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

#42625 Kort:

Во-вторых, проверка кода проще, чем пути.

Да без разницы.

#42625 Kort:

В четвертых, это не глупость и не полнейшая.

Согласен - это не глупость, а идиотизм.

Создать пути и не использовать их, а делать проверку не пойми чего и зачем.

Как можно обойти это ограничение?

Действительно полнейшая глупость

Зачем проверять на одинаковые имена, когда надо проверять пути ?

Само по себе добавление структуры не сложно поправить.

В файле /system/structure.php найти:

$sql = $db->query("SELECT COUNT(*) FROM $db_structure WHERE structure_area=? AND structure_code=?", array($extension, $data['structure_code']));

и заменить скажем на:

$sql = $db->query("SELECT COUNT(*) FROM $db_structure WHERE structure_area=? AND structure_path=?", array($extension, $data['structure_code']));

Тогда можно будет разделы с одинаковыми именами создавать.

#42621 prostogorod:

И что черевато, если это сделать?

Вот тут все намного сложнее

Прилично править придется.

Причем не только вывод самой структуры, но и все что связано с самими страницами, т.к. они привязаны к structure_code, а надо чтоб было к structure_path.

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

Переменная structure_path в любом случае должна быть уникальная, так почему бы ее и не использовать ?

Видно раньше ктото схалтурил и вместо привязки к structure_path, привязал все к structure_code.

clinic/moskow
clinic/novgorod

agency/moskow
agency/novgorod

чтобы урлы были красивые и т.д.

А оказываеться ошибка категория с таким кодом уже существует...

Как можно обойти это ограничение? И что черевато, если это сделать?