EuroTech Web

Das öffentliche Gesicht der Organisation hatte eine Aufgabe: Bewerbende aus vier Sprachen bis zu dem Punkt zu führen, an dem sie ihre Daten hinterlassen. Die Schwierigkeit liegt dabei nicht in der Übersetzung, sondern im Routendesign. Wird auf einer mehrsprachigen Seite die Sprache nachträglich ergänzt, brechen Adressen, und die bis dahin aufgebaute Sichtbarkeit in der Suche geht verloren. Der zweite Punkt ist die Quellenverfolgung: Woher jemand kam, der über eine Anzeige eintraf, durfte beim Absenden des Formulars nicht verloren gehen — sonst weiß niemand, welcher Kanal wirkt. Der dritte Punkt sind Messung und Cookies: Der Messcode durfte vor der Einwilligung nicht geladen werden.

Drei Besuchergruppen. Bewerbende: kommen in einer von vier Sprachen, durchstöbern Programm- und Inhaltsseiten und füllen am Ende das Bewerbungsformular aus. Eltern oder Institutionen: lesen dieselben Inhalte auf der Suche nach Vertrauen. Das Team der Organisation: sieht die eingegangene Bewerbung und die Kampagnenquelle — dieser Teil läuft auf der Portalseite.

Als Entwickler die gesamte Website: Routen- und Sprachstruktur, Seiten, Bewerbungs- und Kampagnenablauf, Cookie- und Messschicht.

Eine serverseitig gerenderte Website auf Laravel 10. Die Sprache ist als erstes Segment der Routengruppe definiert und wird von einer Middleware gelesen: Sie vergleicht den eingehenden Wert mit den vier unterstützten Sprachen, fällt bei ungültigem Wert auf den Standard zurück und setzt die Sprache als Standardparameter für alle folgenden URL-Erzeugungen. So liefert ein einziger Routenbaum vier Sprachen, und die Templates müssen die Sprache nicht mitführen. Die Datenseite ist schmal: zwei Modelle — Benutzer und Kampagne. Das Bewerbungsformular schreibt einen Datensatz in die Datenbank und versendet eine E-Mail-Benachrichtigung; der Bot-Schutz liegt auf einer eigenen Prüfroute. Die Cookie-Einwilligung liegt in einem eigenen Controller, und ob der Messcode lädt, hängt an dieser Einwilligung. Alte Sprachpfade bleiben über dauerhafte Weiterleitungen erhalten.

1. 01

   Sprache wurde als Routing-Frage behandelt, nicht als Übersetzungsfrage

   Die Sprache ist das erste Segment der Routengruppe und wird von einer Middleware geprüft, die bei ungültigem Wert auf den Standard zurückfällt. Da die Sprache zugleich als Standardparameter für die URL-Erzeugung gesetzt wird, müssen Templates sie nicht mitführen — ein irgendwo geschriebener Link entsteht in der richtigen Sprache. Genau das lässt vier Sprachen in einem Routenbaum leben.

   KompromissDie Pfadsegmente sind in allen vier Sprachen gleich; nur das Präfix ändert sich, die Segmente selbst werden nicht übersetzt. Für die Sichtbarkeit in der Suche ist das schwächer als lokalisierte Pfade. Bei VAP Turizm habe ich dasselbe Problem andersherum gelöst: Dort ändern sich die Pfade selbst mit der Sprache — zum Preis von drei Definitionen je neuer Seite.

2. 02

   Die Kampagnenquelle liegt in einem eigenen Modell

   Woher jemand über eine Anzeige kam, durfte beim Absenden des Formulars nicht verloren gehen. Die Quelle in einem eigenen Modell statt vermischt mit dem Seiteninhalt zu halten, sorgt dafür, dass der Quelleneintrag Inhaltsänderungen übersteht.

   KompromissDie Quelle wird nur beim Erstkontakt erfasst; kehrt jemand über einen anderen Kanal zurück, bleibt der erste Eintrag bestehen, eine Last-Touch-Information wird nicht geführt. Der Eintrag beantwortet also "wie haben sie uns gefunden", nicht "welcher Kanal hat konvertiert".

3. 03

   Der Messcode lädt nach der Einwilligung

   Der Einwilligungsstatus wird in einem eigenen Controller verwaltet, und davon hängt ab, ob der Messcode auf die Seite gelangt. Vor der Einwilligung wird nicht gemessen; das ist eine Compliance-Entscheidung zulasten der Messgenauigkeit.

   KompromissWer nicht einwilligt, erscheint in der Messung überhaupt nicht, der berichtete Verkehr bleibt also unter dem tatsächlichen. Diese Differenz wurde akzeptiert.

4. 04

   Veröffentlichte Adressen wurden über dauerhafte Weiterleitungen erhalten

   Die Sprachstruktur änderte sich im Lauf der Zeit, und auf alte Adressen kamen weiterhin Links. Statt gelöscht zu werden, kamen alte Pfade hinter dauerhafte Weiterleitungen, sodass externe Links und Einträge in Suchergebnissen nicht brachen.

   KompromissDie Weiterleitungstabelle wächst, und nichts wird je entfernt; jede Weiterleitung ist eine kleine Wartungslast und eine bei jeder Anfrage ausgewertete Regel. Es gibt keine Messung, welche Weiterleitung noch Verkehr erhält.

Die Website wurde auf demselben Framework wie das Portal geschrieben, und das war Absicht: Teilen zwei Anwendungen derselben Organisation Sprache, Bereitstellungsart und Betriebsmodell, läuft die Wartung mit einem mentalen Modell. Serverseitiges Rendern genügte für eine Seite aus Inhalten und einem Formular — eine getrennte Frontend-Anwendung samt API-Vertrag hätte sich nicht gelohnt. Dennoch blieben Website und Portal getrennte Anwendungen: Eine öffentliche Oberfläche mit einem geschlossenen Portal dieselbe Bereitstellung teilen zu lassen, hätte die Angriffsfläche ohne Grund vergrößert.

Der einzige öffentliche Schreibpfad ist das Bewerbungsformular, geschützt durch einen Prüf-Endpunkt auf eigener Route. Außerhalb dieses Formulars gibt es keinen Endpunkt, über den Besuchende in die Datenbank schreiben können. Die Cookie-Einwilligung liegt in einem eigenen Controller, und Drittanbieter-Messcode gelangt vor der Einwilligung nicht auf die Seite. Da Website und Portal getrennte Anwendungen sind, bedeutet eine Kompromittierung der öffentlichen Oberfläche keinen Zugriff auf Portaldaten — diese Trennung ist der wertvollste Teil dieses Entwurfs.

Für diese Website liegt keine gespeicherte, mit Datum versehene Messung vor, deshalb steht hier kein Score. Strukturell werden die Seiten auf dem Server erzeugt und als vollständige Seiten gesendet; auf dem Client wird keine Anwendungsschicht mitgeführt. Da der Messcode erst nach der Einwilligung lädt, tragen Besuchende, die ablehnen, auch kein Drittanbieter-Skriptgewicht.

Aktive Entwicklung

2024-10 → 2025-11 · 355 Commits

Quelldateien

109 PHP- und Blade-Dateien — die Verzeichnisse app, resources, routes und database

Struktur

6 Controller · 69 Blade-Views · 2 Modelle · 4 Migrationen

Sprachen

Vier Sprachen, ein Routenbaum

Hinweis zur Zählung

In diesem Repository liegt der Ordner der Fremdbibliotheken unter Versionskontrolle; gezählt wurden nur die von mir geschriebenen Verzeichnisse

Die klarste Lehre, die ich von hier mitgenommen habe, ist die Lokalisierung der Pfade. Auf dieser Seite ändert sich nur das Sprachpräfix, die Segmente sind in allen vier Sprachen identisch; bei VAP Turizm habe ich dasselbe Problem andersherum gelöst und die Pfade nach Sprache getrennt. Die zweite Lehre betrifft Weiterleitungen: Eine veröffentlichte Adresse nicht still zu verlieren, ist das Einzige, was sich später nicht reparieren lässt. Anders machen würde ich die Messseite: Die Weiterleitungstabelle wuchs, aber nichts zeigt, welche Regel noch Verkehr erhält — also lässt sich keine Weiterleitung gefahrlos löschen. Dieselbe Lücke habe ich bei Ops Panel auf der Inventarseite geschlossen: Ohne zu sehen, seit wann ein Eintrag in diesem Zustand ist, lässt sich nicht entscheiden, welcher aufgeräumt wird.