Migrating to Model-Based Object Classes

Migrating to Model-Based Object Classes

In versions prior to 0.60.0, Scrivito stored CMS object and widget model classes and their attributes in the CMS. This technique caused creating and maintaining object classes to be cumbersome and difficult to understand. Therefore, CMS-based object classes have been abandoned in version 0.60.0. Object classes and the attributes they have are now solely represented as Ruby models.

This article describes how to upgrade an application that uses Scrivito < 0.60.0 and migrate its content to replace CMS-based object classes with corresponding Ruby model classes.

In order to upgrade an application based on Scrivito < 0.60.0, you need to first upgrade the application itself and then migrate its content.

Upgrading to Scrivito 0.60.0

If you are maintaining an application that was migrated from the “cms.infopark.net” platform to Scrivito, please make sure your content maintenance procedures don’t depend on “Infopark Admin GUI 2.0”. After updating to version 0.60.0 and migrating the content, “Infopark Admin GUI 2.0” will no longer be available to your users. Applications that have always been running on Scrivito should be ignorant of the existence of the “Admin GUI 2.0”.

First, update the version of the scrivito gem in your Gemfile to 0.60.0 and run “bundle install”. Next, your Ruby models representing object classes need to be extended to include the CMS attributes these models have. In previous SDK versions, object classes and their attributes were stored in the CMS, now they are defined in the application using Ruby models.

Fortunately, Scrivito already provides a Rake task which does this for you. So, please run:

bundle exec rake scrivito:migrate_attribute_definitions

This iterates over the classes in app/models that inherit from Obj or Widget and determines the corresponding “ObjClass”es stored in the CMS.

If no object class exists for a model, the task prints a warning and suggests these solutions:

  • You have an unused ruby class that can be removed.
  • You have a model for which intentionally no ObjClass exists. It might be an intermediate abstract class, for example.

If the ObjClass was found, the task inspects its attributes and generates the corresponding method calls in the Ruby model. If, for example, you have a “Page” model and a corresponding ObjClass named “Page” that includes a “title” attribute of the string type and a “body” attribute of the widget type, then the task changes your model as follows:

Starting at version 0.60.0, the widget field type is named widgetlist, so the task automatically renames it. It also automatically renames other field types if required. For details, please refer to the SDK Release Notes.

After executing the migration Rake task, you can open the in-place editing UI and check whether everything is still delivered as expected. Note that model-based attribute definitions are mandatory with version 0.60.0 and later even if the requested content has not been migrated and still includes CMS object classes.

Having sanity-checked your website, you can deploy the upgraded version of Scrivito to your staging or production servers.

Migrating the content

Before you start migrating your content, please ensure that all instances of your application (i.e. production servers, staging servers, test and development environments) have been successfully updated to Scrivito 0.60.0. Earlier versions of Scrivito will cease to work once the content has been migrated because they cannot read the new data format of the content after migration.

First, create the migration working copy for the purpose of dropping ObjClass support. Open the Rails console and enter:

Next, open the in-place editing UI on the production servers of your application. Select the “No ObjClass” working copy and check whether your application works as expected. If everything looks fine, publish the migrated working copy using either the in-place editing UI or the Rails console:

Finally, the working copies that were created prior to adapting the migration working copy need to be updated one by one. You can do this either in place or programmatically in the Rails console:

Afterwards, all working copies should be free of CMS object classes. You can now continue maintaining your content as usual.

Changes to the Web Services API

The migration alters the data format of CMS objects and widgets used by the REST API. The Scrivito SDK handles the format change transparently, so your application should not be affected if you use the API provided by the Scrivito SDK to access CMS objects and widgets.

In case your application bypasses the SDK and communicates directly with the REST API, please take the changed data format into account.

Attribute values used to be communicated as a hash containing keys and values:

{
  title: “My Title”,
  # [...]
}

After migrating, the attribute values are wrapped into an Array consisting of the attribute type and the actual attribute value:

{
  title: [“string”, “My Title”],
  # [...]
}