Image of directions signs

Alfresco WCM Directions considered harmful

Alfresco WCM may be the most volatile part of the product. Some of the changes we have seen here were quite disruptive – technically and conceptually. The discontinuation of the AVM surely is among them. It may hurt some people, but it is a good decision for the long run. On the other hand, Alfresco offers choice by its very nature as a platform. This in turn requires guidance so people don’t get lost. This post is about harmful effects of change and choice.

Web Quick Start : A misleading Name ?

To me the name suggested : „This will get your WCM project going quickly“.
That might prove to be true for some people and/or projects. But you can also get stuck, realizing that some things just don’t work as you want them to. Of course, the risk to fail can be reduced by studying in advance, but seriously:
You do things wrong the first time you apply a new technology, don’t you ?

Alfresco Web Quick Start is a best practice implementation of a „pure“ Alfresco stack WCM solution – just as Java Pet Store is one for JEE or CaveatEmptor is one for Hibernate. These applications serve educational purposes and may also be used as a starting code base for your own projects. As such, it is important to have them.

Should I use Quick Start ?

Having a best practice reference at hand can also be misleading – especially in the huge field of WCM. An Alfresco best practice implementation is not a reference how to implement WCM on top of Alfresco in general. In fact, I think that it does not make sense to build on top of it in the vast majority of WCM scenarios – even if you are building your solution in the Alfresco ecosystem. Why ? Because there may be a good chance that you will face requirements which are not sufficiently addressed – happened to me more than once. Most of my cases were related to presentation and usability.

Nevertheless, several WCM solutions have been built based on Alfresco Web Quick Start. Deckshare by Metaversant and Tribloom is one example. I have been involved in two projects. The first one was at the time Quick Start was initially released, the second one is under active development at this time.

Another import aspect to keep in mind when building on top of Quick Start is that you will „really“ fork the code. Not fork as in git, but in a way which makes meaningful merging „back to the roots“ almost impossible. Most likely, you will at least rename packages and change the model to meet your needs. Afterwards, you will be on your own.

This can be really unfortunate. Quick Start has quite a few good, reusable concepts and implementations (e.g. CMIS/REST) baked in. The fork usage pattern hinders evolution. The reusable parts would have to be extracted to common ground to truly support their own development. I would have contributed code addressing website content access security, workflow, content deployment and large volume / high traffic functionality if it was easier. The Web Producer wiki page can also serve as a „nice to have“ list for Quick Start based applications.

Quick Start Alternatives

Jeff Potts recently summarized Quick Start Alternatives to in the forums:

The alternatives to Web Quick Start are things like:
– Crafter
– Drupal + Alfresco
– Liferay + Alfresco
– Custom solution built using any language you want that accesses the repository via CMIS and/or custom web scripts

I have not used any of the first three myself, but there are some some obvious arguments for them. Drupal for example has by far the biggest ecosystem. Chances are good, something you need is available for download – and for free. Liferay may already be there and now you want advanced content management capabilities.

Crafter Rivet : The Newcomer

I became aware of it just recently. In fact it has a fairly long history and is only a newcomer in Open Source. So far, I can tell that it is huge and it delivers various pieces Quick Start does not have. The user interface is what impressed me most in Russ Danner’s webinar recording – which is a must see if you consider WCM on top of Alfresco.

So far, I only had a quick look beyond the webinar. The >500 MB download size is a bit scary. Besides, the fact that Russ explicitely highlights the AVM migration path and XML make me hope it does not come with to much tightly coupled legacy baggage.

A lot of effort has been put in Crafter Rivet, and Rivet Logic offers community and enterprise editions. They seem very serious about it.

Personally, I wonder whether Crafter practically / non educationally obsoletes Quick Start.

A Documentation Problem ?

Apart from technical diversity, I think there is a problem caused by documentation and the resources on the web. All books that I am aware of tell you to build your website on top of AVM which is fading away. I don’t know of a single one mentioning Quick Start. Imagine you are new to the Alfresco ecosystem, google for „alfresco web content mangement“, check the Wiki and the forums and ask yourself whether what you find is truly helpful.

I hope we will see convergence and shake out where it makes sense.


Andreas Steffan
Pragmatic ? Scientist and DevOps Mind @ Contentreich. Believes in Open Source, the Open Web and Linux. Freelancing in DevOps-, Cloud-, Kubernetes, JVM- and Contentland and speaks Clojure, Kotlin, Groovy, Go, Python, JavaScript, Java, Alfresco and WordPress. Built infrastructure before it was cool. ❤️ Emacs.

2 thoughts on “Alfresco WCM Directions considered harmful”

  1. I’m stuck on using WCM in v4.2 at a seriously basic level. I installed the WQS component (using the advanced installer) but I don’t see the „Web Projects“ space. Is web projects not there any longer? I am coming from v3.4 so the upgrade is really kicking my butt.

    Do you know anything that could help me or guide me?


  2. WQS shipping with 4.x is completely different technology. It really has not much in common with AVM based WCM from 3.4.

    I would still strongly recommend to validate whether any of them really delivers what you are looking for. AVM based WCM will be removed and WQS is just a bare bones „best practice“ implementation. Both approaches most likely require at least in-depth technical understanding and coding. Make sure they deliver a decent amount of the functionality needed. Otherwise, you should really be prepared to code.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.