Architecture Decision Record · 0033

project_offer URL-Kanon-Korrektur — /fuer-freiberufler/projektliste/ + Legacy-Backlink-Redirect

accepted

★
TL;DR. Kanonischer URL-Pfad fuer project_offer-Detail-Seiten ist /fuer-freiberufler/projektliste/<slug>, nicht /projektpartnerportal/<slug>. Dieser ADR korrigiert ADR-0032 R1, das zum Zeitpunkt der Drupal-Konfig-Pflege noch von /projektpartnerportal als Kanon ausging. Die korrekte Anbindung an die Sitemap-IA (Context-0002, Node N16 Projektliste unter N14 Fuer Freiberufler) macht /fuer-freiberufler/projektliste/ zum kanonischen Pfad; /projektpartnerportal/ bleibt als Legacy-301-Redirect bestehen, damit Bestands-Backlinks (Gulp-Anzeigen, Crawler-Indexe) nicht ins Leere laufen.

Kontext

ADR-0032 R1 (2026-05-15) verbindlichte /projektpartnerportal als kanonischen Pfad fuer Listing-View und Pathauto-Pattern fuer project_offer-Nodes. Das war zu diesem Zeitpunkt die pragmatische Konsolidierung gegenueber konkurrierenden Plan-/PRD-Drafts mit /projektportal/projektangebote/.

Die nachfolgende Sitemap-IA-Detail-Pruefung (Context-0002) hat ergeben, dass der Listing-View fachlich unter N16 Projektliste haengt — Sub-Knoten unter N14 Fuer Freiberufler. Der semantisch korrekte URL-Pfad ist daher /fuer-freiberufler/projektliste/; /projektpartnerportal/ war ein Arbeits-Pfad, der die Sitemap-Hierarchie nicht abbildet.

Der Cutover-PR P2503-113 (Gulp HTML-Feed, F-360, 2026-05-25) hat die Test-Assertions bereits gegen den kanonischen Pfad /fuer-freiberufler/projektliste/ gehaertet (Kernel-Tests mit PathAlias-Setup auf dem neuen Pfad). Der Pathauto-Pattern in config/sync/pathauto.pattern.project_offer_content.yml war zu diesem Zeitpunkt jedoch noch nicht angepasst — bestehende 211 Node-Aliase lagen unter /projektpartnerportal/<slug>. Diese Korrektur loest die Diskrepanz auf.

Entscheidung

1) Kanonischer Pfad: /fuer-freiberufler/projektliste/[node:title]

config/sync/pathauto.pattern.project_offer_content.yml wird auf /fuer-freiberufler/projektliste/[node:title] umgestellt. Neue project_offer-Nodes erhalten den Alias auf diesem Pfad. Listing-View und Menue-Eintraege zeigen ebenfalls auf /fuer-freiberufler/projektliste (Canvas-Page 15 + bestehende menu_link_content-Eintraege haben das bereits).

2) Legacy-Backlink-Redirect via redirect-Modul

Bestehende 211 Node-Aliase unter /projektpartnerportal/<slug> werden via hook_update_9007 in solcom_project_offer.install als 301-Redirect-Entities zur kanonischen Node-URI gesichert. Das verhindert Crawl-Loss bei externen Backlinks (Gulp-Anzeigen, Suchmaschinen-Indexe). Das redirect-Modul ist bereits aktiv (core.extension.yml: redirect: 0) und seine Settings sind in config/sync/redirect.settings.yml versioniert.

3) Explizites Alias-Delete im Update-Hook

Globale pathauto.settings.update_action: 2 ("alten Alias behalten, neuen daneben anlegen") fuehrt im Bulk-Regenerate zu Duplicate Aliases. Der Update-Hook umgeht das, indem er den alten Alias explizit per $alias->delete() entfernt, danach pathauto.generator->updateEntityAlias($node, 'insert', ['force' => TRUE]) aufruft. Die globale Pathauto-Konfig wird nicht veraendert (Karpathy-Surgical-Changes-Disziplin) — nur der Hook regelt das fuer diese 211 Aliase.

4) Idempotenz

Hook-Re-Runs sind no-op: die Query gegen alias LIKE '/projektpartnerportal/%' findet beim zweiten Lauf keine Treffer mehr. Die Redirect-Anlage hat einen zusaetzlichen existing-Check via redirect_source__path, um Doppel-Anlage zu verhindern (z. B. wenn auto_redirect: true aus redirect.settings.yml beim Alias-Wechsel selbst einen Eintrag erzeugt — der manuelle Pfad-Check faengt das ab).

Consequences

  • Positive: Konsistente URL-Hierarchie passend zur Sitemap (Context-0002). Bestehende Backlinks bleiben funktional via 301-Redirect — kein Crawl-Loss. Spec-Konflikt zwischen Auto-Memory project_projektliste_canonical_url und ADR-0032 R1 ist aufgeloest; die Memory ist jetzt der gleiche Wahrheitsanker wie die ADR-Linie.
  • Negative: 211 Redirect-Entities erhoehen die Lookup-Last fuer das redirect-Modul minimal (Drupal-DB-Index auf redirect_source__path macht das vernachlaessigbar). Externe Crawler werden ueber den 301-Hop kurz die alten URLs aus ihrem Index entfernen — temporaer leichte Sichtbarkeits-Delle.
  • Risiken & Mitigation: Falls auto_redirect: true aus dem redirect-Modul im Alias-Update-Hook parallel triggert, koennten Duplikat-Redirects entstehen. Der Hook hat dafuer einen idempotent-Check via redirect_source__path-Query. Live-QA verifiziert die Redirect-Anzahl gegen die Alias-Anzahl (211).
  • Test-Coverage: Kernel-Test PathautoUrlCanonRedirectTest in solcom_project_offer deckt den Hook-Lauf ab — old-alias-delete, new-alias-create, redirect-entity-create.

Supersede-Relation

Dieser ADR ersetzt nur Regel R1 aus ADR-0032. Die Regeln R2 (Migrate-Title-Pflicht), R3 (Outbound-Field-Binding-Disziplin) und R4 (Sitemap-IA-Disziplin) aus ADR-0032 bleiben in Kraft. Eine Supersede-Note in ADR-0032 R1 verlinkt hierhin.

Memory-Stand 2026-05-25: project_projektliste_canonical_url (aktiv) ist mit diesem ADR alignment-konform. Die Memory bleibt der Quick-Lookup, der ADR der ausfuehrliche Begruendungspfad.