Routování adres: ID vs. slug vs. jejich kombinace

Varianty 1 a 2 jsou snažší o to, že Ti nevznikne duplicitní URL, kterou budeš muset systémově vyřešit.

Dnes bude horko (takový článek vznikne každý rok v létě), takže jaká bude url?

dnes-bude-horko
dnes-bude-horko-1
dnes-bude-horko-<datum>
dnes-bude-horko-<random-string>

A varianta 3 je jak psal @nightfish a není na tom nic složitého, ale opět si musíš vyřešit možnou kolizi.

Ok, díky všem za odpovědi! Nějak jsem vždy všechno řešil přes ID, protože mi to pak přijde takové jistější (ID je prostě ID). Takže všechny action metody i odkazy v šablonách už mám nyní udělané tak, že to loaduje články přes ID (prostě klasika public function actionItem(int $id): void {}).

Ta cesta navržená od @nightfish je taky dobrá (mám to jako /clanky/, takže ok), ale kdybych chtěl mít slug jako hlavní identifikátor, musel bych teď přepsat podstatnou část aplikace… I toho důvodu bych se možná přikláněl k tomu pracovat s tím ID a slug na to mapovat až přes ten FILTER_IN/OUT (nebo i jinak, pokud by šlo)… Mě osobně to tak řešit nevadí, ale pořád vlastně nevím, jestli to nějak neovlivňuje tu rychlost…

Každopádně když už jde moje uvažování tímhle směrem, nakonec přijde nejpraktičtější, aby to fungovaly obě varianty 1 a 2, s tím, že 2 by byla kanonická. Jak byste v takovém případě řešili tvorbu odkazů? Je na to třeba použít ten FILTER_IN/OUT nebo by se na to dalo jít ještě nějak jinak?

Pavel Kravčík napsal(a):

Káčko to naznačil, poslední dobou se mi nejvíce líbí:

Router /clanek/<id>[/<slug>] → :Front:Article:detail a v presenteru se rozhodneš, jestli je slug povinný nebo ne.

Presenter public function actionDetail(int $id, ?string $slug) A článek hledáš jen dle ID, ale pro uživatele to vypadá docela hezky… teď jsem si všiml, že takhle to řeší Nette fórum. :) Tak asi není potřeba vysvětlovat víc, vyzkoušej si sám třeba ten slug změnit. Nebo změnit ID.

Tady bych to jen upravil, aby slug byl povinný a nemusí být zanesený ani v DB, může se generovat „on the fly“. Hledá se jen podle ID, slug tam je jen jako pozlátko pro hezčí URL a v detail článku, by se ale slug zkontrolovat měl, aby pak nevniklo to, co kdysi bylo na novinky.cz (nebo na nějakém takovém portálu).

/clanek/23543-dnes-bude-horko
=> /clanek/23543-ty-si-blb

a článek pořád fungoval ;-)

Slug nemusí být ani jako parametr v action metodě. Stačí na null parametr v routě aplikovat filtr a dle id dosadit do parametrů požadovaný slug. Pole se slugy bych ještě určitě uložil do keše aby se při tvorbě každého url nemuselo lozit do databáze.

m.brecher napsal(a):

Já to řeším tak, že pro články používám url ve tvaru /article/nejaky-titulek-clanku

slug /nejaky-titulek-clanku se odvodí z title článku (Nette\Utils\Strings::webalize()) .

Pole slug v tabulce article má nastaven unikátní klíč. Před uložením slugu nového/editovaného článku kontroluji zda již existuje a pokud ano, tak přidám číslo verze /article/nejaky-titulek-clanku-verze-1 a opakuji test zda url existuje, až se najde volné.

Článek se nevyhledá podle id, ale podle slug, je to obojí stejně rychlé, url neobsahuje nadbytečné informace, není potřeba v routeru používat FILTER_IN/OUT.

Složitější je, když se titulky článků editují – je potřeba zajistit, aby se staré url přesměrovalo http 301 na nové, tedy uchovat v databázi starý slug s odkazem na nový, tento problém ale existuje i když je url ve tvaru /article/123-nejaky-titulek-clanku.

Titulek článku se může editovat vícekrát a je potřeba uchovat všechny původní verze url, které přesměrovávají na poslední verzi.

Nemyslím, že použití id záznamu v url něco ulehčí, nebo zrychlí routování.

Právě že s použitím id záznamu v url je toto intuitivnější a nemusíš řešit různé verze slugu či dokonce uchovávat jejich historii. Ve FILTER_OUT jednoduše najdeš shodu dle id a do parametrů poté dosadíš onen slug, pokud je rozdílný či dokonce chybí, provede se přesměrování na aktuální verzi.

Jak vzpomenul @PavelKravčík, tuto logiku aplikuje i Nette fórum.

@m.brecher: Určitě to není antipattern. ;) Počet různých use-case se blíží nekonečnu. Tvůj způsob bude třeba hrozně user-unfriendly u projektu, kde nezáleží na SEO a často se mění název a nemá smysl držet historii slugů (nestojí to za to programovat).

m.brecher napsal(a):

Pavel Kravčík napsal(a):

@m.brecher: Určitě to není antipattern. ;) Počet různých use-case se blíží nekonečnu. Tvůj způsob bude třeba hrozně user-unfriendly u projektu, kde nezáleží na SEO a často se mění název a nemá smysl držet historii slugů (nestojí to za to programovat).

Ale jo, každý pattern má někdy výjimky, kdy se vyplatí ho nedodržet – u nenáročných webů se asi nevyplatí s tím rozlišováním 301/404 ztrácet čas.

Pár náhodných článků:

• https://forum.nette.org/…ch-kombinace (301)
• https://www.novinky.cz/…nek-40407004 (301)
• https://magazin.aktualne.cz/…c1f6b220ee8/ (302)
• https://www.zive.cz/…default.aspx (200)
• https://www.blesk.cz/…b-blesk.html (301)
• https://www.nbcnews.com/…ws-rcna44565 (200)
• https://www.dailymail.co.uk/…ilymail.html (301)

Během těch 3 minut, co jsem tomu teď věnoval, jsem narazil na 2 weby, které vracely 404 (bbc, theguardian). Ti ale mají jiný formát URL, takže to jinak ani nejde.

Tím ale neříkám, že by se měli věci dělat vždy podle toho, jak to mají ostatní. Spíš jen to, že řešit nějak moc 404 je tady možná zbytečné.

Editoval David Kudera (27. 8. 2022 18:33)

@mbrecher
Tebe ale ve výsledku bude zajímat co nabídne vyhledávač uživateli. Jedná se o kanonizaci, kterou framework v tomto případě řeší za tebe a díky tomu vyhledávač nezaindexuje všechny varianty, ale pouze tu jednu správnou (Přesměrování 301.), která se případně zobrazí ve vyhledávání.

A na tom, že někdo ručně zkusí změnit url a přesměruješ ho na ten správný tvar není nic špatného. Tebe přeci zajímá co a jak to vyhledávač zaindexuje, zkrátka se postarat o to, aby nedostal různé url s duplicitním obsahem.

Editoval Marek Znojil (27. 8. 2022 20:08)

@Bulldog

neexistující slug? Měl jsem na mysli takový slug, který nikdy na webu použit nebyl, ale přijde na něj http request – překlepem v prohlížeči, nebo v odkazu na jiném webu. Ano, pro realizaci nejhezčího url ve tvaru /clanky/slug je nutná doživotní archivace slugů. Plus implementovat např. tento algoritmus:

• všechny v historii webu použité slugy je potřeba do konce života webu archivovat:
  • state = moved + odkazem na nový slug
  • nebo state = deleted
• při vytváření nového slugu se nesmí použít starý, který se nepoužívá, ale je v archivu

  při duplicitě např. přidat nějaký rozlišující index

  nový slug označit state = active

a pak už je to jednoduché, článek hledáme ne podle id, ale podle slugu:

• slug nalezen, stat = active ⇒ 200
• slug nalezen, stat = moved ⇒ 301
• slug nalezen, stat = deleted ⇒ 404
• slug nenalezen ⇒ 404

Alternativně lze mazané články rovnou smazat a archivovat se nemusí, fungovat to bude stejně. Zrovna tak lze při mazání přesměrovaného článku mazat i existující staré verze, které na něj přesměrovávají.

V praxi se po publikaci nedělá moc často, že by se měnil titulek článku, nebo dokonce se měnil mnohokrát za sebou. Pak nevadí smazané/přesunuté články kterých bude pár kusů jednoduše ponechat v tabulce article, unikátní index nad sloupcem slug zajistí unicitu, není potřeba vytvářet samostatnou tabulku pro archivované slugy. Je to deset/dvacet řádků kódu a jeden pattern je splněn na 100%. A url vypadá jak má.

Důležité je, že volba id x slug nijak nevyžaduje použití komplikovaných filtrů FILTER_IN/OUT v Routeru jak původně uvažoval @koren . A to je téma diskuze. Mít Router jednoduchý a zvolit si verzi /clanky/id-slug nebo /clanky/slug.

@mystik díky za zajímavou informaci, korigovat případné překlepy v url a přesměrovat na správné je zajímavá myšlenka. V přesměrování všech neexistujících slugů na existující není z hlediska SEO asi žádný problém. Google nemá rád falešné 404, kdy se na všech neexistujících url místo korektní 404 zobrazí 200 s informací, že stránka již neexistuje. Toto doporučují někteří seo experti, protože si myslí, že se tím podaří zachytit traffic a page rank ze starých zpětných odkazů, které odkazují na již neexistující stránky. Je ale potom obtížnější hledat reálné chyby v odkazech přímo na webu.

Díky všem za plodnou diskuzi! Nejvíc zaujal návrh od @Michalek , protože to zní nejpoužitelněji a zároveň se nemusí nějak extra řešit ten slug (nicméně i tak tam je, což je fajn pro SEO)…

Nebyl bys tedy prosím tý dobroty a nerozepsal v krátkosti, jak přesně to máš udělaný? Tj. především jak vypadá:

1. action / render metoda
2. routovací funkce
3. generování odkazu v šabloně

Já nějaký nápady v hlavě mám, ale vypadá to, že už to máš promyšlený, tak budu rád za nasměrování ;) Samozřejmě čím víc info, tím líp, ale z věcí výše už to pak snad dál domyslím.

U toho generování odkazu v šabloně mě např. zajímá, jestli to umí generovat i odkaz přímo se slugem nebo ne (to si totiž dokážu představit jen pokud by router využíval FILTER)… Leda to tam pak šoupnout trochu punkově jako např. <a href="{link article, $article->id}-{$article->slug}">, ale to se mi zdá takový nepěkný :)

(btw. nápad se zkracovačem taky super!)

Editoval koren (1. 9. 2022 18:12)

Díky moc @Michalek ! :)

Navedlo mě k to vlastnímu řešení, kde skutečně není potřeba používat FILTER (a přesto se to chová tak, jak jsi popisoval)… Základem všeho zůstává směrování podle ID a slug je tam v podstatě jen taková ozdoba pro SEO… Pokud dojde ke změně slugu v DB, ničemu to nevadí, protože presenter to vždy přesměruje na ten aktuální…

Kdyby s tím tedy někdo taky časem zápasil, přikládám moje lehce osekaný řešení (ve výsledku je to mnohem jednodušší, než jsem čekal):

Router:

$router->withModule('Front')->addRoute('clanek/<id [0-9]+>[-<slug>]', [
	'presenter' => 'Article',
	'action' => 'item',
]);

Presenter:

public function actionItem(int $id = NULL, string $slug = NULL): void
{
	$article = $this->articles->getItem($id);
	if($article->slug != $slug) {
		$this->redirectPermanent('this', array('slug' => $article->slug));
	}
}

Šablona:

<a n:href="Article:item, id: $article->id, slug: $article->slug">

Jediný, nad čím přemýšlím, který to přesměrování při nesedícím slugu použít. S ohledem na SEO mi z toho ale intuitivně nejlíp vychází redirectPermanent, aby to jelo pomocí 301…

Editoval koren (9. 9. 2022 17:46)

@koren
Pokud bys nechtěl ‚otrocky‘ všude doplňovat slug při tvorbě url a zároveň ho dát pryč z action metody, můžeš zkusit použít toto:

$router->withModule('Front')->addRoute('clanek/<id>[-[<slug>]]', [
  'presenter' => 'Article',
  'action' => 'item',
  'id' => null,
  null => [
    Route::FILTER_OUT => function (array $params): array{
        $params['slug'] = null;  // výchozí hodnota slugu.

        // Zjištění správného slugu z databáze (keš).

        return $params;
    },
  ],
]);

Díky tomuto při tvorbě url ti stačí už pouze doplnit do parametrů id. Z action metody parametr slug taky zmizí, routa se o přesměrování postará.

@koren a @mystik V trvalém provozu použít pro přesměrování 301, ale při testování a ladění krátkodobě používat 302, protože prohlížeče 301 cachují, zatímco 302 ne.

koren napsal(a):

Jediný, nad čím přemýšlím, který to přesměrování při nesedícím slugu použít. S ohledem na SEO mi z toho ale intuitivně nejlíp vychází redirectPermanent, aby to jelo pomocí 301…

@koren
Tvoje řešení je super, ale pořád trošku složité. Presentery přesně pro tento případ mají metodu canonicalize takže tvůj kód by měl správně být takto:

public function actionItem(int $id = NULL, string $slug = NULL): void
{
	$article = $this->articles->getItem($id);
	$this->canonicalize('this', array('id' => $id, 'slug' => $article->slug));
}

Zbytek kódu stejný jak jsi popsal a ten if a redirect dělá metoda canonicalize interně

@koren
Ani s tvým řešením redirectPermanent by jsi tento link tag nemusel použít. Ten se používá v případě, že obě URL adresy jsou platné. Například, pokud máš stránky jak s www. na začátku, tak bez něj a na adrese https://domena.cz máš stejný obsah jako na adrese https://www.domena.cz pak se do hlavičky dá tento link tag, který vyhledávačům řekne, že o duplicitě obsahu víš a že chceš, aby braly v potaz jen jednu z těch URL a tedy aby nerozmělnily PageRank.

Někdo to používá třeba i pokud má vícejazyčný web, tak je tam vlastně totožný obsah jen v jiném jazyce, tak si pomocí link rel="canonical" zvolí jeden jazyk jako výchozí. Toto použití je sice sporné, ale proti gustu. :)

Tedy ne, pokud používáš redirectPermanent, canonicalize, nebo v routeru třeba $router::ONE_WAY, případně jiný 301 redirect, tak link rel="canonical" není potřeba. :)

Editoval Bulldog (10. 9. 2022 16:48)