bin geschockt!: Aliase für Seiten ohne Hierarchie (per default)

[zonky]

Hi,

gleich vorweg Folder-URL habe ich installiert!

Nachdem ich nun eine weiterreichende Seitenhierarchie angelegt habe, bin ich über das Thema "Aliase" gestolpert. Das Thema hätte ich eigentlich für keins gehalten, da mir das bei anderen CMS unter meinen Fingern noch nicht vorgekommen ist.

Wie soll ich einem "Anwender" erklären, das das Feld "Alias" eine stupides "DNS-System" ist was aus einer ID einen Namen macht bzw. umgedreht OHNE die erzeugte Hierarchie des Seitenbaumes zu beachten??

Auch die Ext. Folderurl halte ich eher für eine "Notlösung" - wenn ich in der Hierarchie eine "Parent-Seite" anpasse, muß ich mich durch alle "Childs" klicken?? Nö, oder...

Da andere CMS (die auch mit MVC werkeln) das System "on Board" haben, sollte es doch für diese Fragestellung ein "Design Pattern" geben.

Ich bin so geschockt - ich mach mir erstmal ´n Bier auf

zonky

[andre.5tz]

Auch die Ext. Folderurl halte ich eher für eine "Notlösung" - wenn ich in der Hierarchie eine "Parent-Seite" anpasse, muß ich mich durch alle "Childs" klicken?? Nö, oder...

Du kannst zumindest über die Seitenstruktur "Mehrere Bearbeiten" -> Auswahl der Seiten -> Seitenalias -> "einfach alle Inhalte löschen und speichern" sehr schnell die neue Struktur erzeugen (Sollte zumindest so problemlos funktionieren)
Die Funktion habe ich noch nicht bei anderen CMS gesehen!
Hätte nicht so lange gedauert, wie das Schreiben des Beitrags

[zonky]

Hi Andre,

jess - so hab ich die Sache auch gemacht - funktioniert - "elegant" finde ich das nicht...

Die Funktion habe ich bei anderen CMS auch noch nicht gesehen - hatte sie dort bisher auch nicht vermisst, da ich mich nicht darum kümmern muss(te)!

Ich sehe zwar u.U. einen Vorteil für die bisherige Verfahrensweise - z.B. kann man Impressum, AGB, Kontakt in der "Seite" Service unterbringen und so zusammenfassen obwohl nach außen "/service/" niemand sehen muss. Ich finde, das ist eher die Außnahme als die Regel.

Mann kann sich sicher einige Erweiterungen für die Erweiterung Folderurl vorstellen (autom. Update der Kinder-Aliase, wenn Elternalias geändert wird usw.) nach meiner bisherigen Einschätzung bleibt das aber trotzdem nur eine "Hilfsgröße".

Stehe ich mit der Meinung wirklich so alleine da?

zonky

[FloB]

[…] wenn ich in der Hierarchie eine "Parent-Seite" anpasse, muß ich mich durch alle "Childs" klicken?? […]

Schonmal was von Permalinks gehört?

[zonky]

Permalink: sicher...

...kann man machen - muss aber nicht in jedem Fall das non plus ultra sein - insbesondere bei einer herarchischen Struktur mit "festem" Aufbau sehe ich eine Eindeutigkeit in der URL in Forme der "Lesbarkeit" als primäres Ziel.

Beispiel:
folgende URLs werden dem User gezeigt (alles Seiten Kinder von workshops/:

/workshops-seminare/kanienchen.html
/workshops-und-seminare/fische.html
/w-u-s/elefanten.html
/veranstaltungen/hunde.html

wie sollte er sich da orientieren können? Wenn dann die Breadcrums auch noch eine andere Interpretation des "wo bin ich" suggerieren, ist die Verwirrung komplett.

... und Permalink habe ich ja über Aufruf der ID (nicht getestet, aber man kann doch sicher die Seite auch parallel zum Alias so aufrufen - oder?)

Ich will nicht nur "meckern" - auch wenn ich die Anmerkungen nicht als solche verstanden haben möchte - und beteilige mich auch gern an der Entwicklung (Code oder Monetär).

Bin beim TL-Framework noch nicht ganz eingstiegen - ich denke am Controller bzw. Dispatcher wäre hier anzusetzen...??

Gruß zonky

[christian]

Wie soll ich einem "Anwender" erklären, das das Feld "Alias" eine stupides "DNS-System" ist was aus einer ID einen Namen macht bzw. umgedreht OHNE die erzeugte Hierarchie des Seitenbaumes zu beachten??

Na ja, Du hast halt in einem CMS 2 Möglichkeiten: Entweder werden Hirarchien in der Url-Struktur verwendet (als eine Art virtuelle Verzeichnisse), oder eben nicht. TYPOlight verfolgt den Ansatz ohne "Verzeichnisse". Ich halte das auch keineswegs für einen Fehler oder für verbesserungswürdig.

"Folderurl" ist halt die Lösung für diejenigen, die gerne Verzeichnisse in der Url hätten. Das man sich damit den Nachteil einkauft, bei Änderungen mehr Arbeit zu investieren, ist klar.

Anfangs war es anders, aber mittlerweile sehe ich eigentlich keine Vorteile mehr in einer verzeichnisorientierten Url-Struktur, die Umgewöhnung ging sehr schnell.

Grüße,

Christian

[gaj]

Hallo Zonky,

was versprichst du dir von der hierarchischen Darstellung der Urls?

Gruß
Gaj

[zonky]

@gaj

Primär: ... eine Orientierung im Seitenaufbau / Inhaltsstruktur

Sekundär: ich muss für gleiche Themenseiten nicht zwangsweise unterschiedliche Aliase/Urls basteln

z.B
Konferenzen
--Medizintechnik
--Pharma
Workshops
--Medizintechnik
--Pharma

für die beiden Kinderseiten muss ich unterschiedliche Aliase "basteln"

BTW: was ist der Grund warum das DB-Feld ein VARBINARY ist?

gruss zonky

[christian]

Primär: ... eine Orientierung im Seitenaufbau / Inhaltsstruktur

Braucht man das? Der Seitentitel sollte aussagekräftig sein, die Url ist doch eigentlich eher unwichtig. Kurz = gut zu merken.

Sekundär: ich muss für gleiche Themenseiten nicht zwangsweise unterschiedliche Aliase/Urls basteln

z.B
Konferenzen
--Medizintechnik
--Pharma
Workshops
--Medizintechnik
--Pharma

konferenzen-medizintechnik und workshops-medizintechnik ???
Da in TL Alias-Felder systemweit gleich behandelt werden, ist das auch absolut logisch und keineswegs eine Bastelei. Innerhalb einer Domain darf ein Alias eh nur einmal vorkommen - und zwar unabhängig davon, ob der Eintrag noch von irgendetwas anderem abhängt. 2 x "medizintechnik" würde also eh nicht funktionieren. So etwas trifft mal halt 1 x als Grundsatzentscheidung.
Bei "Bandwurmadressen" wird das natürlich schnell sehr viel Arbeit.

BTW: was ist der Grund warum das DB-Feld ein VARBINARY ist?

Man hätte auch Longtext nehmen können. Hier werden halt serialisierte Daten abgelegt, die normalerweise auch nicht per Editor bearbeitet werden sollen. Leo kann Dir die Frage ggf. genauer beantworten.

Grüße,

Christian

[FloB]

Meine Frage bezüglich Permalinks bezog sich nur auf die Änderung der Parent-URL – wenn sich das ändert, gehen alle bisherigen Verlinkungen und Bookmarks verloren. Deswegen sehe ich die "Hürde", dass Kind-Elemente nicht "aktualisiert" werden, als Vorteil für den Nutzer an – der Betreiber kann nicht mal einfach so das Elternelement ändern und wird sich soetwas zweimal überlegen.

[chris]

@FloB: Kleine Rewrite Regel und schon geht das, oder nicht?

[zonky]

...was versprichst du dir von der hierarchischen Darstellung der Urls?

Gruß
Gaj

hmmm... gute Frage: a) braucht man das oder b) braucht man das nicht

wenn b) wieso gibt es sowas überhaupt?

Die Antwort zu dieser Teilfrage ist sicher in derr Historie zu sehen, als statische Webseiten der Übersichtlichkeit im Dateibaum in verschiedene Ordner gepackt hat und diese Ordner-Seiten-Struktur sich bekanntlich in der URL wiederfindet.

Bei einem CMS ist dies nun eigentlich nicht mehr dringend/zwingend notwendig, so dass eine "Grundsatzdiskussion" nach dem Sinn und Zweck durchaus erstrebenswert wäre.

Welche Möglichkeiten stehen zur Alternative zur Verfügung?

1. Aufruf per ID - domain.tld?id=5 bää...
2. alle Seiten haben eindeutigen Alias und werden nach der TLD angezeigt - domain.tld/meineseite.html
3. Seiten mit erweiterter URL (URI ??) aufgebaut - domain.tld/thema/meineseite.html

zu 2.:
wenn ich hier domain.tld/thema-meineseite.html schreibe - was habe ich gekonnt? außer dass niemand auf die Idee kommt per domain.tld/thema/ auf die übergeordnete Seite zu kommen.
Die aus den Blogsystemen bekannten URLs domain.tld/ich-wollte-schon-immer-mal-was-zu-sagen-haben-und-darum-schreibe-ich-hier-an-euch.html haben außer Arbeitsaufträgen an den SEO-Anbietern nur den Service der URL-Verkürzer gebracht like snippy.com/45Uzet23ksher

- super zu merken! warum wurde eigentlich der DNS entwickelt - 112.392.349.23 kann man sich doch auch gut merken... ;-)

zu 3.:
Die Frage, die sich mir hier stellt, ist, warum arbeiten wir im BE nach einer Struktur, die sich im FE nicht wiederfindet - ergo: braucht man im BE die Seitenstruktur?

... der Einspruch zum Thema Navigation: das kann sicher auch anders/einfacher gelöst werden

Daher nochmal die (provokante) Frage: ist eine fixe Seitenstuktur im BE "zeitgemäß"?

Bei Seiten mit einer abzubildenden Hierarchie ist das für die Ordnung sicher prima - dann finde ich die Entsprechung in der URL aber auch für konsequent!

Andererseite kommen mir Projekte von mir in den Sinn, wo genau diese Struktur eher hinderlich war. Man baut sich erst ein Regal mit Themen und soll dann seinen Kram einsortieren - hmm... hierhin oder doch dahin?

siehe Beispiel oben: ich kann die Hierarchie nach Veranstaltungsthemen aufbauen oder nach Inhaltsthemen und jeweils die anderen Elemente "verkindern". Es ist sicher möglich, sich eine zweite "blinde" Hierarchie aufzubauen und die schonmal eingegebenen Artikel in die zweite Hierarchie zu "includen" oder irgendwie die Sache mit Taxonimie bzw. Tags zu lösen.

Für eine relativ gradlinige Eingabe von "Content" bzw. bei überschaubarer Informationsfülle gut handelbar - will man aber das M wie Management im Kürzel CMS herausstreichen kommt man mit dieser Logik zwangsläufig an die Grenzen.

An der Stelle haben sich (die mir bekannten) CMS zu wenig vom Dateisystem oder Buch abgenabelt.

Was ist die Alternative dazu? ... ich überlege mal

gruss zonky

[FloB]

@FloB: Kleine Rewrite Regel und schon geht das, oder nicht?

Ja, wenn man sie einrichtet – was zu viele nicht machen. Wenn mit einem Klick die gesamte Struktur geändert werden kann, denken die wenigsten direkt daran eine RewriteRule einzusetzen.

[FloB]

An der Stelle haben sich (die mir bekannten) CMS zu wenig vom Dateisystem oder Buch abgenabelt.

Was ist die Alternative dazu? ... ich überlege mal

Du suchst ein Node-basiertes CMS, z. B. Drupal.


Ansonsten muss ich sagen, dass ich eine Integration der folderurl-Funktionalität in den Core, zumindest als dazuschaltbare Option, ebenfalls befürworte.

[chris]

Ich möchte der obigen Ausführung noch folgendes hinzufügen:

URL Ordner sind gelernte, visuelle Kategorisierungs-Strukturen.
Bindestriche dienen dagegen dazu, Wörter zu gliedern, die zusammengeschrieben zu unüberischtlich wären. Eine künstliche Verkettung von Themengebiet und Inhalt ist aber eine nicht regelkonfrome Anwendung und kommt damit den typischen Lesegewohnheiten nicht entgegen, kann sogar im schlimmsten Fall unleserlich werden, da es keine Regel gibt, an welcher Stelle Haupt-, Unterkategorie und Inhalt zu platzieren sind. Besonders chaotisch wird es, wenn dann noch ein "echter" Bindestrich dazu kommt.

Gut, wir sind alles denkende Menschen. Die meisten kommen darauf klar. Aber was ist mit Maschinen? Versetzen wir uns mal in eine Suchmaschine. welche Variante kommt ihr eher entgegen, die flache URL-Hierarchiestruktur mit Bindestrichen, oder die URL Ordnerstruktur?
In letzterem Fall ermöglicht man Google nicht nur die semantische Unterscheidung von Kategorie und Inhalt, sondern kann auch im Namen der aufgerufene Datei unverwässert das Keyword platzieren.

Hartgesottene TL Core verfechter mögen noch Hoffnung auf KI haben. Sie könnten alternativ auch sagen: "aber da gibts ja Extensions mit denen man... da muss man dann nur noch auf 'mehrere bearbeiten'... "

Dieser und viele andere Workarounds sind der einzige Grund, weshalb TL zumindest für Templatefrickler in Puncto SEO/Barrierefreiheit verwendbar ist.

Es stellt sich die Frage, kann und will man überhaupt TL zur eierlegende Wollmilchsau machen?

Grüße
Chris

[zonky]

Du suchst ein Node-basiertes CMS, z. B. Drupal.

Vorbemerkung: habe mit Drupal bisher nur "gespielt"

hmm - ja - der Node-Ansatz ist - denke ich - ganz gut, aber im BE findet man genau wieder die Ordnerstruktur wie immer. Man kann sich zwar eigene Views bauen, die Nodes anhand spezifischer Eigenschaften darstellen, aber das Inhalts-Management ist dadurch nicht einfacher.

Ansonsten muss ich sagen, dass ich eine Integration der folderurl-Funktionalität in den Core, zumindest als dazuschaltbare Option, ebenfalls befürworte.

zu/abschalten finde ich akzeptabel - nur sollte es bei Zuschaltung auch "pflegeleicht" funktionieren (in meinem Sinne zu verstehen s.o.)

[zonky]

zu Chris:

ich kann dem nur zustimmen - konsequenter Weise sollte dann aber das System auch mit

domain.tld/thema/

umgehen können. Beim ordnerbasierten System sucht der Server nach der eingetragenen index-Datei - bei einem DB-basierten System ist an der Stelle zu überlegen was gewünscht/"Standard" ist.

...warum soll TL nicht zur "eierlegende Wollmilchsau" werden?

gruss zonky

[chris]

Es gibt nicht nur diverse Zielkonflikte, sondern auch festgefahrene Meinungen. Das macht die Unternehmung eierlegende Wollmilchsau nicht nur zu einer Frage der Perspektive, sondern auch zu einem schwierigen Unterfangen. Man darf darüberhinaus auch nicht vergessen, dass die Entwicklungsarbeit nicht auf viele Schultern verteilt ist und die Priorisierung nicht unbedingt der persönlichen Präferenzstruktur ensprechen muss.

[zonky]

Hi Chris,

haste recht...

Hier ist ja nicht der "offizielle" Support für TL - ich denke in der Community kann das (und andere Themen) angerissen werden.

Wie ich im TL-Blog sehe, gehen doch einige Ideen und Entwicklungen aus der Community in den Core ein.

Gruss Ingolf

[chris]

@FloB

Hatte deinen Kommentar bzgl. Rewrites irgendwie übersehen.

Ja, wenn man sie einrichtet – was zu viele nicht machen. Wenn mit einem Klick die gesamte Struktur geändert werden kann, denken die wenigsten direkt daran eine RewriteRule einzusetzen.

Meiner Meinung nach sind Änderungen der Strukturen wenn dann in der Entwicklungsphase häufiger gegeben als auf Produktivseiten. Wenn die Seiten aber erstmal online ist, dann wird man solche groben Veränderungen eher selten machen und wenn, dann wird jeder, dem sein bis dahin erzieltes Googleranking wichtig ist daran denken ein Rewrite zu setzen. Wers nicht tut, dem ist die Platzierung auch nicht wichtig.

Gruß
Chris

[xtra]

zu Chris:
ich kann dem nur zustimmen - konsequenter Weise sollte dann aber das System auch mit
domain.tld/thema/

umgehen können. Beim ordnerbasierten System sucht der Server nach der eingetragenen index-Datei - bei einem DB-basierten System ist an der Stelle zu überlegen was gewünscht/"Standard" ist.

Das mit dem Ordnerbasierten System und dem datenbankbasierten System koennte man die Auswertung/Akzeptierung eines solchen trees generell zustimmen.
Nun kommt jedoch, wer haett es gedacht, ein "Aber".
TYPOlight verwendet mit slash separierte Parameter (...item/foobar), wie gedenkst du diese in Zukunft zu verwalten? Ab wo ist in der URL dann ein Parameter, dann braucht es einen speziellen Seperator, oder aber jeder Extension Entwickler muss dem Core Bescheid sagen, Welche Parameter er gerne verwenden will.
Das fyhrt in logischer Konsequenz irgendwann dazu, dass man sehr viele Begriffe als Seitenalias nicht mehr verwenden darf, da sie von irgendeiner Extension als Parameter erwartet werden.
Der Kompromiss ist die aktuelle Extension, mit welcher man den hierarischen Seitenbaum auch als Ordner-alias abbilden kann. Hierbei werden ebenfalls die entsprechenden Werte als Parameter registriert.
Dass dies im Core nicht enthalten ist, das hat aber definitiv seinen Grund denn deine Frage:

...warum soll TL nicht zur "eierlegende Wollmilchsau" werden?
gruss zonky

Diese Frage will ich an einem Beispiel beantworten:
Aktuell ist im TYPOlight core enthalten:

• Kalender
• Kommentarmodul
• FAQ
• Listenansicht von Tabellen
• Nachrichten
• Newsletter
• Mitgliederregistrierung
• RSS Leser

Eine Durchschnittliche Seite benoetigt von diesen Modulen schon nicht alle, dennoch werden sie bei TYPOlight immer mitgebracht.
Du willst nun durch deine Aussage, dass es eine Eierlegende Wollmilchsau werden soll, vermutlich dass noch mehr im Core ausgeliefert wird.
TYPOlight ist aber ein System, dass sein "light" nicht umsonst im Namen traegt (von obigen Modulen schmeisse ich z.B. etliche immer raus, da ich sie nicht benoetige und somit den "Ballast" yber Bord werfe).
Das System selbst ist schlank und soll dies auch bleiben.
Jedoch steht es einem jederzeit frei, Extensions und Module zu entwickeln um seine eigene Installation alles andere als "light" zu gestalten um zum vom Kunden oder selbst gewynschten Ergebnis zu kommen.
Der Spagat um bei diesem Ausbau nicht aus Versehen statt einer "rich" Installation eine "fat" Installation zu erhalten, bei der zigtausend ungenutzte Module und Dinge enthalten sind, muss der Designer jedoch machen.

Im Allgemeinen ist TYPOlight eine "Eierlegende-Wollmilchsau-Zucht", aus der der Anwender (Ich meine hierbei denjenigen der die Installation in Betrieb nimmt und wartet, nicht den Redakteur) seine eigene persoenliche Eierlegende Wollmilchsau bauen kann.

Meiner Meinung nach sind Änderungen der Strukturen wenn dann in der Entwicklungsphase häufiger gegeben als auf Produktivseiten. Wenn die Seiten aber erstmal online ist, dann wird man solche groben Veränderungen eher selten machen und wenn, dann wird jeder, dem sein bis dahin erzieltes Googleranking wichtig ist daran denken ein Rewrite zu setzen. Wers nicht tut, dem ist die Platzierung auch nicht wichtig.

Mit solchen Pauschalaussagen waere ich generell vorsichtig.
Deine Annahme, dass sich die Struktur vorrangig(!) in der Entwicklungsphase aendert teile ich zwar.
Dennoch will mir hier nun nicht einleuchten, warum es nicht so wichtig sein sollte, wenn Redakteur B bei einem internen Glaubenskrieg einer Firma der Meinung ist die Seiten gehoeren woanders hin, da es seiner logischen Struktur eben anders entspricht. Oder aber er moechte nur dass es im Menu woanders auftaucht (Eine Messe ist gerade wichtig, daher verschiebt der Redakteur die jeweilige Seite in den root anstatt im Root eine Weiterleitung anzulegen usw.).
Dummerweise ist dieser Redakteur B nun im Gegensatz zu Redakteur A nicht geschult worden was SEO und all diese tollen Buzzwords bedeuten und dass die Seite hierarchische URL verwendet.
Redakteur A ist jedoch im Urlaub, Krankenhaus, was weiss ich und kann daher aktuell die Webseite nicht pflegen.
Erklaerst du hinterher dem Chef warum seine Seiten alle aus den Suchmaschinen verschwinden, bloss weil man eine Seite in der Struktur verschoben hat?
Daher ist Meiner Meinung nach der aktuelle Weg der Beste. Du kannst verschieben und tun was du willst (alias nicht anfassen) und die Seiten bleiben da.
Wenn du was anderes willst, dann nimm die Extension und pflege deine Aliase selbst.
Man koennte evtl. nachdenken alle Aliase auf Wunsch neu generieren zu lassen, jedoch nicht einfach so automatisch den Alias umbiegen lassen, wenn man eine Seite verschiebt.
Einen dahingehenden Patch nimmt Andeas Schempp sicher auch gerne entgegen (schliesslich werden solche Extensions von uns allen kostenlos bereit gestellt, externe Mitarbeit wird gerne gesehen).

Gruß
Chris

Gruss
Ein anderer Chris

[schman]

Meiner Meinung nach sind Änderungen der Strukturen wenn dann in der Entwicklungsphase häufiger gegeben als auf Produktivseiten. Wenn die Seiten aber erstmal online ist, dann wird man solche groben Veränderungen eher selten machen und wenn, dann wird jeder, dem sein bis dahin erzieltes Googleranking wichtig ist daran denken ein Rewrite zu setzen. Wers nicht tut, dem ist die Platzierung auch nicht wichtig.

Unsere Stadt Webseite hat viele Seiten die Struktur ist eigentlich vorgegeben, denoch passiert es recht häufig das die Abteilungen intern umstrukturieren. Beispiel ein Redakteurswechsel hat statt gefunden, der neue Redakteur will das ganze mal "aufräumen" da kann es dann schon passieren das einige Seiten komplett woanders sind.

[chris]

Erstmal danke für die ausführlichen Erklärungen.

Ich fände es ja super, wenn TL noch schlanker wäre und so gut wie alle Module nachinstalliert werden müssten. Aber dann bitte so, dass nachvollziehbar ist, welches Modul für welchen Zweck benötigt wird. Die Auslagerung der Funktionalitäten in Extensions verhindert meiner Meinung nach noch lange nicht, dass TL eine eierlegende Wollmilchsau sein könnte.

Aber um zB. das DC Startseitenproblem in den Griff zu bekommen "Googlesitemaps" installieren zu müssen (damit man dann in der Seitenstruktur auf der gewünschten Seite "Startseite" anhaken kann), das kann doch wohl wirklich keiner wissen und verlangt selbst erfahrenen Entwicklern eine Menge Recherchearbeit ab und führt zum Großteil mit Sicherheit sogar zu Kopfschütteln. Mal abgesehen von der Notwendigkeit dann auch noch in der htaccess einen permanenten Redirect zu setzen (von start.html zur unspezifischen URL) macht in der Summe doch zu viele Fallstricke, ganz besonders für Hobbyseitenbauer, die nirgends dokumentiert sind, außer in den Tiefen des Forums.

Je mehr dieser kleinen, undokumentierten Workarounds benötigt werden, desto weniger Eier legt diese Wollmilchsau.

Und um nun auf unser URL Folder Beispiel zu kommen, ich glaube am Ende ist es egal wie es gehandhabt wird, hauptsache der Lösungsweg liegt in irgendeiner Art auf der Hand. Am besten er ist selbsterklärend und man muss nicht in den Tiefen des Forums nach ähnlichen Themen suchen.

Nicht falsch verstehen, ich habe hier nicht die Headline des Threads untermauern, sondern lediglich dem Hinterfragen der Sinnhaftigkeit von URL Foldern entgegenwirken wollen. Mir ist das prinzipiell wurscht, ob die Aliase der Hierarchie gehorchen, wenn man sie mit einem Rutsch schnell ändern kann.

An dieser Stelle noch ein Hinweis falls der Entwickler der Extension das lesen sollte. Besser wäre den URL Folder in einem Separaten Feld unterzubringen, denn oft hat man im Hinblick auf SEO den Seitennamen fürs Frontend absichtlich andes gewählt als den Namen der Seite in der Seitenstruktur des Backends. Beim Löschen aller Felder, um den Folder anders benannt zu bekommen ist dann aber leider die Arbeit futsch.

Grüße
Chris