Bad practice
Warum man keine Links aus der Preview kopieren sollte
Ein weiterer, häufig gemachter Fehler tritt beim Einfügen von Links auf. Normalerweise wird der Link, wenn es ein interner Link sein soll, über den Linkdialog eingegeben. Über das blaue Ordner-Symbol kann das entsprechende Ziel ausgewählt werden über die Ordnerstruktur ausgewählt werden.
Dies ist der Weg interne Links einzupflegen. Dabei kommt die Linkverwaltung von Fiona zum Einsatz, die per eindeutiger ID das entsprechende Objekt referenziert und für die freigegebene Version den Link umwandelt.
Bei externen Links kann man hingegen die Linkadresse in Form einer URL einfach per Copy&Paste in das entsprechende Feld einfügen. Wird dies nun mit einem Link aus der Vorschau gemacht, z.B.: https://wcms-fakgw.rrz.uni-hamburg.de/fakgw/NPS/i/zz/xx/fiona/de/service/badpractice/_boxes/vorlage-aendern* so wird dieser Link wie ein externer Link behandelt und nicht noch separat umgesetzt, wie dies bei internen Links der Fall ist. Das führt aber dazu, dass Links auf interne Objekte (in obigem Fall: auf das Boxenelement "Vorlage aendern") nicht aufgelöst werden.
Besucher landen somit auf der obigen Seite und sehen die Vorschau. Damit können diese auch die Arbeitsversion von Seiten sehen, sofern die Zugriffsrechte stimmen.
Es sei hier nochmals darauf verwiesen, dass die Fiona-Instanzen nur aus dem universitären Netz heraus bedient werden können – das gilt auch für die Vorschau, aber um solche Zugriffe zu unterbinden, sollte der Zugriff erst gar nicht angeboten werden.
Zudem werden die Linkziele nicht aus dem Internet heraus aufgerufen werden können.
Warum man nicht die Vorlage ändern sollte
Ein häufig auftretendes Problem, dass sich sofort und ohne Freigabe auf den Live-Betrieb der Webseiten auswirkt, wird durch die Änderung der Vorlage verursacht. In schlimmen Fällen erscheint ein Fehler 500 (Internal Server Error, erkennbar durch die Meldung "We're sorry, but something went wrong"), und die Webseite ist quasi sofort nicht mehr zu erreichen.
Von daher raten wir grundsätzlich davon ab, die Vorlage nachträglich zu ändern.
Hintergrund
Durch die Vorlage werden bestimmte Funktionen in Fiona gesteuert. Wenn Sie nun die Vorlage nachträglich ändern, können diese Funktionen nicht mehr korrekt ausgeführt werden, und es gibt besagten Fehler 500.
Ein beliebtes Beispiel:
- Es wird der Ordner news mit der Vorlage "Nachrichten-Auflistung" angelegt und mit Nachrichten befüllt.
- news wird dann in einem "Container für aktuelle Nachrichten" auf der Startseite verlinkt
- Später wird der Ordner news von der bisherigen Vorlage auf die Vorlage "Standard-Ordner" geändert
In dem Fall wird die Startseite ab dem Zeitpunkt der Änderung einen Fehler 500 auswerfen, da der Container für aktuelle Nachrichten zwingend eine Vorlage "Nachrichten-Auflistung" erfordert, diese aber nicht mehr vorhanden ist.
Lösung
Wenn Sie die Vorlage ändern wollen, empfiehlt es sich daher, ein komplett neues Objekt der gewünschten Vorlage anzulegen. Die Unterseiten können Sie mit der Funktion Ausschneiden komfortabel verschieben. Denken Sie daran, die Links auf das alte Objekt auf das neue zu übertragen, falls sinnvoll und nötig. Danach können Sie dann das alte Objekt löschen.
Falls das alte Objekt Teil einer URL war, also nicht unterhalb eines _boxes Ordners lag, sollten Sie dem neuen Objekt nach Löschung den alten Objektnamen geben. Dann bleibt die URL bestehen, da diese aus den Namen generiert wird.
Warum man Objekte nur in besonderen Fällen deaktivieren sollte
Wenn Objekte im CMS nicht mehr im Live-Auftritt erscheinen sollen, ist der dafür gedachte Standardworkflow „Zurückziehen“. Wenn Inhalte überhaupt nicht mehr gebraucht werden, ist der Standardworkflow „Löschen“.
Oft wurde stattdessen jedoch die Funktion „Deaktivieren“ genutzt, entweder über „Bearbeiten –> Deaktivieren“ oder über das Feld „Gültig bis“. Das hat erhebliche Nachteile:
- Bei skriptbasierten Ändern von Feldern oder Vorlagen im Rahmen von Fiona-Releases werden solche Objekte unter Umständen wieder aktiv.
- Beim Kopieren von Teilbäumen werden diese Objekte neu angelegt und sind deshalb im Status „in Bearbeitung“.
- Links auf deaktivierte Objekte in aktiven, freigebenen Objekten funktionieren nicht
- Die Brotkrümel-Navigation funktioniert nicht richtig, wenn unterhalb eines deaktivierten Ordners aktive Objekte liegen.
Sinnvoll sind nur zeitgesteuerte Dekativierungen, z.B. wenn Informationen eine zeitlich begrenzte Gültigkeit haben, insbesondere z.B. in Nachrichten oder Anmeldeformularen.
Warum man bei Änderungen von Objekt-Namen aufpassen muss
Wenn man Namen von freigegebenen Objekten (Verzeichnissen, Dateien) ändert, löst das keine Aktualisierung von darauf bezogenen Cache-Inhalten und des Solr-Index aus, d.h. das Objekt kommt nicht in den Status „in Bearbeitung“, sondern bleibt freigegeben. Insbesondere bei Personen- oder Nachrichtenverzeichen, deren Inhalt beim Aufruf der Seite nicht dynamisch aus der Datenbank bezogen wird, sondern aus dem Solr-Suchindex stammt, kann es dann dazu kommen, dass der Inhalt plötzlich leer ist. Auch Subnavigationen können plötzlich ins Leere zeigen.
Wenn Sie also den Namen eines Objekt ändern, dann müssen Sie dieses unbedingt noch manuell freigeben, z.B. indem Sie das Objekt zurückziehen und dann wieder freigeben. Erst dann wird auch der Cache-Inhalt und der Solr-Index aktualisiert.