Files
ipal-kit/docs/slug.md
T

2.0 KiB

slug

Pole slug generowane automatycznie z tytułu, per locale.

Plugin JUŻ to ma — nie pisz własnego auto-sluga. Częsty błąd: projekt dodaje ręczne pole { name: 'slug', type: 'text' } i każe redaktorowi wpisywać slug, albo pisze własny hook normalizujący. Nie trzeba — buildSlugField robi to lepiej: auto-generacja gdy puste, nie nadpisuje ręcznego, per-locale, diakrytyki PL→ASCII. Jeśli w kolekcji masz ręczny slug, ZAMIEŃ go na buildSlugField({ from: 'title' }).

Użycie (kolekcja klienta)

import { buildSlugField } from '@intecion/ipal-kit'

export const Pages: CollectionConfig = {
  slug: 'pages',
  fields: [
    { name: 'title', type: 'text', required: true, localized: true },
    buildSlugField({ from: 'title' }),
    // ...
  ],
}

Zwraca gotowe pole: slug, text, localized, required, z hookiem beforeValidate.

Zachowanie

Slug generuje się z pola źródłowego tylko gdy jest pusty. Cokolwiek edytor wpisze ręcznie, zostaje — także po zmianie tytułu. Zmiana adresu opublikowanej strony to zerwane linki, więc plugin nigdy nie robi tego sam.

Diakrytyki idą przez slugify: „Strona główna" → strona-glowna.

Per locale

Slug jest zlokalizowany — każdy język ma własny. Edytując w PL ustawiasz slug.pl, w EN slug.en.

Konsekwencja: slug generuje się tylko dla locale, w którym wypełniono tytuł. Utworzysz stronę po polsku, przełączysz front na /en/… — 404, bo slug.en jest puste. Trzeba przełączyć locale w adminie i wpisać tytuł po angielsku.

To ta sama mapa slugów, z której powstają hreflang alternates (patrz seo.md) i przełącznik języka (patrz i18n.md).

Opcje

buildSlugField({
  from: 'title',        // pole źródłowe
  name: 'slug',         // nazwa pola (domyślnie 'slug')
  required: true,       // domyślnie true
})

Pomocnicze

import { toSlug } from '@intecion/ipal-kit'

toSlug('Strona główna')   // 'strona-glowna'