Dynamiske CMS-links: hvorfor dit 'Link'-felt er en tidsbombe

En tirsdag morgen omdøber en marketing-medarbejder en kampagneside i CMS'et. De ændrer /kampagner/forar-2024 til /kampagner/forar-launch. Tre nav-punkter, to forsidekort og en betalt ads-landingsside peger nu på en 404. Ingen opdager det i elleve dage. Betalt trafik blev ved med at ankomme hele tiden.

Det er ikke en forfatterfejl. Det er en modelfejl. CMS'et gav dem et tekstfelt og en fodgun.

I den gennemsnitlige CMS-opsætning er "link til en anden side" implementeret som et string-felt. Forfatteren forventes at huske URL'en, taste eller indsætte den korrekt, og opdatere hver reference i hånden, hvis den nogensinde ændrer sig.

Der er ingen validering af, at URL'en eksisterer. Ingen advarsel, hvis målet er upublished, slettet eller flyttet. Ingen måde for CMS'et at fortælle dig seks måneder senere: "disse 47 steder linker til en side, der ikke længere eksisterer." Bureauet, der byggede det, leverede til tiden. Omkostningen blev udskudt til forfatteren og til din trafik.

Det kræver ikke et redesign for at bryde sammen. De daglige operationer i et content-team bryder det:

• Slug-ændringer. SEO omdøber en side af keyword-grunde. Hvert tekstfelt-link, der pegede på den gamle slug, brækker.
• Locale-varianter. Den engelske forfatter taster /about. Den danske version er /da/om-os. Halvdelen af de lokaliserede sider linker ud af locale.
• Forælder/barn-flytninger. En side flyttes under en ny forælder. Dens fulde sti ændrer sig. Hvert link til den er nu forkert.
• Sletninger og unpublish. En side tages ned. Hvert tekst-link til den peger på en 404 for evigt.
• Domæne- eller scheme-ændringer. Trailing slashes, http vs. https, www vs. apex. Vælg en URL-detalje og find den forfatter, der tastede den anderledes.

Stop med at gemme URL'er. Gem en reference til den entry, forfatteren vil linke til, og beregn URL'en fra entryen. Linkfeltet på hver indholdstype bliver:

• En reference til en Page-entry (eller hvilke entry-typer der nu er linkbare).
• En valgfri override-label, så forfattere kan sige "link til denne side, men kald den 'Læs historien'."
• En valgfri anchor til in-page-jumps.

Forfatteren behøver ikke længere kende URL'er. De søger på sidetitel, vælger entryen, og systemet garanterer, at linket vil resolve, så længe siden eksisterer.

Den anden halvdel af løsningen er at modellere navigationshierarkiet i selve CMS'et. I de fleste opsætninger lever URL'en for en side tre steder: et slug-felt, en redaktørs hukommelse, og en hånd-vedligeholdt navigationsmenu. Tre kilder, ingen enighed.

Modellen, der holder:

• Ét felt på siden: slug-segmentet for kun den side (fx forar-launch, ikke den fulde sti).
• Et self-reference-felt: forælder, der peger på siden ovenover i træet.
• En beregnet fuld sti, afledt ved at gennemløbe fra siden til roden og samle slug-segmenterne.
• Navigationsmenuen genereres fra dette træ, vedligeholdes ikke i hånden.

Når en side flyttes under en ny forælder, opdateres hver URL under den. Hvert reference-link til den fortsætter med at resolve, fordi referencer gemmer entry-ID'er, ikke stier.

Mønsteret nedenfor er den præcise model, jeg nu bruger på hvert Contentful-projekt. Den er lille. Den er forskellen mellem et CMS, der ældes godt, og et, der forfalder til en kirkegård af brudte links.

title: Symbol            // krævet, indekseret
slug:  Symbol            // krævet, kun segment ("forar-launch")
parent: Link<Entry<Page>> // valgfri, self-reference
locale: Symbol           // krævet (en, da, ...)
sections: Array<Link<Entry<Section>>>
seo:    Link<Entry<Seo>>

// Validering:
//  - slug er unik blandt sider med samme forælder + locale
//  - forælderen skal være af typen Page og samme locale
//  - cycle-check: en side kan ikke være sin egen forfader

page:   Link<Entry<Page>> // krævet
label:  Symbol            // valgfri override
anchor: Symbol            // valgfri, fx "pricing"
rel:    Symbol            // valgfri, fx "nofollow"

// Eksterne links er en separat type (ExternalLink),
// så modellen selv forhindrer, at man taster en URL i et felt,
// der skulle være internt.

type PageRef = { sys: { id: string }; fields: { slug: string; parent?: PageRef; locale: string } }

export function resolvePath(page: PageRef): string {
  const segments: string[] = []
  let current: PageRef | undefined = page
  while (current) {
    segments.unshift(current.fields.slug)
    current = current.fields.parent
  }
  const localePrefix = page.fields.locale === "en" ? "" : `/${page.fields.locale}`
  return `${localePrefix}/${segments.join("/")}`.replace(/\/+/g, "/")
}

Du behøver ikke bygge om for at adoptere det. Migrationen er mekanisk:

1. Tilføj den nye PageLink-reference-type ved siden af det eksisterende tekst-URL-felt. Slet ikke det gamle endnu.
2. Kør et engangsscript, der gennemløber hver entry, parser URL-strengen, finder den matchende Page ved sti og skriver referencen. Log de umatchede URL'er.
3. Triagér den umatchede liste. De fleste vil være eksterne links (flyt dem til ExternalLink) eller links til sider, der ikke længere eksisterer (de var allerede brudte — nu ved du det).
4. Stil en redirect-tabel op til de 404'er, du fandt. Den er også CMS-styret: en Redirect-type med from-streng og to som en PageLink.
5. Skjul det gamle tekst-URL-felt i editoren. Fjern det efter én publiceringscyklus.