Yii2. Бесконечная глубина вложенности страниц

[Just_Skiv]

Ситуация такая. Имеется некая модель, назовём её Data. Каждый объект этой модели может иметь или не иметь родительский элемент (родитель тоже является экземпляром этой же модели). В итоге, мы можем получать сколь угодно длинные цепочки вида root->child1->child2->...->childN.

Требуется сделать так, что бы у каждого объекта $dataObject была своя страница, при чем url этой страницы должен содержать в себе всех родителей, то есть выглядеть примерно так: site.com/parent1/parent2/.../parentN/data_object. Как правильно это реализовать в UrlManager? Как правильно генерировать ссылки на такие страницы? (конечно же, action и view-файл у всех объектов предполагается общий, вне зависимости от уровня вложенности).

[Йож]

Обычно делают свой UrlRule:
http://www.yiiframework.com/doc-2.0/gui ... ting-rules

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

А распарсить урл можно с помощью регулярки, и весь полученный массив проверить на соответствие всех родителей.

Я так делал в интернет-магазине (правда для MaterializedPath дерева), но показалось замысловато и было несколько минусов такой реализации, в том числе лишняя нагрузка на базу при запросе и длинных урлов (что для SEO не особо хорошо).
В общем отказался в пользу более простых урлов.

[Just_Skiv]

...
было несколько минусов такой реализации, в том числе лишняя нагрузка на базу при запросе и длинных урлов (что для SEO не особо хорошо).
В общем отказался в пользу более простых урлов.

Спасибо за ответ. Думаю, дальше уже разберусь, просто не знал, каким способом это делать правильнее всего. Однако, последняя часть Вашего сообщения вызвала у меня вопрос (пригодится для общего развития) - чем это дело плохо для SEO и почему? Хотя бы вкратце.

[Йож]

Если вкратце:
1. У Гугла и Яндекса есть ограничение на максимальную длину урла. По многим источникам в СЕО сообществе урл не должен превышать 60 символов.
2. Короткое ЧПУ лучше длинного ЧПУ, т.к. транслитерация нужного запроса тоже учитывается в ранжировании, и чем длиннее урл, тем менее точное вхождение запроса получается.
3. При изменении slug (например, при изменении названия) для раздела будет изменены урлы для всех вложенных страниц, что ведет потерю всего ссылочно веса на старые урлы, даже если поставить 301 редирект на новые (это вообще отдельная песня).
4. Аналогично с перемещением товара из категории в категорию + имеют место дубли, если для товара указано несколько категорий.
5. Также существует внегласное правило у сеошников - чем короче урл - тем лучше (на эту тему можно долго холиварить), даже при учете, что транслит в урле влияет на ранжирование - это влияние сильно малО.
6. Если смотреть на то, что урл поможет в построении структуры сайта и страниц на нем, это не так - гораздо лучше помогут хлебные крошки с правильной микроразметкой, в том числе для использования в выдаче:

[Just_Skiv]

Большое спасибо, буду иметь в виду.

[Йож]

Жаль нет системы репутации на форуме, плюс бы Вам добавил

[Just_Skiv]

Её нет, но мне всё равно приятно

[Just_Skiv]

У меня появилась идейка, как уменьшить нагрузку на БД притаких урлах. Что, если я генерировать урл на этапе создания записи, и у каждой записи в БД будет сохранён свой урл, а меняться там он будет, например, при переименовании родителей и т.п. Конечно, если мы изменим название одного из корневых родителей, то придется менять урлы всем дочерним записям, которых может быть много, однако если такие действия будут происходить не часто, то это имеет смысл, на мой взгляд. Это уменьшит нагрузку на БД со стороны пользовательской части сайта.

Это решение выглядит адекватно? Или я что-то упустил?

[Loveorigami]

для этого есть кеширование

[Йож]

Я считаю, что это создание геморроя на ровном месте.
Либо кеширование, либо не обращать внимание на "лишнюю" нагрузку..

[Maxim Glushko]

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

Если уже очень хочется бесконечных урлов, создайте поле, где через запятую будут перечислены id всех родителей. И одним запросом всех родителей и повыбираете. Тоже с периодическим обновлением поля parent_ids кроном.

[Just_Skiv]

Вообще, эти урлы не обязательно будут такими уж длинными. Скорее всего, 3-4 уровня, не более. Имеет ли смысл заморачиваться тут с кэшированием, или "лишняя" нагрузка будет незначительная? Самих ссылок тоже будет не очень много (вряд ли больше десяти на страницу), да и сайт не особо большую нагрузку имеет.