Notes from EPiServer 7 Developer Summit

Ever since the first sneak peeks and public preview back in June, it's clear that EPiServer has undergone some major surgery, and the results were presented to an excited developer crowd in Oslo on November 1. See how Twitter reacted to #EPi7DS.

I was interested to see how the inital reactions from the vNext/Falcon sneak peek (from Karoline Klever, Stefan Forsberg, Alexander Haneng and others) have been addressed in the finished product. The main concerns back then were the new UI, strongly typed pages, blocks, MVC and the Add-on system. Are there still any unanswered questions?

The Alloy Demo Templates

Alloy Technologies has been renamed to just Alloy, and has been given a facelift. It is now a fully responsive demo site. The EPiServer team has focused on making all of the page templates use best practises instead of being quick-and-dirty demo code.

Mobile magic sold separately

One word of warning though - attention sales people everywhere. You've seen those fancy screenshots where the Alloy site is viewed with the iPad/iPhone skin through mobile Display Channels, right?

Well, EPiServer 7 in itself does not magically make your site mobile.
You still need external help like responsive stylesheets, or  (*shiver*) separate mobile-optimized templates like MobilePack.
But you knew that, right? Just making sure you don't go overboard.

The new UI - Edit mode

Update: For more on the new UI experience, see my blog post "Editing EPiServer 7 content on a mobile device". 

In EPiServer 7, on-page-edit is the default view. By clicking any visible property, an editor popup relevant to the property type appears (e.g. TinyMCE for xhtml, UrlPicker for url, ImagePicker for image, etc). Changes to the page can be previewed in real time, and changes are instantly autosaved.

Revitalising On-Page-Edit

On-page-edit has been around for a long time, but has not been the killer feature that it should be. For this to work in CMS 5 and 6, properties had to be rendered using the <EPiServer:Property PropertyName="MyProperty"...> notation. However, complex page templates and use of PageTypeBuilder often dictated that properties were rendered using <%= CurrentPage.MyProperty %> inline code instead.

On-page-editing is still primarily achieved using the <EPiServer:Property> webcontrol, but can also be achieved by decorating properties with EditHint attributes to let EPiServer know which type of editor should be used for each property. Good news for both developers who get flexibility, and for editors who can edit the same way across the whole site.

Forms editing still available

Feeling more comfortable with the old forms editing? By clicking a little icon in the corner, the properties are listed in forms style.

In fact, you have to enter this view if you want to edit elements like access rights for the page, URL/simple address, language settings, publish/archive dates etc. 

Classic edit mode

So here's a hidden gem: Classic edit mode is also included. If you enter the old URL format, e.g. "/episerver/cms/edit", you're back in the good old editing style of CMS 6:

Sharing edit view

Another fun fact: The URLs in EPiServer 7 edit mode are designed so that you can share the URL with a colleague, and after logging in they will see the exact same edit view of the page as you. Note: This doesn't seem to work in IE9. 

Design updates

Even the default EPiServer login dialog has been given a design update and a dash of color: 

The styles for the login screen come from /util/login.css, which by default is located in the EPiServer global install folder, e.g. C:\Program Files (x86)\EPiServer\CMS\7.x.x.x\application\util. Unfortunately that means if you want to re-style the default login screen, it will take effect for all sites on the server.

Decoupled UI elements

The rest of the UI however, is decoupled from the EPiServer installation. By default, styles and javascript are installed under each site:

• \VPP\MySite\Packaging\Modules\Shell\1.0.290\ClientResources\epi\themes\sleek\ for the new EPiServer7 themes
• \VPP\MySite\Packaging\Modules\Shell\1.0.290\ClientResources\epi\themes\legacy\ for CMS6-style themes
• \VPP\MySite\Packaging\Modules\Shell\1.0.290\ClientResources\epi\ and various subfolders contain the UI 

In principle this means that developers can personalize the visual theme per site without affecting other sites on the same server.

 

Strongly Typed Pages

When PageTypeBuilder was introduced, defining pagetypes and properties in code really revolutionized EPiServer development. There was much debate over whether EPiServer would adopt PageTypeBuilder. In the end, they built their own strongly typed content model.

Of course, Joel Abrahamsson shared his experiences and feedback from PTB. EPiServer also built their typed pages system very similar to PTB on purpose, so developers would not face a steep learning curve to adopt the new system. 

More on EPiServer's view on PTB and Joel's response from back in 2010.

Manual changes overrides code

Like in previous versions, it's still possible to create/change pagetypes and properties manually in admin mode. However there is a big difference:

With PageTypeBuilder, deploying code to a site would overwrite any manual changes made by editors/administrators (dubbed the "PTB tyranny" by some). 
In the new system, manual changes (the database) have top priority. This means that if there is a conflict between the code and the database, the database overrides the code.

While this will lead to less frustration and lost work amongst site owners, I fear this will lead to a lot of diffs between the project code and what actually runs in production. Keeping the code base in sync with all the manual changes on the production site will require good communication between site owner and development team.

PTB and EPiServer 7

It is still possible to make PageTypeBuilder work in EPiServer7, but the dev team have focused on making it as easy as possible to migrate from PTB to the new typed pages system. In the long run that will probably be the recommended course of action, as Joel is unlikely to continue development on PTB now that Seven is out.

Blocks

Early on, Blocks were described as a kind of property group. In the final product, Blocks are one of the key new features, essentially Composer's cooler cousin. 

Blocks are similar to WebParts, and can consist of either pre-filled content, or content created on the fly by the editor. All new blocks are initially Shared Blocks (which means they can be reused on any page) unless they are specifically bound to a specific pagetype and become "local" Blocks. 

When creating a new block type, you will automatically see a preview of how the block will look in all of your active Display Channels (if your site uses responsive design).

Blocks are not Tetris

You can't drop Blocks anywhere you like. Blocks can only be placed within block zones pre-defined on the pagetype. This means that while editors can freely choose which content to create and rearrange their order of appearance, they are not free to redefine the block zones as they please.

Savvy editors will perhaps find this limiting, while for others it will be a safety net that ensures that the design and layout remains consistent.

Will Blocks make WebParts obsolete?

At Epinova, we use the EPiServer WebPartsFramework in most of our projects. Combined with our FlexiGrid module, the editor gets a fluid, flexible layout which is not limited by pre-defined zones. WebParts can be created, drag-n-dropped and rearranged freely within this layout, and the layout itself can be redefined.

But frankly, we are still a bit undecided on the future of WebParts in EPiServer 7. We'll go think about it a bit, and come back with an awesome solution.

MVC

It was revealed in the early previews that EPiServer 7 would support MVC (3.5 at the time). But would it mean that we all had to abandon WebForms and learn MVC?

In the final product, both WebForms and MVC are supported. In fact, you can have both in parallel within a project. The advantage of this is that you can convert a site from WebForms to MVC one template at a time. 

EPiServer 7 actually requires MVC 4 and .NET 4 to run.

Project structure

When you start a new EPiserver 7 web project via the Visual Studio integration, the project is structured like an MVC project (however, the Alloy template project used the standard WebForms structure). This means that your pagetypes are organized under "Models" and your templates under "Views". This is more consistent now that the terms "PageType" and "Page" are replaced by "ContentType" and "Content". 

 

Add-on interface

When this was first announced, developer reactions were mixed. Could it be implemented without the risk of breaking a site? During the developer summit presentation, I tweeted:
"And now for the part that makes sales ppl cheer, and developers cringe: The Add-on Store". And I mean it.

In EPiServer 7, Add-ons are divided into three levels:  

• System - Core components like EPiServer edit UI, EPiServer Add-on UI etc. 
• Protected - Scheduled jobs, gadgets etc
• Public - Typed pages, blocks, templates etc. 

Risk factors

At the dev summit, Steve Celius demonstrated how it only took seconds to install the Social Reach add-on. While this apparently worked seamlessly, this add-on has been developed and tested thoroughly by EPiServer prior to release and SHOULD work flawlessly. I chatted with Steve and identified a number of pit falls.

1. Unqualified users messing around

The Add-on interface is NOT intended to be an experimental playground for eager editors. From the SDK:
"To access the EPiServer Add-on Store interface for installation, upgrading and uploading, you need to be a member of either theCmsAdmins or the PackagingAdmins role." Restricting the use of add-ons to a controlled minimum will be crucial. 

2. Corrupting critical assemblies

By design, add-ons are not allowed to write to the /bin folder of the site, thereby reducing the chance of corrupting critical assemblies. Instead, add-on related files are placed in the /modules folder and are picked up using reflection when reloading the site. 

3. Dependency mismatch

Add-ons are essentially nuget packages. Viewing the details of each add-on reveals their assembly dependencies. What if an add-on depends on a different version of the same assembly as the site?

If I understood Steve correctly, EPiServer 7 solves this by automatically upgrading both dependencies to use the newest version. While this may seem to solve the problem, there might be valid reasons why a very specific version of an assembly was used, and changing this might break functionality.

4. Manual upload

See that scary button in the upper left corner that says "Manual upload"? Yup. Users can upload add-ons from disk (provided of course they have sufficient privileges). The add-ons don't even have to come from a nuget feed. As developers you have NO control over the quality of add-ons uploaded manually by a user. For all you know, it could be something the user hacked together in his spare time. Or worse, what's stopping some malicious developer from creating an innocent-looking module, making it available on the EPiServer nuget feed (as a third party add-on), that in reality wipes your entire site? Looking forward to some potentially fun support calls on this.

5. Functionality conflict

When installing add-ons that have not been tested together before on a live site , I imagine some add-ons will cause conflicts in functionality, like two modules that both do some stuff on page events like OnCreatingPage or OnMovingPage.

6. Won't work in load balanced environments

Sites that live in load balanced environments cannot use add-ons. In these cases, the add-ons would have to be added while the site is in a single server staging environment, and then the whole package would have to be deployed to alle the load balanced servers. 

7. Will create diffs between production and code

When add-ons have been installed on a live site, those files and configurations do not exist in the code base. This creates a diff that will require maintenance.

So, while the idea of an app store is interesting, I am still very sceptical about it. The individual modules can be tested and work fine isolated, but might not play nice with every other module out there. Using a live site as a trial-and-error ground seems a bit sketchy.

 

In summary

EPiServer have covered a lot of ground in this release, rebuilt much of the core and added some exciting new features to the CMS. Some of the features will need some time to mature, while others will instantly add value to your new projects. There is definitely an excited buzz around all the new technologies like Dojo, Dijit and MVC. 

How were your own expectations met in the release version of EPiServer 7?