Saving Local Content in OSF

Introduction
In Drupal, Content Type entities are by default saved into the default field storage system, which is MySQL. This is what we call "local content". This type of content is "local" to Drupal.

What this page will show, is that it is possible to save the values of some of the [local] Content Types directly into OSF instead of Drupal. This magic is performed by the OSF FieldStorage module which creates a new FieldStorageAPI for Drupal. What this module does is to create a new kind of storage (OSF) to save the values of some of the fields (the ones that have been created using that new storage system).

What that means is that for the same Content Type entity, you may have 2 of its fields that are saved in Drupal (MySQL) and 4 of its other fields saved into OSF. Or you could have all of them in MySQL, or all of them in OSF. Everything depends on how you configure the Content Type entities.

Configuring OSF FieldStorage
Before configuring any Content Type entity using the new  system we have to configure a few settings in the OSF FieldStorage module. To access these settings, click on the top  menu item. Then, you have to click the.

Then click the  tab. Now you will see all the configuration options.


 * Change the default storage system of the Content Types to use the  system by default instead. By selecting this option, all the future field that will be created for the Content Types will be using a OSF instance as field data storage system. This means that the  storage system won't be available anymore when you will be managing your fields.
 * By default, only the field that uses the  field storage system will appear in the list of fields to be mapped in RDF under the RDF MAPPING tab. This means that only the mapped fields will be saved into the OSF instance. By enabling this option, you will see all the fields, whatever the field storage system they are using to be mapped in RDF. All the mapped fields will be saved into the OSF. This option could be used when synchronizing existing content on a Drupal instance that is no in OSF but that needs to be there.
 * Select the dataset you want to use to save all the local content you are creating from this Drupal instance. The local content is all the Content Types such as the Nodes, Articles, Pages, etc.
 * By default, only the field that uses the  field storage system will appear in the list of fields to be mapped in RDF under the RDF MAPPING tab. This means that only the mapped fields will be saved into the OSF instance. By enabling this option, you will see all the fields, whatever the field storage system they are using to be mapped in RDF. All the mapped fields will be saved into the OSF. This option could be used when synchronizing existing content on a Drupal instance that is no in OSF but that needs to be there.
 * Select the dataset you want to use to save all the local content you are creating from this Drupal instance. The local content is all the Content Types such as the Nodes, Articles, Pages, etc.
 * Select the dataset you want to use to save all the local content you are creating from this Drupal instance. The local content is all the Content Types such as the Nodes, Articles, Pages, etc.

Configuring Drupal Content Type
Now that the OSF FieldStorage is properly configured, the next step is to configure existing, or new, Content Type entities to use the new  system.

To access the Content Types, you have to click the  top menu, and then click on the   link. What you get is the list of Content Types currently defined in your Drupal portal. From there, you can manage the ones that are created, or create new ones.

The option that particularly interest us is to manage the fields of a Content Type to choose the fields that will be used to describe one of these entity, and more particularly, which FieldStorage system it should be using.

Click the  link to start managing the fields of a Content Type. In the  section of a Content Type, you can see all the fields that are defined for a given Content Type. You can add, remove or edit fields as required. Each field is associated with a. That field widget is a tool that will help the user to find or describe the right value for a field. The user interface of the original Content Type  section only slightly changed compared to what you may be familiar with. The changes are: With this new user interface in place, you can create a new field that uses the  type, or the default   type.
 * A new  columns where you can see the FieldStorage type used by the field
 * A new  used to creae a new field that uses the   type

If you want to change the storage type of an existing field, you have no other choices than deleting it and re-creating it with the new type.

If you want to create a new field that uses the  field, then you have to define a   for it, then to select a   and a. None of this is different than what you were used to with the normal Content Type user interface.

The list of supported  and   is:

When you will click the  button, you will be redirected to more configuration pages depending which field type and field widget you selected. When the new field is created, you will see it appearing in the list of fields with the  you selected at the beginning. The next essential step is to map the newly created field to a RDF property. It is this mapping that will tell the system how to save the field's information into OSF in RDF. To manage this mapping you should click on the  tab. This section will show you two things: Then for each of these things, you will be able to define how it should be mapped in RDF.
 * 1) The   of the content type
 * 2) All the   of the content type

If you do not select a type for the content type, then the default internal Drupal mapping will be used, which is. Then you have to map all the fields to different properties that are currently defined in loaded ontologies.

Once you are done mapping the fields, you can click the  button to save the mapping. Once you are done with all these steps, you can to do edit an existing Content Type record, or to create a new one and save it. Depending on the field type you choose, the information will be saved in OSF or in MySQL (or any other possible FieldStorage type).