I’m not going to lie, I’m mainly a Sitecore developer and have been working more with Sitecore than EPiServer. But I’m going to try to be objective and set aside my personal preferenses in this comparison. I will begin to compare the core installations of both CMS platforms without any modules and with be using the latest current releases of both platforms, Sitecore 6.6.0 rev 130214 and EPiServer CMS 7.0.586.1, so lets begin.
Installation
The installation process differs between the both. When it comes to Sitecore, you have to run an installation file to install the Sitecore framework, and then the installation is pretty much self contained. It doesn’t install files anywhere else than in the folders selected, which makes it easy to move to another folder or server. EPiServer have a different approach, when you install EPiServer you start with installing a deployment tool where you can choose to install multiple versions of EPiServer and modules and later deploy a new site based on one of the installed EPiServer version and prep it with modules available, which is great. However this approach makes moving the site a little harder since a deployed site depends on binaries installed under program files on the server. But if you have multiple sites on the same server the core installation takes less space since the sites share alot of files.
There is a tool much like EPiServer deployment tool that you can use for Sitecore aswell which doesn’t require you to install any application. It’s a self contained .exe file which, when you execute it, you have to point to a folder containing Sitecore installation files. With this you can then install a Sitecore installation with extra modules in one go. You can read more about it here
Issues:
For some reason I had some issues after installing EPiServer, when logging in the admin UI the UI seemed to miss some styles and images and when checking, /App_Themes/Default/Styles/ToolButton.css, /App_Themes/Default/Styles/system.css and some images reported 404 Not Found. I found a virtualPath configuration in the EPiServerFramework.config and it seemed to be correct but didn’t work, so I copied the App_Themes folder form the shared library in program files and now it works.
I’ve also had some issues installing EPiServer in folders starting with underscore (_)
Loggin in
On a fresh installation of Sitecore, you use the default admin account admin/b, all security is handled isolated from the computers security using .Net membership. So implementing a different membership provider is possible if necessary. When logging in you are presented to log directly in to one of three modes, desktop mode, content editor and page editor.
On a fresh installation of EPiServer you log in using the computers account, and I think it has to be a member of the administrators role. This can be reconfigured to be isolated from the servers security or to mix it. EPiServer also uses .Net membership framework so implementing a custom membership provider is possible.
First look
Sitecore
When loggin in to Sitecore as a developer, I prefere to use the Desktop mode, since it ease the access to multiple sources and databases simultaniously. The desktop mode looks like this.This is basically a window manager where you can open up multiple “applications” at the same time, making it possible to open several items at the same time for example you can edit templates at the same time as you are editing an item based on that template.
The main application used in Sitecore is the Content Editor which makes it posible to edit anything item-related, wether it’s the site structure or the template which the items in the site structure is based on or adding images to the media library.
EPiServer
When logging into EPiServer you arrive at the dashboard where you can build up a custom view of modules. I’ve never used this myself, but you could potentially add modules displaying page views, visits, pages ready for publish and so on.From the dashboard you can reach the Edit mode and the Admin mode which will be of most interrest for a developer since this is where you build the site.
Templates and PageTypes
Templated and PageTypes are basically the same, it’s a representation of a data object. It could be a representation of a page, spot or other types of data. In previous version of EPiServer the PageType was tied with a presentation, a .aspx file, and you couldn’t create a PageType without connecting it to a apsx file, but now they seem to have changed that which is good.
Field and Properties
In EPiServer a PageType consist of Properties which can be structured in Tabs, the tabs are global for all PageTypes and are created in the Config section.
In Sitecore a Template consist of Sections and Fields and unlike EPiServers PageTypes, the sections are individual to the templates.
Sitecore Template Editing
EPiServer PageType Editing
Field Types and Property Types
EPiServer has lots more Property Types than Sitecore. The reason that EPiServer has more Property Types it that there are several properties that does the same thing but has different limitations such as a String property that allows a maximum of 255 characters and another Long String property that allows more that 255 characters. I Sitecore there is no limitations on the Field Types, this is handled by validators that are configured on the template when you have created a field based on a specific Field Type. Both Sitecore and EPiServer allows you to create custom Property Types and Field Types. I don’t know if this is easy in EPiServer but in Sitecore it a little bit tricky and you will probably have to use Reflector or other decompiling software to check the structure of existing fields since there is little documentations on this.
Inheritance
It is also possible to inherit fields from another template in Sitecore which makes it possible nicely structure chunks of fields and reuse them. For example you can create a template containing all fields required for standard content like Title, Image and Body, and inherit that into multiple templates that needs these fields, for example a standard sub page, news page, product page and so on. If you alter the name of a field in the base template, it will also change in all templates that inherit form that base template. This is something that makes the work run faster. Unfortunately this is missing in EPiServer.
Security
In both Sitecore and EPiServer it is possible to restrict who can edit a page, create an Item based on a template or Page based on a PageType. Unlike EPiServer, Sitecore has taken it one step further, and make it posible to restrict who can edit specific fields.
Insert page and item
Both EPiServer and Sitecore allow for customising what Template/PageType can be added as child for a Template/PageType, however Sitecore has more flexibility. Using the Rules Engine in Sitecore, you can define more detailed rules for when you can add a page based on a specific template and what names are allowed and much more.
In Sitecore you can also define branches for insert. A branch is a predefined structure of pages that can be added.
Presentation
This is where one of the bigger differences are between EPiServer and Sitecore. EPiServer uses the ASP.NET standards with Web Form and MasterPage, where the MasterPage has ContentPlaceHolders and the Web Form has Content sections and links to a MasterPage. Once you have created a PageType and connected it to a Web Form (.aspx file) that’s it, it doesn’t seem like you can make any exception on any pages based on that PageType and use a different Web Form without having to change it on the PageType itself.
Sitecore does this different and way better. In Sitecore you define Layouts which links to a Web Form file (.aspx) and Sub Layout which links to Web User Controls (.ascx). These Layouts and Sub Layouts are then using placeholders you basically puzzle them together to form a presentation on the Template. This presentations can then be overridden on the page that is based on the template for special pages that doesn’t really require it’s own Template. This allows for a lot more customisability.
Security
Both Sitecore and EPiServer utilizes the .Net Membership framework with customised membership providers. On a new installation of EPiServer you have the possibility to either use the servers users and roles, users and roles stored in a SQL database or to use both. Sitecore only have users stored in a SQL database. They both allow you to develop your own membership providers as well.
The security in EPiServer is a little bit flat, it only allow you to create users and roles, assign roles to users and configure security in the site tree based on either user or roles. In Sitecore you nest roles so that one role inherits security rights from several roles which allow you to split up the security over several roles and reuse them. This makes it more flexible and easier to create more complex security configurations. I find that the tools in Sitecore for configuring the security is better, for example the Access Viewer where you can get an view of how the security settings affects a user or role in the content tree and the Security Editor where you edit the security in the same manner.
Preview and Publishing
This part is handled very differently in Sitecore and EPiServer, in EPiServer a version is flagged as published when you publish it, which should work fine. I think this has been somewhat fixed in EPiServer 7 but in EPiServer 6 you couldn’t check if you were in preview mode, and the framework for getting child pages didn’t take this in consideration either so pages that wasn’t published didn’t show up in the menus when previewing the page, which is kind of strange.
Sitecores solution to publishing is to have 2 databases, one Master database that you edit in, and then a Web database that you publish to. All changes made are added to a publish queue so that you don’t have to copy the entire Master database to the Web database. When previewing the site sites context is set to use the Master database insed of Web. It is also possible to configure multiple publishing targets, so that you might have 2 web databases to publish to.
Page Editing
Both Sitecore and EPiServer allow the editor to edit directly on the page, however the approach differs some, and to be honest I kind of like the way it’s done in EPiServer 7. In EPiServer 7 the page editing is more integrated in the way you mainly edit the page. When in the standard Edit mode, and browsing the site structure you get a preview of the page where the editable content is highlighted with a borde to indicate that it’s editable. When clicking the editable content an edit box appears on the right side. If you rather like to edit the fields in the old fashion style, you can switch to the field mode with one click.
In Sitecore you either edit in the Content Editor where you edit the fields or you open the Page Editor where you only edit the content on page. You can configure Edit frames which opens up a dialogue with a collections of fields. Unlike EPiServer 7, where you edit the content in a box that show up to the right in the windows, you actually edit directly on the page in Sitecores Page Editor. This is great since you see how the content will look like while typing. If EPiServer 7 had this as well, EPiServer would have the best editor experience.
Page designing
In Sitecore it is possible to allow editors to add elements to the page. This is done by configuring placeholders with placeable sub layouts such as spots, sliders or maybe a contact. The sub layout can be configured with a folder path and a required template which allows the editor to either use an existing item in that folder based on the required template or create a new item which will contain the content for the element. Since the sub layout has a configured datasource to an item and that item can be reused, if you want to make any changes, you only have to alter one item and it will change all sub layouts that uses that item. As mentioned before it is possible to restrict what layouts that are possible to add in the placeholder, but you can also configure security on top of this so that some users can only add specific layouts
EPiServer have a similar functionality previously called “Composer” in EPiServer 6 which was an extra module. In EPiServer 7 they have built in a “Composer” like functionality. In EPiServer 7 you define blocks and Content Areas and where you can place blocks. You can also easily drag a page to the content area and it will create a teaser of the page. It is also possible to create global blocks which can be added to several pages and only needs to be updates in one place. I’m not to familiar with this functionality but I can’t find if it’s possible to copy a block with content unless you have created a global block. It doesn’t seem to be possible to restrict what blocks can be created in a Content Area, so if you add a block which is to wide for the Content Area the design get messed up. It doesn’t seem possible to configure security on the block either so that some users can create specific blocks.
Media Library
Both Sitecore and EPiServer have a media library, but they work differently. In Sitecore the media library is handled exactly like everything else, all uploaded media gets attached to an item which is based on a templates. The files are stored in the database and when retrieving the media it is cached on the server in that size it was retrieved in. It is easy to get the image from an image field and handle the image like resizing and cropping using Sitecores framework. It is possible to upload several files simultaneously and also upload a zip archive containing folder structures and files.
EPiServer media library is detached from the content tree and is handled as files on the disc. What is both good and bad is that each page has its own library, so that you don’t have to upload some media that is only required for one page to the global library. However by default when selecting media from the editor, the local library is opened by default, and with out thinking you have uploaded an image to that pages local library even though you were going to reuse it. It doesn’t seem to be possible to upload multiple images simultaneously. There is however a module ImageVault that creates a new media library with more features, but it requires a license.
Customisation
Since I’m haven’t developed that many sites using EPiServer let alone EPiServer 7, this section will mostly be about Sitecore.
GUI
Sitecore in it self is built upon Sitecore. As I mentioned before Sitecore has a Master database where you edit the site, and a Web database to which you publish you changes and the visitors see. On top of this there is a Core database which contains Sitecore it self, all applications, buttons in the applications and controls. So if you would like to change or add a button in the Content Editor, you manage this in the Core database just like you would with your site in the Master database.
Pipelines
Pipelines are a serie of processors that implement functions for example to publish an item or to build up the sitecore context when requesting a page. Each pipeline is easy to modify through the web.config file and new processors can be added. Pipelines are kind of complex and I will not dig in very deep here, but if you would like to read some more about it, I’d refere to John Wests article on the subject. This is what the pipeline for publishing an item looks like:
<publishItem help="Processors should derive from Sitecore.Publishing.Pipelines.PublishItem.PublishItemProcessor">
<processor type="Sitecore.Publishing.Pipelines.PublishItem.RaiseProcessingEvent, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.CheckVirtualItem, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.CheckSecurity, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.DetermineAction, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.PerformAction, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.AddItemReferences, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.RemoveUnknownChildren, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.MoveItems, Sitecore.Kernel" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.RaiseProcessedEvent, Sitecore.Kernel" runIfAborted="true" />
<processor type="Sitecore.Publishing.Pipelines.PublishItem.UpdateStatistics, Sitecore.Kernel" runIfAborted="true">
<traceToLog>true</traceToLog>
</processor>
</publishItem>
Events
Much like Pipelines you can also hook into events that Sitecore triggers by creating a event handler and define it in web.config for the specific event. There are tons of events that you can hook up to and do your own thing. For example if you would like to do something when someone saves an item in Sitecore, you implement your handler and add it inside the event definition in web.config. This is what the configuration for an event looks like:
<event name="item:deleted">
<handler type="Sitecore.Links.ItemEventHandler, Sitecore.Kernel" method="OnItemDeleted" />
<handler type="Sitecore.Tasks.ItemEventHandler, Sitecore.Kernel" method="OnItemDeleted" />
<handler type="Sitecore.Globalization.ItemEventHandler, Sitecore.Kernel" method="OnItemDeleted" />
<handler type="Sitecore.Data.Fields.ItemEventHandler, Sitecore.Kernel" method="OnItemDeleted" />
<handler type="Sitecore.Rules.ItemEventHandler, Sitecore.Kernel" method="OnItemDeleted" />
</event>
Commands
As mentioned before in GUI, Sitecore is built in the Core database. Almost all buttons that exsits in all applications in Sitecore is defined in the Core database. Many of these buttons triggers something called a command which is defined in a config file which is imported to the web.config. If you’d like to change the behaviour of a button that use a command, either you create your own command, and change the button to use that command. But sometimes many buttons uses the same command and it’s preferred to change the command it self which is done byt changing what class is run for that command.
Summary
Over all I find that Sitecore is more customisable and contains more functionality out of the box. EPiServer requires extra modules to get close to what Sitecore base installations gives. However EPiServer 7 editor mode feels easier to use with the preview mode as the main way to edit compare to Sitecore where you have to jump between content editor and page editor. If Sitecore had a Page Editor tab in the Content Editor so that you easily could switch between page editor and field editor it would be great. And if EPiServer 7 had inline editing on the page instead of opening a editor to the right it would also be great.