In yesterday’s post we covered the fact that Alfresco stopped selling the AVM based WCM solution to new customers. Existing customers using the AVM based approach will continue to receive support until the AVM reaches end of life status. New customers looking to Alfresco for WCM/WEM capabilities who read this will naturally wonder what is the approach to WCM on Alfresco. Existing customers will want to know how to migrate off the AVM and in to Alfresco’s core repository.
As we have seen in yesterday’s post, the core repository has had the benefit of continuous innovation through which it has grown as a platform now capable of supporting use cases critical to WCM/WEM with key features like remote file deployments and form based content capture. Along with features clearly directed at the WCM use cases, the core repository is host to an amazing array of features and capabilities that make it ideal for all manner of enterprise management, WCM/WEM included.
At Rivet Logic we have made a significant investment in a web content and experience management extension to Alfresco that we call Crafter Rivet. Crafter Rivet is a 100% open source, full featured application that powers 100s of websites and has over 40 man years of development effort invested in it. Initially Crafter Rivet’s authoring and management capability was based on the AVM. When Alfresco made the decision to direct the full force of its innovation on the core repository we knew it was time to covert. Just released, Crafter Rivet 2.0 is 100% based on the core repository, Solr search and Actviti workflow for Alfresco 4 CE and EE. Making the switch from the AVM to the core repository required a deep examination of our use cases and the features we would have on hand within the core repository.
Use Case: Sandboxing
As described in yesterday’s blog, sandboxing is a feature but there are use cases that drive this feature. In a Web CMS context we have times when we need to modify templates, CSS and other assets that have far reaching effects on our sites. There are three common use cases that point to sandboxing:
- Timing: On websites of significant size and complexity, there are often times when projects are created to update the look and feel of the site. These projects with future delivery dates need to be able to take place without interfering with daily publishing. Further, it’s important that the project be able keep up with on-going updates to reduce the headache of last minute merges.
- Playground: Sometimes we just want to play. Sandboxes allow us to enable team members to innovate and play around without fear of impacting the live website.
It’s clear that the ability to sandbox (or branch/merge) your website code base can be pretty handy. In my mind there are several key questions:
- Is the support for this use case a “must have” for my specific environment? How often do I run in to the use cases above?
- What granularity of sandboxing do I need?
Many popular Web content management systems do not natively support sandboxing. In a lot of cases the need for the branch merge capability is handled through the development and deployment process. In general I think it safe to say this feature is a rather strong “nice to have” unless you have an site with look and feel components which are literally being constantly updated and where the traditional development process would add too much time to the effort.
When you do need sandboxes the next question is granularity and how sandboxes are used. The AVM UI dictates sandboxes for each user. In my experience accumulated over many Alfresco WCM engagements; is that this was too fined grained for the needs of most engagements. Most users want to work directly in context with other users. They need basic locking on individual assets to keep work safe during their edits but they don’t require an entirely separate and parallel universe. The ability to create a sandbox ad-hoc for a specific purpose maps more directly to the needs we see on the ground. In other words, a sandbox is too granular but a sandbox for a project to update the look and feel of the entire site where users could work together would more aptly address the kind of needs we see.
Crafter Rivet starts with the first finding, that sandboxing is not a “must have” feature and that in-fact when it is applied it should be done so to facilitate specific projects and specific ad-hoc needs. If you look at the way we have structured our content in the core repository you will see we have left room to support one or more draft copies of the site. In v2.0 we do not support layering in the default configuration; however, Crafter Engine, our content delivery and preview tier, is able to sit over top of multiple hierarchical stores and present them as one store much in the same way the AVM did.
Use Case: History and Reversion in a Web CMS Context
As a user, when I want to preview a version of a specific asset, let’s say a page, I want to see the page as it was on that day. That means I want to see exactly the same components and assets (images, CSS, js etc) as they were on that given day. This is a real challenge in the core repository because there is no native support linking assets together under a common version; each asset is individually versioned and the links between objects (associations) do not capture version.
- In the short term because they have made a mistake, or
- in the long term because they need to revert messaging to a previous point in time.
In the first instance there is likely to be no issue. Common assets are likely going to be the same as they where at the point in time of the version. However, in the second case, we really want to see the old content in the context of the current templates, etc. If we revert, it’s to get the older content, but we’re going to deploy it in the context of the latest look and feel of our site.
Handling versioning in Web CMS is a must have, must do capability.
In Crafter Rivet we considered these use cases fully and drew a distinction between two types of relationships. Those relationships which are page only and those which are shared commonly amongst other objects in the system. When you revert a page or any other object, those relationships which are “page only” will revert to a point in time, while other relationships that are common will continue to align to the latest version of the asset.
To accomplish this we leverage both the native versioning capability of the core repository as well as file organization and patterns. In short, we organize page-only assets in folder structures that represent the page. Page objects are given names that are based on a hash of the object to guarantee a unique name which means in effect that the versioning of the page only object is “horizontal” in the repository. By horizontal I mean that a new file path is used rather than relying on the version store. Shared objects like pages or other common assets are stored regularly and rely on the native versioning support. If you revert a page you will revert to an a state where the page points to a different set of file / file paths — achieving a solution for both use cases we mentioned above.
There are several Web CMS use cases that could require snaphsots and version diffs. For example, some websites have compliance related issues and thus must maintain versions of their sites so that in the event of a dispute over information communicated via the site they can easily prove what the site looked like at a particular moment in time. The question for snapshots is:
- Is this something your organization must have?
- And if so, is it something that the repository has to do for you?
Our experience shows that this feature, for the general market, is a nice to have. Most customers don’t take advantage of this capability. When we looked at this capability in Crafter Rivet, we decided it was not important to support natively within the repository itself. If a customer needs a snapshot every day we simply include a deployment target that would produce a snapshot.
For those wondering about snapshot rollback; our experience has shown that this particular feature is really not relevant to most customers in day to day operation. The feature has come in handy as a mechanism for bailing out people who have made sweeping changes to a site (100s of files) and deployed them with little or no QA only to find a broken website after the fact. In such a case, snapshotting a rollback is a life saver. With a click of a button you can revert 100s of files.
Crafter Rivet, by design is 100% file based. In such a crisis scenario, a simple file based backup could be used to restore a Crafter Rivet based site to a former state. In the repository, you are unlikely to desire an actual rollback. It’s more likely that you will want to keep the broken state and simply fix what is wrong and then redeploy the working site.
Alfresco v4 is an incredible platform and the move to the core repository unlocks all of that capability and innovation. Crafter Rivet is a platform that made use of all of the functionality in the AVM. And with our new release, we made the move. You can as well. More importantly, if you are using the AVM with Alfresco v3 (or even V2), then Crafter Rivet is the perfect solution for your upgrade. We can provide parity for most needs with a much better user experience that goes way beyond basic Web CMS needs with the coverage of WEM use cases like integrated analytics and reporting, native mobile application authoring, preview, and presentation, content targeting and personalization, multi-channel publishing and much more. If you’re new customer to Alfresco looking for Web CMS solutions, Crafter Rivet is a comprehensive WCM/WEM solution, with features that rival some of the major players in the industry.