The Fiona 7 gem is based on the Ruby-on-Rails framework. It was designed with best compatibility with CMS Fiona in mind. When integrating the gem into a Rails application, permission management, the administration user interface, workflows, the TCL interface, and numerous other functions continue to work as usual. Switching over to Fiona 7 requires a Rails application using either the RailsConnector (“Fiona on Rails”) or an empty CMS instance.
The version numbers of the Fiona 7 gem correspond to those of the Scrivito gem. As an example, version 0.3.0 offers best compatibility with Scrivito 0.3.0 All APIs and programming concepts strongly follow those in Scrivito.
Fiona 7 radically changes the way editors work. Most of the content changes can now be made in the preview (in editing mode), i.e. in place, directly on the delivered pages. Only few administrative tasks are still carried out using the classic interfaces. (Even these remaining tasks can be hidden by providing code.)
With Scrivito, all processes refer to a specific working copy, an entity not present in Fiona 7. However, since working copies play a central role in the Scrivito world, and since they are required for compatibility with several Scrivito libraries, Fiona 7 emulates two working copies, the “published content” and the “migration working copy” (“rtc”).
“Published” includes all objects and their released content, “rtc” all objects and their edited content. Both emulated working copies are always present and cannot be deleted. It is not possible to create further working copies.
Experienced CMS users may wonder how Scrivito/Fiona-7 widgets are represented in the CMS. To make switching to the new technology as easy as possible, a simple and pragmatic way of modelling widgets was chosen: Every page able to contain widgets is given a subfolder named “_widgets.” In this folder, objects representing widgets are stored.
So, a page that includes several widgets is made up of several objects in the CMS. For strong consistency, the widget objects are linked by the page, making it impossible to inadvertently delete a widget object because link destinations cannot be deleted.
This approach is also advantageous with respect to the access permissions of the widgets. They inherit their permissions from the page containing them.
The contents of widgets, e.g. images, may be uploaded using drag and drop. If possible, the uploaded images are stored in the “_uploads” subfolder of the page concerned. If this is not possible, the images are stored in the global “/_uploads” folder. It is essential to grant full access to to this folder to each and every CMS user.