Structuring and configuring a FirstSpirit project

1) Adding a central FirstSpirit project

To begin with, a FirstSpirit project is created containing all content and project properties needed to develop the project, e.g.:

• Users
• Presentation channels
• Languages
• Resolutions
• Modules
• etc.

2) Structuring a FirstSpirit project (recommended)

Exporting and importing FirstSpirit project content using External Synchronization should be complete and use clearly defined processes wherever possible. This helps to prevent problems resulting from incomplete project contents (in local development environments), and, as a result, conflicts.

We recommend always exporting the entire Template Store.

To make sure the referenced elements can also be synchronized with ease, they should be collected in a separate folder in the corresponding Store and become part of the synchronization process. This means that this folder must also be exported and imported during each synchronization process. When using database content, the corresponding CS2 objects also have to be exported and imported.

We therefore recommend using a project structure in line with the following schema:

Page content:

Folder that contains all pages linked to the page references used as preview pages for the templates (“Properties” tab).

The folder can also contain sub-folders.

Data sources:

All of the projects’ datasets needed for template development. A matching data source must also be exported for each dataset.

Media:

A folder that contains all media needed for development. A reference to these media is normally established on the presentation channel tabs (e.g., via $CMS_REF(media:"...")$):

• Image files for icons
• Image files for buttons
• Image files for navigation elements
• CSS files
• JavaScript files

See, for example, the Layout folder on the “Simple scenario” page. The folder can also contain sub-folders.

Site structure:

A folder that contains all page references used as preview pages for the templates (“Properties” tab).

Global content:

A folder that contains all global content referenced on the templates’ presentation channel tabs (e.g., via $CMS_VALUE(#global.gca("..."))$).

The folder can also contain sub-folders.

3) Creating local FirstSpirit projects

In a distributed development environment, each developer works in his own local development environment. Each developer uses his own local FirstSpirit Server and his own local FirstSpirit project.

The local project can be “empty” to begin with. The contents and settings can then be transferred out of the central FirstSpirit project (or remote repository) using External Synchronization.

Alternatively, the central project can be added to the developers’ local servers using the “Export project” / “Import project” (ServerManager - Menu “Project”) functions.

All of the developers and systems involved in the project must used standardized settings. This means that the local projects must have a standardized structure and identical project settings!

Why is this important? An example:

In a distributed development environment, multiple developers work on one FirstSpirit project. Using a version control system, the modified project contents and settings are distributed across multiple systems, e.g.

• in additional local development environments (“Development”)
• on a test system (“Test”)
• on a productive system (“Productive”)

If, for example, the individual systems have a different number of languages in this scenario, this will always lead to conflicts if the project property projectproperty:LANGUAGES is also transported via External Synchronization (in other words, as part of the export or import action).

In this case, a “Check-in / Export” from the development system (number of languages: 2) into the VCS and then a “Check-out / Import” into the test system (number of languages: 10) leads to content being removed for the 8 languages not included.

4) Configuring permissions

Users must hold the relevant permissions to export and import project content.

Example: If objects are created in the project during an import, the user must have permission to “Create objects” and / or permission to “Create folders”. If objects are deleted during an import, permissions for “Delete objects ” and / or “Delete folders” are required.

Some actions may require administrator permissions. Server administrator permissions are required to export and import server properties (users, fonts, etc.). At the very least, project administrator permissions are required to export and import project properties.