Migration from 1.x to 2.x
This document will describe the changes in Fusion 2.0. It will highlight what is and isn’t backward compatible.
Conceptual Change
In Fusion 1.11 and before, the word layouts was used for documents acting as templates to build new content from. In Blackburn and beyond, they will be referred to as templates.
The term layout is still used and is described in more detail further down.
Structural Changes
![]() Fusion 1.11 | ![]() Fusion 2.0 |
The images above illustrates the changes to the root folder structure. Instead of ‘layouts’ there are now folders matching the individual document types currently supported by Activator:
brief
email
slide
In each of these folders there can be the following content:

In the templates folder, you would put the same files that are stored in layouts folder in 1.11 and before.
Backward compatibility note 1: If no [document type]/templates folder is available, Activator will still look for layouts folder in order to find templates.
Backward compatibility note 2: Fragments are stored in same place as before in order to ensure backward compatibility. It may however change before full release of 2.0. We will then look into moving the fragments automatically with the shared upgrade script.
Layouts and Helpers
Layout and helpers are new content types that can be stored in the shared resource and edited in Activator. They have similar structure (HTML snippets) but are used for different purposes.
This is new functionality that is not compatible with earlier Fusion versions.
Responsive Content
Fusion 2.0 greatly enhances the ability to create responsive content. The responsive config flag was introduced in earlier version but from 2.0 it will have a significant impact on how content behaves.
The responsive flag is found in shared/src/config.json file. It is not available from Activator UI.
Flag should be set to false if non-responsive absolutely positioned content is desired.
It should be set to true if responsive statically positioned content.
One shared resource should not be used for both types of content.
Note 1: it doesn’t affect emails which will always have responsive content
Note 2: we’re currently looking into how to best display to the Activator user what mode is used for the content (responsive or not).
Component Updates
Previously slides created in Activator have been wrapped in an <article class=”slide”> tag and overall slide settings have been placed on the body element.
In Fusion there is a new fusion-slide element that replaces the article tag. This element will also handle all overall slide settings, e.g. background color and image.
Backward compatibility note: Content created previously with article tag, will not work properly with a 2.0 shared resource.
Using Existing Shared Resources in Blackburn
Existing shared resource and slides created before Blackburn, will continue to work in Activator as long as the shared resource isn’t upgraded to 2.0. If upgraded to 2.0, then the body and article tags of the slides will have to be manually updated. We’re looking into automating the process but haven’t been able to yet. Our intent is to make it possible to upgrade to 2.0 without manual work, but at this time we can’t guarantee that it will work.
Upgrading Shared Resources with Auto-upgrade function in Activator
Activator provides an easy to use auto-upgrade function, but in some scenarios, a manual upgrade will be needed.
In order to auto-upgrade a SR, these following things need to be consider:
Make sure that the structure of the SR is kept as per this article details
If any changes to the structure, or any folders are missing, the upgrade function won’t work
Any changes to the src/fusion folder will prevent the auto-upgrade to work, and if any changes are done here, the only way to upgrade the SR is manually.
It is not a problem to have custom components in the SR, as long as they are correctly saved in the src/components folder.