Rails 4.2 is a requirement for using the Fiona 7 gem. We recommend to first update Rails to version 4.2 for applications still using older Rails versions and subsequently start testing Fiona 7.
The aspects that should be taken care of when upgrading to Rails 4.2 are documented in detail in A Guide for Upgrading Ruby on Rails. The FionaConnector requires no extra steps in this process.
Yes, it is. However, you still need to include “fiona7.js” and “fiona7.css” in your website. For the CSS and JavaScript alternatives, a different method for including them might be required (e.g. different syntax).
Yes. Since the Fiona 7 gem is based on the standard mechanisms of Rails, template libraries other than “.erb” can be used in the views.
The root account of the application is used for the following tasks:
You can have control attributes displayed and make them editable on the details pages of the corresponding class.
Objects to which no path is assigned during creation are placed directly in a folder named “_orphaned” whose path is hidden from the Rails application. Thus, regarding this matter, Fiona 7 applications behave exactly like Scrivito applications do. Objects that are created using the page menu are automatically created underneath the current page, i.e. as children.
The appearance of the login page can easily be changed. This page is made up of two components, “app/views/layouts/fiona7_login_page_layout.html.erb” (layout) and “app/views/fiona7_login_page/index.html” (the page itself). These files can be overridden simply by creating them in the application.
To change the logic of the login page, override the “Fiona7LoginPageController.” The default object representing the login page is created by the initialization script, “/_global/login_page.” You can move this object without running into problems. Should you require further login pages (e.g. to support additional languages), the “Fiona7LoginPageController” needs to be adapted accordingly.
When the application runs in “standalone” mode, read permissions are not supported. When running in “legacy” mode, you can prevent users from accessing pages they are not permitted to view by adding the following code to the CmsController:
before_action :require_read_permission def require_read_permission return @obj.permission.read? end
This prevents the blocked pages from being opened. However, these pages still show up in lists, for example in navigations generated using the fiona7_toclist helper.
Every page has a page menu that includes an item for directly publishing it. Publishing a page requires the user to have the “permissionWrite” permission for it. Before a page is published the user has the option to choose which linked content should be published together with the page.
It is not possible to release the complete working copy containing the edited content (“rtc”).
Only objects of the “publication” type may have subobjects. If someone tries to add widgets to an object of the “document” type, it won't be posible to store them underneath this object. In this case, the global “/_widgets” folder is used as the storage location: Underneath “/_widgets” a folder is added whose name equals the ID of the page object. In this folder the widgets of the page are stored.
The same applies analogously to uploaded content.
It is no longer necessary to distinguish between the live and the preview mode. The live mode is optional and can still be used where appropriate.
Since logging in to the website causes data to be exchanged with the CMS via the XML interface, the login page should be blocked in the live environment.
This is only possible if your application is running in “legacy” mode. In “standalone” mode, existing images cannot be automatically reused in Fiona 7. If, for example, you have an image library you would like to use with Fiona 7, please contact us. We'll be happy to help you.
Usually, RailsConnector applications are operated using a prefix for the preview. If, for example, the name of the instance is “internet,” the web server should deliver the Rails application using the “/internet” prefix.
It is possible to address the GUI and the application by means of different domains on the same machine. For this, the different applications are hosted on the server using different ports. An apache webserver in front of these ports then forwards requests by their domain name to the corresponding port. For details or help, please contact our support team.