kubczak
Crownpeak employee

Änderung der Dateiendung (Extension) einer Seite und Zurücksetzen der persistenten URLs (SEO)

Jump to solution

Hallo,

wir stehen aktuell in einem Projekt vor dem Problem, die Dateiendung einer Seite auf Basis einer Eingabekomponente der Seitenvorlage ändern zu müssen. Das wurde im Prinzip schon einmal hier besprochen: https://community.e-spirit.com/message/4262

Die Problematik ist die gleiche: Weist eine entsprechende Eingabekomponente der Seite (oder ihrer Metadaten) einen bestimmten Wert auf, so soll statt einer .html Seite eine .jsp Seite generiert werden. Ein erster Ansatz war, das Ganze über einen eigenen URLCreator, bzw. eine URLFactory zu realisieren. Das Problem an dieser Stelle ist jedoch, dass die "getUrl" Methode der Factory nicht mehr aufgerufen wird, sobald der Seite durch den URLCreator eine URL zugewiesen wurde (Stichwort persistente SEO-URLs). Ändert man also im Nachhinein den Wert der Eingabekomponete in der Seite und generiert erneut, bekommt die Seite ihre alte Endung, da für sie ja bereits eine URL vergeben wurde. Das passiert auch, wenn ich das ganze mit Absätzen realisiere, die die Dateiendung der Seite überschreiben.

Das Problem läßt sich also darauf reduzieren, ob es eine Möglichkeit gibt, die gespeicherten URLs einer Seite dynamisch zurückzusetzen, wenn der Redakteur bestimmte Änderungen an der Seite durchgeführt hat, bzw. diese noch vor dem Aufruf der "getUrl" Methode der URLFactory abzufangen. Ein automatisiertes "Gespeicherte URLs zurücksetzen", wenn man so will.

Viele Grüße,

Christian

0 Kudos
1 Solution

Accepted Solutions
kubczak
Crownpeak employee

Danke für die Hinweise. Es ging im Speziellen um JSP-Fragmente in der Seite, die basierend auf einer Permission Komponente in den Meta-Daten verwendet werden sollten, damit eine Custom Web-App beim Kunden die Absicherung der kompletten Seite vornehmen konnte.

Mittlerweile ist man hier zu einer anderen Lösung über gegangen, bei der die als abgesichert spezifizierten Seiten von FS in eine XML-Datei geschrieben werden. Die Aufrufe im Live-System werden dann über ein Filter-Servlet geschickt, welches diese XML-Datei als Basis heranzieht und den Zugriff auf eine Seite erlaubt/verweigert. Die Seiten können somit nach wie vor als reine HTML-Seiten bestehen bleiben und auch das Prinzip der stabilen URLs wird nicht beeinträchtigt.

View solution in original post

0 Kudos
3 Replies
broszeit
I'm new here

Hallo Christian,

das Ganze sollte mit gar nicht so viel Aufwand möglich sein:

1. Einen StoreListener implementieren, welcher auf Änderungen an den Seiten reagiert.

2. Dieser prüft, ob sich der Wert der Eingabekomponente auf der Seite (bzw. Metadaten evtl auch Seitenreferenz?!) seit der letzten Revision geändert hat.

3. Wenn ja, dann soll die URL aller PageRefs zurückgesetzt werden:

Das erreicht man mithilfe der URLProperties, welche eine Methode resetStoredUrls bereitstellen.

Viele Grüße

Rouven

Der Weg über StoreListener ist kein solider. Besser wäre hier ein Auftrag, der über die Revisions-Metadaten läuft und bei entsprechenden Änderungen die passenden Aktionen ausführt. Generell finde ich es aber problematisch, "stabile" URLs einzuführen, dann aber bei Inhalts-Änderungen diese stabile URL "in die Tonne zu kloppen". Ich vermute hier geht es JSP-Fragmente, die Template-gesteuert eingeblendet werden. Hier sollte man eher versuchen, Web-Server-Magie zu finden, damit die Stabilität der URLs erhalten bleibt.

Peter
kubczak
Crownpeak employee

Danke für die Hinweise. Es ging im Speziellen um JSP-Fragmente in der Seite, die basierend auf einer Permission Komponente in den Meta-Daten verwendet werden sollten, damit eine Custom Web-App beim Kunden die Absicherung der kompletten Seite vornehmen konnte.

Mittlerweile ist man hier zu einer anderen Lösung über gegangen, bei der die als abgesichert spezifizierten Seiten von FS in eine XML-Datei geschrieben werden. Die Aufrufe im Live-System werden dann über ein Filter-Servlet geschickt, welches diese XML-Datei als Basis heranzieht und den Zugriff auf eine Seite erlaubt/verweigert. Die Seiten können somit nach wie vor als reine HTML-Seiten bestehen bleiben und auch das Prinzip der stabilen URLs wird nicht beeinträchtigt.

0 Kudos