Slug: использование ID vs "чистый" url

Темы, не касающиеся фреймворка, но относящиеся к программированию в целом.
Loveorigami
Сообщения: 977
Зарегистрирован: 2014.08.27, 21:54

Re: Slug: использование ID vs "чистый" url

Сообщение Loveorigami »

может бросил NotFoundHttpException ? откуда он появился там?
Ну да... Не правильно выразился.
замечу, что слаг в описанном варианте начинается сразу с корня, никаких shop
Без разницы. Alias, slug, id, productId, catalogSlug/productSlug.... - это все для UrlManager-a, чтобы построить урл.

Поэтому у меня в таблице редиректов хранятся не слаги (или др.). А старые -> новые урлы (упрощенно).


1. about-us -> about
2. shop/tv/samsunGGG -> shop/tv/samsung

зайдя по about-us - попадешь через 301 в about
зайдя по about-us123 - 404
зайдя по shop/tv/samsunGGG -> попадешь через 301 в shop/tv/samsung
зайдя по shop/tv/samsunG - 404
Loveorigami
Сообщения: 977
Зарегистрирован: 2014.08.27, 21:54

Re: Slug: использование ID vs "чистый" url

Сообщение Loveorigami »

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

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

Мое решение - поместить редирект в обработчике ошибок и делать запрос в редирект тогда, когда возникла эта самая ошибка (NotFoundHttpException - не найдена модель).

===========

Похоже, Вы ранее не решали таких задач. Поэтому и приводите ссылку на доку для создания url-правил.

Я вам привел код со своего проекта. Проект был изначально на Joomle. Переводили его на Yii2 со старой структурой адресов (region/alias) на новый вид (region-alias) + параметры.

Вышло порядка 30 000 старых адресов, которые были ранее проиндексированы, часть из них держались в топ-25 и топ-5. И все их нужно было структурно перевести и перенаправить на разные модули, контроллеры, экшены...

В общем, как напишите свою реализацию данной задачи, продолжим дискуссию ;)
yan
Сообщения: 942
Зарегистрирован: 2011.03.23, 09:28
Откуда: Уфа

Re: Slug: использование ID vs "чистый" url

Сообщение yan »

Loveorigami писал(а): 2018.07.30, 22:04 Похоже, Вы ранее не решали таких задач. Поэтому и приводите ссылку на доку для создания url-правил.
как раз таки много занимался подобными вещами, поэтому знаю о чем пишу, но смысла не вижу дальше дискутировать - не наша тут тема, пусть автор соображает, что ему нужнее
Последний раз редактировалось yan 2018.07.31, 00:32, всего редактировалось 1 раз.
GHopper
Сообщения: 83
Зарегистрирован: 2017.06.05, 10:53

Re: Slug: использование ID vs "чистый" url

Сообщение GHopper »

Читая ваши посты я больше думаю над возможностью избавиться от таких заморочек, нежели о конкретной реализации.
А что если запретить изменять слаг через два часа после создания артикла. За два часа не боты не проиндексируют и редакторы/клиенты на ошибки уже могут обратить внимание. На у а если все-таки накосячили, то новость в архив и создаем новую с праильным слагом. Старая какое-то время еще позапрашивается, но получив 404 все про нее забудут. Новая займет ее место, но это не точно.

Все-таки брак это скорее исключение, нежели правило, чтобы под него выделять отдельную таблицу в БД и писать специальные контроллеры.
Loveorigami
Сообщения: 977
Зарегистрирован: 2014.08.27, 21:54

Re: Slug: использование ID vs "чистый" url

Сообщение Loveorigami »

yan писал(а): 2018.07.30, 23:28
Loveorigami писал(а): 2018.07.30, 22:04 Похоже, Вы ранее не решали таких задач. Поэтому и приводите ссылку на доку для создания url-правил.
как раз таки много занимался подобными вещами, поэтому знаю о чем пишу, но смысла не вижу дальше дискутировать - не наша тут тема, пусть автор соображает, что ему нужнее
Без кода - это не более, чем просто слова.
Нужнее что? Вашего решения ни я, ни автор не увидели.

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

Речь шла не о нескольких контроллерах, которые генерируют слаги в первый уровень и обмениваются ими. А об одной сущности, которая поменяла слаг 4 раза
- была страница - site.ru/about-my-company
- через пол года сеошник поменял на site.ru/about-company
- через год компания стала корпорацией - site.ru/about-us
- через месяц сеошник поменял на site.ru/about

Все ЧЕТЫРЕ названия - это названия ОДНОЙ страницы. Никто никуда не мигрирует и не кочует.

ИТОГО -
- зайдя на about-my-company -> 301 -> about
- зайдя на about-company -> 301 -> about
- зайдя на about-us -> 301 -> about
- зайдя на about-123 -> 404
- зайдя на about -> 200
Читая ваши посты я больше думаю над возможностью избавиться от таких заморочек, нежели о конкретной реализации.
А что если запретить изменять слаг через два часа после создания артикла.
Тоже заморочка.
Написать круд для одной таблицы - дело 10 минут. (id, old_url, new_url, status = 301)
Обойдемся без поведения. Вручную, когда нужно сделать редирект, вносите в таблицу запись - откуда и куда.
И в обработчике ошибок - ловите исключение NotFoundHttpException и проверяете.

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

А теперь эти ссылки претерпели изменения. Причины бывают разные.
GHopper
Сообщения: 83
Зарегистрирован: 2017.06.05, 10:53

Re: Slug: использование ID vs "чистый" url

Сообщение GHopper »

Интересно, что StackOverflow, по видимому, использует слегка доработанный подход №2
Как я понял, у них реализована проверка на существование и если она проваливается, то редирект на существующий слаг. Таким образом, можно в любой момент менять слаги и ничего нигде не сохранять - всегда получишь редирект на актуальный, если <id> существует.
Ответить