Staging and preview is new functionality added in Magento Enterprise Edition 2.1. It makes it faster, easier and less expensive to add new campaigns, catalog updates, promotions and other changes that help keep site fresh and improve conversion rate. Ability to preview, test prior to launch and schedule when changes should be applied allow to deliver right customer experience. In this session I will give a brief overview of the functionality and talk about some implementation details.
Hi
I’m happy to see so many people in one place talking about Magento and sharing their experience.
My name is Igor, I started working with Magento in 2009 as system integrator. A little more bit than a year ago I joined Magento. I live in Austin. Time to time I attend local Magento meetups. If you have any questions, don't hesitate to ask me
My presentation is about staging and preview, a new Enterprise Edition feature that was added in 2.1 release
Hi
I’m happy to see so many people in one place talking about Magento and sharing their experience.
My name is Igor, I started working with Magento in 2009 as system integrator. A little more bit than a year ago I joined Magento. I live in Austin. Time to time I attend local Magento meetups. If you have any questions, don't hesitate to ask me
My presentation is about staging and preview, a new Enterprise Edition feature that was added in 2.1 release
I’m going to do overview of the functionality, talk explain staging architecture and talk how you can use staging framework in your module
Customers come to online stores to browse products, add products to cart, apply different types of promotions and eventually place an orders.
Content is the main part of the website and every merchant constantly maintains his store, updates catalog, adds new discounts and update CMS pages and blocks to announce new products and promotions.
Before Magento Enterprise Edition 2.1, one of the workflows for updating content and publishing new changes was as follows.
You have separate copy of the website where you make and test changes. After you confirm everything looks good you move these chang es to the live site. Sometimes you forget to migrate something and need to troubleshoot and resolve issues on live site.
Migrate everything and make sure that everything works and looks good is a lot of work.
In Magento Enteprise Edition 2.1 we added a feature that allows make changes in the single place.
You can preview changes before customers see them to make sure everything looks good.
And you can schedule when changes will be applied.
Updates being applied automatically. So, you don’t need to stay up very late until traffic goes down to roll out changes, if you have big website.
You have visibility on all planned updates with campaigns dashboard. You will see on the next slides
Staging and Preview is a critical new feature for Magento Enterprise Edition 2.1.
Why is Staging and Preview so important? For merchants, it empowers your business teams to do more to grow sales. It makes it faster, easier and less expensive to implement new campaigns, catalog updates, promotions, and other changes that can help keep a site fresh and improve conversion rates. And it allows you to do this without having to involve their IT team!
It also allows merchants to gain peace of mind that all your updates will go out at the right time and with the right customer experience because you are able to preview and test everything prior to launch. Merchandisers no longer need to go online at midnight when a new campaign is launched to confirm everything is in order.
Staging and Preview also gives much better visibility into their planned updates because they can see them all in one place. By just glancing at the timeline dashboard, you can quickly see where you may need to add more promotional activities or discover instances where programs overlap in ways that are not ideal for the business.
And all of these updates can be managed and previewed in the Magento Admin without impacting site performance – so shoppers have a great experience, even as merchandisers are actively setting up changes on the backend.
Let’s take a closer look at what the new staging and preview has to offer. With staging merchants can create, edit, and delete updates to site content, including: products, categories, CMS content and promotions
Changes can be grouped together into campaigns for easier management and merchants can schedule an unlimited number of updates.
When you edit content you can see…
On the right side of the screen, you can see an example of what it looks like to create and schedule a product change using the new interface. At the top of the page, you can see a list of all the scheduled changes to the product. You can easily preview or make edits to those changes, or schedule a new one. Below that section, you can access the product editing screen to make and save new updates to the page.
Staging dashboards gives greater visibility into campaigns. Dashboards allow conveniently see all their campaigns in one place, in either a grid view or timeline view.
This means they can quickly track start and end dates, what’s included in a campaign (like 6 product, 2 category, and 1 CMS page update), and campaign status for easy management. From the dashboards, merchants can drill in to individual campaign components to preview them, make edits, or even delete them. This consolidated view helps merchandising teams work fast and ensure they have all the information they need to create an optimal mix of campaigns and site changes.
On the right of this slide, you can see a screenshot of the dashboard grid view that shows a complete list of all the active and upcoming campaigns. If you hover over the campaign objects, you can get an overview of all the components included in the campaign.
In this screenshot, you can see the dashboard timeline view. It shows all current and upcoming campaigns on a timeline, making it easy for merchants to see how these changes may interact with each other and confirm that they have a coordinated plan in place. When they hover over a particular campaign, they can access additional detail, make edits, or preview the changes.
Staging and preview also allows merchants to preview upcoming changes to ensure that they are delivering exactly the right experience to their shoppers. Merchants can preview changes by date or by store view. As part of the preview process, they can view all checkout pages without placing an order to ensure that promotions and price changes are being handled appropriately. They can also share links to previews so other team members can easily review and approve changes.
On the slide, you can see the two different ways to preview site changes.
In the screenshot on the left, merchants can choose to preview changes by store view. They can select the store view from the pull down menu and see that version displayed below. This is a great way for a merchant to see how a campaign will be implemented across different language sites, for example.
In the screenshot on the right, merchants can choose to preview updates scheduled to run at a specific date and time.
If you are writing extensions it is important to understand how the staging work.
Especially if you want to customize stageable entity or want your extension to work with and with out staging.
Let’s take a look at big picture of staging architecture. I will talk about each of the pieces on the next slides, but let's see what are the main parts first.
In the heart of staging is database schema. Many of you probably already noticed that in Enterprise Edition 2.1 additional fields have been added to entity tables for which you can stage changes.
To manage persistence of stageable entities was introduced Entity Manager. Entity Manager is ORM that is currently used by staging only but in the future will be recommended way to persist entities.
Entity Manager uses operations to perform persistence (for instance read, create, delete). Staging has it's own implementation of these operation to perform additional logic.
In staging multiple versions of the same entity are stored in the same tables. Purpose of from condition renderer and version manager is to make sure we always get active version in application.
There is a Staging module, that contains business logic generic to all stageable entities. For instance, persistence logic or Ui elements.
And there are also modules that add staging functionality to the original modules, for instance CatalogStaging or CmsStaging.
Updates applied automatically by cron jobs. Cron jobs also perform other functions like, removing expired campaigns.
I separated configurable Ui elements from Staging module to highlight that all Ui components already in place. If you adding staging functionality to your entity, you just need to configure these components and you will get fancy Ui.
To describe changes to database schema I will use product entity as example, but the same applies to other entities.
As I mentioned earlier, in staging we have multiple versions of the same entity, and they are stored in the the same table. When you save update, the new entity will be created in database, that will became visible at scheduled time. If you take a look at catalog_product_entity you would notice that entity_id is not unique anymore, there is a new field row_id and it’s primary key now. row_id is unique identifier of the record and entity_id is a sequence identifier. Sequence identifier is the same for all versions of the particular entity.
Entity can have non stageable attributes and stageable. Stageable means that you can modify it in the future version. Attributes that are stageable linked to the main entity by row_id, attribtues that are not stageable linked by entity_id.
created_in and updated_in fields specify the version for the entity. We will talk entity version and how Magento determines the version on the next slide.
We have new table staging_update with campaigns. In this table stored versions for all of the entities in the system. You could assign multiple updates to the same version, in this case it will be campaign.
Also, every stageable entity has sequence table to be able generate unique identifier per all version of particular entity.
As I mentioned on the previous slide, created_in and updated_in fields specify version of the entity.
created_in – version from which entity is active, default 1.
updated_in – version to which entity is active, default 2147483647.
If created_in = 1 and updated_in = 2147483647, it means entity will always be active as these are the left and right margins for the verison.
As I will be talking about versions on the next few slides, lets agree that max version is 999.
In the example, we have 2 entities in the table, first entity is always active. Second entity active from version 200 to 999.
When you create update (or new version of the entity in other words) Magento saves information about the version to staging_update table.
Then at any given time, we can get the current active version using query shown on the slide.
Now we have a version and can select active updates.
Here I have table with my entity.
I have 2 products in the table, Product 1 and Product 2. Product 2 has 3 versions. There are changes to price and description.
In every moment of time we know which version is active. To continue example from previous slide, let's say current version is 200. Using query shown at the bottom of the slide we can select all active updates.
First row will be selected because it’s active from version one to infinite. Third row will be selected, because it satisfy condition by version.
Magento uses the same condition to select active versions.
There are permanent and temporary updates. Permanent update doesn’t have an end date, temporary update has.
When you create a permanent update a new record will be added the the entity table and in staging_update table. Notice that is_rollback set to 0, it will became more clear why on the next slide.
Here we create update with an end date. It’s one update, but as you can see there are 3 records in the database. After update expiries, Magento need somehow to revert the update and display previous version.
When you create temporary update, one more update being created, that will take affect after temporary update expires. This update is system update (not visible in the Ui), it is copy of entity before temporary update.
This system update is called rollback. is_rollback flag in system_update used to specify that this is rollback.
Entity Manager is responsible for persistence of the data. Currently it’s used only for staging. We are working on improvements and in the future it will be recommended way for persisting data.
Entity Manager is an entry point. It delegates all work to operations, operation use processors to persist different types of data.
Entity can be extended via extension attributes and logic for saving these attributes could be different. For this purpose relation and extension attributes processor uses handlers to persist this data.
It's very high level diagram, if you want to know more you can take a look at the code. Or ask me about it after presentation.
All parts can be configured via DI for your entity.
Create, update and delete operations overwritten for every stageable entity in order to handle persistence of updates and versions.
As we have different schema in enterprise edition, configuration for stageable entities overwritten in enterprise.
When you select entity by identifier or load collection of entities framework automatically checks if this entity is stageable. If yes, it automatically adds a condition to select active version of the entity.
So, you always get current version when you load your entity or collection.
We talked about how Magento determines current version, this is what version manager does. It determines the version.
We also talked that entity could have stageable and non stageable attributes. Not stageable attributes are the same for all versions of the same item. For instance website relation for a product is not stageable. All versions of the product A, will have the same sequence id (entity_id field in the database for a product)
We need somehow to apply updates when they became active. This being done by cron. Magento changes active version in the system, then reindexes affected entities (if they have indexes) and clear cache for them
You could have thousands of updates grouped together in one campaign. When you change date for a campaign, you need to update all these entities. It’s a lot of update operations, Magento performs them by cron.
Magento also removes old updates by cron
Preview calculates data on the fly.
When you load entity in the preview, Version Manager supplies version for which you want to preview the changes instead of current version.
If you have some precalculated data, for instance indexes, it bypasses that storage and calculate data for selected entity.
Very simple. As there is not much data to pregenerate, preview works fast.
Let’s talk about main aspects of writing a module that has staging functionality
We received the following requirements from product owner.
…
Looks like we need to create a blog module with staging functionality. I actually already did that, you will find the link to repository on the resources slide.
I’m going to submit pull requests to Magento sample-modules repo after I add code coverage and go through code review process.
On the next slides I will describe main parts of the module.
Persistence is the main part.
Module need to work in CE and EE. In EE we I created install script that alters schema
As we have different schema in EE, I overrode configuration of Entity Manager for blog post
I also configured Entity Manager to use operations from staging to handle persistence of blog post
I didn’t create any Ui because all elements already available in Magento.
I only created configuration for …
Also I implemented data providers and controllers.
The last important piece is module service contract to manage updates.
I implemented API that allows manage updates. It is only 2 methods: schedule and unschedule updates.
That is basically it.
Take a look at the code on GitHub. Ask questions if something is not clear or doesn’t work, I will try to answer.