Häufig gestellte Fragen

Müssen wir auf Rails 4.2 umsteigen? Unsere RailsConnector-Applikation fährt immer noch mit Rails 3.2.

Rails 4.2 ist eine Voraussetzung für den Betrieb des Fiona-7-Gems. Für Applikationen, die noch mit einer älteren Rails-Version betrieben werden, empfiehlt es sich, erst einmal auf Rails 4.2 umzusteigen und anschließend Fiona 7 zu testen.

Die Punkte, die beim Upgrade auf Rails 4.2 beachtet werden müssen, sind sehr gut in A Guide for Upgrading Ruby on Rails dokumentiert. Seitens des FionaConnectors gibt es keine Besonderheiten.

Kann man LESS, SASS/CSS oder CoffeeScript mit Fiona 7 nutzen?

Ja, jedoch müssen in diesen Fällen „fiona7.js“ und „fiona7.css“ in die Website inkludiert werden. Für die CSS- und JavaScript-Alternativen sind gegebenenfalls andere Mechanismen für die Inklusion erforderlich (beispielsweise eine andere Syntax).

Darf man HAML, Slim oder andere Template-Sprachen nutzen?

Ja. Da das Fiona-7-Gem auf den Standardmechanismen von Rails basiert, können auch andere Template-Bibliotheken als .erb in den Views verwendet werden.

Wofür wird der root-Zugang genutzt?

Der root-Zugang wird in der Applikation für die folgenden Aufgaben genutzt:

  1. Arbeit in der Konsole (beispielsweise Skripte ausführen)
  2. Initialisierung
  3. Authentifizierung der Benutzer
  4. Automatisches Verwalten von Vorlagen und Attributen

Wie können die zahlreichen Steuerattribute unserer Vorlagen bearbeitet werden?

Steuerattribute können auf der Detailseite der betreffenden Vorlage angezeigt und bearbeitbar gemacht werden.

Bei Scrivito kann es Objekte ohne Pfad geben, wie verhält es sich bei Fiona 7?

Objekte, denen beim Anlegen kein gültiger Pfad gegeben wird, werden in einem separaten Ordner namens „_orphaned“ abgelegt, dessen Pfad vor der Rails-Applikation versteckt wird. Damit ist das diesbezügliche Verhalten von Fiona-7-Applikationen identisch zu Scrivito-Applikationen. Objekte, die über das Seitenmenü angelegt werden, werden automatisch unter der aktuellen Seite platziert, also als Kinder dieser Seite.

Wie können wir die Anmeldeseite ändern?

Das Aussehen der Anmeldeseite kann sehr einfach angepasst werden. Sie besteht aus zwei Komponenten, app/views/layouts/fiona7_login_page_layout.html.erb (Layout) und app/views/fiona7_login_page/index.html (die Seite selbst). Diese Dateien lassen sich einfach überschreiben, indem man sie in der Anwendung anlegt.

Um die Logik der Anmeldeseite zu ändern, überschreiben Sie den Fiona7LoginPageController. Das Objekt, das die Anmeldeseite darstellt, wird standardmäßig durch das Initialisierungsskript unter „/_global/login_page“ angelegt. Dieses Objekt kann problemlos verschoben werden. Sollten Sie weitere Anmeldeseiten anlegen wollen (um beispielsweise weitere Sprachen zu unterstützen), sind entsprechende Anpassungen am Fiona7LoginPageController erforderlich.

Können die Leserechte berücksichtigt werden?

Wenn die Applikation im standalone-Modus läuft, werden Leserechte nicht unterstützt. Im legacy-Modus können die Leserechte auf die folgende Art und Weise berücksichtigt werden:

Um Seiten, für die ein Benutzer kein Leserecht hat, zu sperren, genügt es, folgenden Code in den CmsController einzufügen:

before_action :require_read_permission

def require_read_permission
  return @obj.permission.read?
end

Hierdurch wird nur der Aufruf der gesperrten Seiten verhindert. Die betreffenden Seiten werden weiterhin in sämtlichen Listen aufgeführt, beispielsweise in Navigationen, die mit dem fiona7_toclist-Helper erzeugt wurden.

Wie veröffentlicht man Seiten?

Im Seitenmenü gewöhnlicher Seiten gibt es einen Befehl, mit dem die Seite freigegeben werden kann. Für diese Operation benötigt der Benutzer das Recht permissionWrite bei der betreffenden Seite. Der Nutzer bekommt dann ein Overlay angeboten, worüber er bestimmen kann welche Verlinkten Inhalte zusammen mit der Seite freigegeben werden sollen.

Es ist nicht möglich, sämtliche bearbeiteten Inhalte in der Arbeitskopie („rtc“) auf einmal, d.h. die Arbeitskopie selbst freizugeben.

Welche Bedeutung haben die globalen Ordner /_uploads und „/_widgets?

Nur Objekte, deren Vorlage den Typ „publication“ hat, können Unterobjekte haben. Versucht man, Widgets zu einem Objekt mit einer Vorlage des Typs „document“ hinzuzufügen, können sie nicht unterhalb des Objekts abgelegt werden. In diesem Fall wird der globale Ordner /_widgets als Ablageort verwendet. Unter /_widgets wird ein Ordner angelegt, dessen Name der ID des Seitenobjekts entspricht. In diesem Ordner werden die Widgets der Seite abgelegt.

Dasselbe Verfahren wird auf hochgeladene Inhalte angewendet.

Funktioniert der Live-Modus auch in Fiona 7?

Es besteht keine Notwendigkeit mehr, zwischen Live- und Vorschau-Ansicht zu unterscheiden. Die Live-Ansicht ist optional und kann in Fällen genutzt werden, in denen dies sinnvoll ist.

Da bei der Anmeldung an der Website Daten über die XML-Schnittstelle mit dem CMS ausgetauscht werden, sollte die Anmeldeseite in der Live-Umgebung gesperrt sein.

Lassen sich existierende Bilder für Widgets nutzen?

Dies ist nur möglich, wenn Ihre Applikation im legacy-Modus läuft. Im standalone-Modus  können bestehende Bilder leider nicht ohne Weiteres in Fiona 7 weiterverwendet werden. Wenn Sie beispielsweise eine Bildbibliothek haben, die Sie mit Fiona 7 nutzen möchten, dann wenden Sie sich bitte an uns. Wir helfen Ihnen gern.

Kann eine Fiona-7-Anwendung in der Vorschau getestet werden?

RailsConnector-Applikationen werden in der Regel für die Vorschau mit einem Präfix betrieben. Wenn beispielsweise die Instanz internet heißt, dann sollte die Rails-Applikation unter dem Präfix /internet vom Webserver ausgeliefert werden.

Es ist aber durchaus möglich, GUI und Vorschau über separate Domainnamen auf dem gleichen Server anzusprechen. Hierbei werden die jeweiligen Applikationen über separate Ports ausgeliefert. Über einen vorgeschalteten Apache Webserver lassen sich dann Requests über ihren Domainnamen auf den entsprechenden Port leiten. Für Details oder Hilfe wenden Sie sich bitte an unser Support-Team.