CMS Made Simple Forums

Видимо не решена. А в чем заключается проблема?

ZYV wrote: Видимо не решена. А в чем заключается проблема?

Проблема одинаковых имен алиасов страниц.
Вот такое работать не будет:
/about/history/
/company/history/

Система не даст создать второй раздел history, мотивируя тем, что такой алиас уже существует.
Если структура сайта довольно большая, проблематично каждый раз выдумывать новый алиас

Ну так уж маршрутизатор работает - страницы идентифицируются по уникальному слову, а не по пути, которого, кстати, может и не быть, если use_hierarchy = false. В ветке 1.x точно не будет изменений - в 2.x - не знаю, надо это обсудить с разработчиками, какие у них планы по переписыванию маршрутизатора, но у меня на это времени нет.

ZYV wrote: Ну так уж маршрутизатор работает - страницы идентифицируются по уникальному слову, а не по пути, которого, кстати, может и не быть, если use_hierarchy = false. В ветке 1.x точно не будет изменений - в 2.x - не знаю, надо это обсудить с разработчиками, какие у них планы по переписыванию маршрутизатора, но у меня на это времени нет.

По сути, из пути по сайту можно вычислить страницу, почему бы не использовать это, ведь метод очень простой

strict wrote: По сути, из пути по сайту можно вычислить страницу, почему бы не использовать это, ведь метод очень простой

Если посмотришь код - там не из пути вычисляется страница, а только из его окончания - тоесть фактически из того-же альяса... Остальное - это пустышка... Попробуй у себя: создай станицу about, а дальше вводи: asdsad/about/ asdasdas/xcvxcvxcv/about/ ну и так далее

Правда защиту от этого уже выкладывала Sonya.

von-hamster wrote:

strict wrote: По сути, из пути по сайту можно вычислить страницу, почему бы не использовать это, ведь метод очень простой

Если посмотришь код - там не из пути вычисляется страница, а только из его окончания - тоесть фактически из того-же альяса... Остальное - это пустышка... Попробуй у себя: создай станицу about, а дальше вводи: asdsad/about/ asdasdas/xcvxcvxcv/about/ ну и так далее

Правда защиту от этого уже выкладывала Sonya.

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

strict wrote: Так нужно всего-навсего изменить систему опознания -- брать не последний объект, а всю цепочку пошагово и вычислять принадлежность.

Это не так просто. И будет нагружать систему... Для 2-3 десятков вычислить в реальном времени принадлежность - просто, а если страниц 2-3 сотни, да еще 5-6 уровней вложености? Плюс индекс построить по альясу выгоднее, чем по цепочке... К тому-же в этом случае нужно переделывать распознавание, в случае отключенных ЧПУ.

von-hamster wrote:

strict wrote: Так нужно всего-навсего изменить систему опознания -- брать не последний объект, а всю цепочку пошагово и вычислять принадлежность.

Это не так просто. И будет нагружать систему... Для 2-3 десятков вычислить в реальном времени принадлежность - просто, а если страниц 2-3 сотни, да еще 5-6 уровней вложености? Плюс индекс построить по альясу выгоднее, чем по цепочке... К тому-же в этом случае нужно переделывать распознавание, в случае отключенных ЧПУ.

Включенные ЧПУ должны быть по-умолчанию
Имея опыт сайтов с посещаемостью несколько тысяч в день и уровнем вложенности до 7-9, могу сказать, что не нагружает сервер подобная схема.

Это смотря как реализовать... Как ты предложил (если я правильно понял) - это нужно разбить путь, сделать 1 + n запросов, где n - уровень вложености (тоесть, запрашивать информацию о родителях, пока они есть, начиная с последнего или начиная с первого запрашивать потомков с текущим альясом). 7-9 дополнительных запросов в БД для высокопосещаемого сайта - не айс

Конечно, кэширование спасает...

В данном случае решить эту проблеему можно или через разработчиков (если они решат, что это необходимо), либо самому писать хаки..

von-hamster wrote: Это смотря как реализовать... Как ты предложил (если я правильно понял) - это нужно разбить путь, сделать 1 + n запросов, где n - уровень вложености (тоесть, запрашивать информацию о родителях, пока они есть, начиная с последнего или начиная с первого запрашивать потомков с текущим альясом). 7-9 дополнительных запросов в БД для высокопосещаемого сайта - не айс

Конечно, кэширование спасает...

В данном случае решить эту проблеему можно или через разработчиков (если они решат, что это необходимо), либо самому писать хаки..

Метод определения зависит от того, как организаваны в базе отношения "родитель-ребенок".
Если это классическая схема с двумя колонками
id    parent_id
то можно попробовать взять все одним списком и сортировать средствами пхп.
Либо сделать нормальную логику, где айди имеют определенную кратность, показывающую уровень вложенности.
К примеру, делаем один уровень, кратный пяти цифрам, тогда:
id                      title
00001                about
0000100001      history
0000100002      management
00002                services
0000200001      personal
0000200002      corporate
0000200003      other

Т.е. мы, имея айди 0000100001, видим, что это 2-й уровень вложенности, плюс, родитель для него -- пункт с айди 00001 (отрезав 5 последний цифр).
И головная боль проходит 

Как в этом случае, имея адрес  about/history определяеся что он 0000100001?

von-hamster wrote: Как в этом случае, имея адрес  about/history определяеся что он 0000100001?

Пардон, пересмотрев свои писульки, понял, что у меня тоже рекурсия
Но, тем не менее, такой метод позволяет определять родителей / детей дальше соседнего уровня, что несомненный плюс.

В любом случае, как я тебе ответил, это упирается в переписку рутера с возможной реорганизацией БД. В ветке 1.х это НЕ будет сделано. Если у тебя есть время и желание этим заниматься - обсуди с разрабами по теме 2.x, предложи концепты и т.п. Всё вокруг люди адекватные, если возьмешься грамотно сделать к тебе прислушаются.

Есть такое замечательное поле в таблице cms_content - называется hierarchy path. Я его часто в хаках использую. В этом поле весь путь в алиасах задан. Берем оттуда значение и разбиваем на array
Количество родителей (уровень вложеннности): count($pedigree)
Родитель первого уровня: $pedigree[0]
Прямой родитель: $pedigree[count($pedigree) -1]

Помогите разобраться с чпу. Установил сайт на nichost.ру сделал все как положено но сайт отказывается работать с правильными урлами хоть они и стали правильными. Все пересмотрел, ошибки допустить не мог, потому как неделю назад когда делал другой сайт все получилось. Помогите! p.s. это может быть из-за хостинга?