Magnolia Employee Blogs

Magnolia CMS in 2011 – another amazing year

Boris Kraft — Thu, 26 Jan 2012 14:39:00 GMT

2011 has been another incredible year for Magnolia. From 4 people in 2006 we grew to 28 employees (plus a handful of externals) at the end of 2011. Read on for some insight into what has happened in 2011.

A lot has been achieved last year even though for the first time in our history we did not release a new version of Magnolia. This is surprising on one hand; on the other it shows just how far we have come. Quite a number of maintenance releases have been published. Version 4.4.5 probably set a new record at Magnolia, with fixing nearly 100 issues. And we do have Magnolia 4.5 in the making, which will be released at the end of February 2012 and all things considered is possibly the biggest effort we have ever put into a single release.

Two years ago we set out to change one aspect about Magnolia in particular: its documentation. Our documentation team has grown to three persons. Documentation has been a full blown success. Where 2 years ago we would get bad comments about our lack of documentation, today we get positive feedback up to the level that decisions for Magnolia are made because of the quality of documentation. The statistics do reflect this: in the last 12 months we had a stunning 70% growth in unique visitors to our documentation site. During the same time, our corporate site traffic has grown by 17.5%.

Business has reflected our strong position. Worldwide, the number of license subscriptions has grown by 32% last year. Our expansion efforts in the USA resulted in an astounding 60% growth in license subscriptions for Magnolia Americas, which now holds 20% of our subscriptions worldwide.

Notable Client wins in 2011:

Atlassian, USA
Autorité des Marchés Financiers (AMF), France
Basler Versicherungen, Schweiz
Bundesrechenzentrum GmbH (BRZ GmbH), Austria
Editora Meio & Mensagem Ltda., Brazil
FOXTEL Channels Group, Australia
Leroy Merlin España S.L.U., Spain
Lufthansa Systems Network Services GmbH, Germany
MBC, Middle East (Dubai)
Michelin Brazil, Brazil
Scientific Learning, USA
Sheffield City Council, UK
Zumba Fitness, USA

(Links added where sites are already live and/or publicly visible). We now hold an astonishing 7% of the worlds global 100 enterprises as our customers, and fully expect this number to grow much higher in the coming years.

Furthermore, in 2011 we have added the following new partners:

Cross Agency
Fast Forward
Priocept
Serviceplan
T8y
Tribal DDB
Ventiv
VML

In terms of Facebook Likes, we have seen 57% growth and have 830 fans today. Our Linkedin group has 241 members, with nearly 70% growth last year.

We held our first two webinars in 2011, wrote 8 new case studies, won a Red Herring Top 100 Europe Award, are a sponsor of the Web Experience Management Interoperability (WEMI) standard at OASIS and added an arabic landing page (www.magnolia-cms.ae). A whopping 64 (prev: 40) blogs entries have been written by Magnolians this year to help spread the word and our support team has solved 554 issues, 62% more than in 2010.

Our biggest goal for 2012 is the release of Magnolia 5. For 3.5 years we have designed and redesigned Magnolia's next UI. Last year we have seen a new phenomenon: iPads take the enterprise by storm. Apple recently stated that 93% of Fortune 500 companies either test or already deploy the iPad. This has made us change our plans for Magnolia's future UI in mid 2011, and by the end of 2011 we finally had the breakthrough in interaction design we have all been waiting for. Magnolia 5 will be the first CMS on the market that has been designed for touch. This is tremendously exciting and will be a watershed event for us.

All our efforts will be focused on not only delivering the product but also to be ready for the opportunities that Magnolia 5 will create for our business. Obviously we will need to grow, and our growth will bring changes. We will ensure that these changes will not happen by accident, and that our growth remains manageable.

Luckily our financial position is excellent. Magnolia has no external obligations. We are independent in every aspect, where most competitors are either part of larger corporation (e.g. Fatwire (Oracle), Day (Adobe)) or have financial dependencies (e.g. venture capital). Others depend on services to finance their product development and in this way compete against their partners. Magnolia on the other hand has a sustainable license model that ensures a steady cash flow without competing against our partners.

We have great plans for 2012, which will be a really busy year for all of us. As you can see from this review, we are in pole position to make 2012 a year to remember. I am looking forward to it.

PS: Join us. You will like it.

Picnik for collaborative screenshots

Antti Hietala — Tue, 17 Jan 2012 13:13:00 GMT

Update! Picnik is closing on April 19, 2012. This is sad news. I really liked working with the product. Please sign the Don't Close Picnik petition! A subset of Picnik features is available in the Google+ Creative Kit but, crucially, the Photo Bucket is not. This means that the custom circles and arrows we use to annotate images are gone.

At Magnolia, we recently started using Picnik to annotate screenshots. We wanted a casual but obvious way to draw the reader's attention to an image detail. In this post I explain why we chose Picnik and how it is working so far.

Picnik is a photo editor that runs in the browser. You may have seen it as the embedded photo editor in Picasa Web Albums. The requirements that drove us to a Web-based tool were:

No OS lock-in. We have technical writers working on Windows 7, Vista and Mac OSX. It is difficult to find a screenshot tool that works on all those platforms. Skitch is awesome on the Mac but a Windows version is still only hearsay.
Consistent annotations. Annotations are the circles and arrows we add to screenshots to draw the reader's attention to whatever it is we write about. While any screenshot tool can take a plain screenshot, adding consistent annotation shapes is difficult unless everybody uses the same tool. Documentation ends up looking amateurish and poor if the shapes are not consistent.
Casual, hand-drawn look. We wanted a casual, edgy look. Straight lines and rectangles are difficult to see on a UI that already has lots of straight lines. They also look incredibly boring. If you annotated something on a piece of paper, you would grab a pen and circle it. That's the look we wanted.
Shared storage. Web-based tools promise cloud storage. Why should everybody take the same screenshot when a perfectly good example exists in a shared library? Why draw your own arrows with a shaky mouse if there's a nice-looking arrow in the toolbox?

I must emphasize that Picnik really isn't a screenshoot tool. It's a photo editor whose features are clearly geared towards processing photos. It's great for assembling favorite shots into a Christmas card but for taking a screenshot you still need a local tool, which is fine for us.

Picnik features we love and curse

Uploading an image is a snap. The image is opened in the editor immediately so no unnecessary browsing is needed. Besides upload, you can open an image from Flickr, Facebook and several other popular services.

Resizing to new dimensions works as expected. The quality of the reduced image is not as good as if you used Photoshop. The image is fuzzier, which can be a problem. Text in a screenshot must stay sharp and readable in smaller size too. To get around the issue, we either crop to the relevant area or keep the shot full-size. Modern browsers do a very good job at resizing in the viewport, certainly no worse than Picnik.

Canvas as a concept does not exist as in Picnik. When you need more room around the image, add a border. The border can be any color and width. Make it white and you effectively have a bigger canvas.

Shapes. I drew a collection of annotation shapes by hand in Skitch and saved them as PNG files. Then I uploaded them into a Picasa Web Album that is visible in the Photo Basket in Picnik. Now anybody in the team can drag-and-drop symbols onto an image. This solves the requirement that all writers use the same symbols to produce a consistent look and feel.

Text. Picnik has a huge variety of fonts to choose from. They are very hip and cool, which means they are perfect for a scary Halloween photo but not so great when you need readable text. We chose a font called Just Me Again Down Here by Kimberly Geswein. It's a good compromise between hand-drawn look and readability. We matched the font size to the shape stroke width.

Sharing and layers are my biggest grievance with Picnik. I asked on the help forum why sharing is so weird. Bottom line: edits are stored on the image owner's Picnik account and are not accessible to other users. This means that while you can save an image to a Picasa Web Album, other team members won't be able to edit it. The image is flat to them. This is a shame because picking up from where another use left would be fantastic. As for the shapes, we put them in a common Picasa account which all technical writers register in their Picnik. So at least the shapes are available to everyone.

So there you have it. Picnik works for us now. Drop a comment if you solved similar requirements in your team with something else.

Twitter-style character counter for textareas

Antti Hietala — Mon, 16 Jan 2012 14:32:00 GMT

In this post I show how to improve textarea usability with a Twitter-style character counter.

Validating form input length is a common strategy for reducing errors. So common in fact that the HTML specification provides a maxlength attribute for input fields. Starting with HTML5, multiline textarea fields support the attribute too!

Since it is always better to prevent an error than catch one the user already made, here are two ways to improve textarea usability in Magnolia CMS, making sure the user knows how many characters are allowed.

Display the character limit

The obvious improvement is to display the character limit. In Magnolia CMS, you set the limit on the form field. The system saves it to a maxLength property in the repository.

Render the length on the page:

Copy the formEdit.ftl script which renders input controls.
Create folder Templating Kit > Templates > /form/paragraphs.
Create a new template script formEdit and paste the copied script into it.
Render the maxLength property in the textarea element on line 21.
Render it visibly to the user: ${content.maxLength!'50'}
Enable the script and refresh the Contact form page.

Twitter-style character counter

How does the user know they are approaching the limit? jQuery Charcount plugin adds a Twitter-style character counter. As the user types text, the plugin counts unused characters. When a limit is exceeded, the counter turns red.

Start by downloading the jQuery Charcount plugin kit:

jQuery.js is the core jQuery script. Magnolia CMS already has it.
charCount.js counts the characters and draws the counter.
CSS styles sets the alarm color.
01.html is an example page.

Step 1: Add the Charcount script as a resource

Go to Templating Kit > Resources > /templating-kit/js/all.
Under all, add a new JavaScript resource charCount.
In the Advanced tab, set Extension to js.
Paste the downloaded charCount.js script into the charCount item.
Change line 35 to read the textarea ID from the element:
var available = $(obj).attr('maxlength') - count;

Step 2: Warn when 10 characters are left

Copy the document.ready function from the example 01.html file.
Paste it in the charCount script before the closing })(jQuery); line.
Change #message2 to textarea. We are getting the IDs dynamically.
Set the warning to 10.

The end of your script should now look like this:

$(document).ready(function(){

//custom usage

$("textarea").charCount({

warning: 10,

counterText: 'Characters left: '

});

})(jQuery);

Step 3: Make the counter red on warning

In /templating-kit/themes/pop/css, create a new sheet charCount.
On the Advanced tab, set Extension to css.
Set Model Class to info.magnolia.module.templatingkit.resources.STKResourceModel.
Paste the following style in the Content box:

.form-wrapper div span.warning {

color:red;
font-weight:bold; !important
}

Step 4: Include the new style in the theme

In Templating Kit > Themes > /pop/cssFiles, copy styles to charCount.
Set link property to /resources/templating-kit/themes/pop/css/charCount.css.

Step 5: Try it!

Reload the Contact page. Now the page has a counter that starts counting back from the limit.

Type some text into the box. When 10 characters are left, the counter turns red.

Resources: The Code for Faceted Search Navigation

Sean McMains — Wed, 28 Dec 2011 21:22:24 GMT

In my last post, I discussed the data-capture portion of our new Resources page on our corporate site. Now I’d like to get into the code for the page to show you how things are done. The main template for the page is pretty much a standard STK template: There are a couple of interesting [...]

Git at Magnolia

Grégory Joseph — Wed, 28 Dec 2011 18:02:31 GMT

You might have heard or read about it, Magnolia is finally moving to Git. The main reasons for this move are the pains of merging and branching (i.e we just don’t branch as much as we should because Subversion makes … Continue reading →

CMIS support for Magnolia CMS

Tobias Mattsson — Wed, 28 Dec 2011 16:48:00 GMT

This autumn I've had the opportunity to work on implementing CMIS support in Magnolia CMS. CMIS stands for Content Management Interoperability Services and is a specification administered by OASIS. The goal is to improve interoperability between content management systems and it achieves this by defining a model representing the content in a repository and a set of services for accessing it. The services come in two flavors, SOAP Web Services and REST-style services using ATOM-format.

The first version of Magnolia to have CMIS support will be 4.5. The scope of the first release is to expose the DMS in Magnolia over CMIS. This means that you will be able to download, manipulate and store content in Magnolia and access Magnolia content in other CMIS enabled systems.

The implementation is based on OpenCMIS. An open source framework for implementing both server and client -side implementations. It's one of the libraries developed by Apache Chemistry. Of special interest to us is the server binding to JCR. OpenCMIS implements the services which delegates to a binding. We have extended the JCR binding to match the repository layout we use in Magnolia and integrated the OpenCMIS authentication mechanism to use our security model.

In the process we encountered a few things we wanted to improve to make OpenCMIS adaptable to our repository layout. We developed this and contributed patches that were accepted by the active and focused team working on OpenCMIS. As a result our implementation is quite minimal and mainly consists of mapping the CMIS model onto our JCR layout. The value of OpenCMIS is impressive, an entire stack with both SOAP and REST that only needs to know how to interact with the specifics of a JCR layout.

The source code for the Magnolia CMIS Module is publicly available as always.

Rendering Paragraphs with AJAX, Part III: Autocomplete example

Teresa Miyar — Mon, 19 Dec 2011 12:35:00 GMT

In Rendering Paragraphs with AJAX Part 1 and Part 2 I showed basic examples of using AJAX in paragraphs in Magnolia CMS. In this last post, I demonstrate how to create a predictive search for contacts and how to render a contact's details when it is selected.

The end result looks like this, hoping it motivates you to read the whole post :-). It is a new paragraph that contains a text box. You type a contact name in the box and the paragraph starts listing matching contacts from the directory.

When you select one of the contacts, a contact paragraph is rendered, displaying full contact information from the directory.

What is needed to achieve this? A paragraph, a model class and of course a nice jQuery Autocomplete widget. The last bit is what makes this example so simple to create.

Paragraph script

The paragraph script looks like this.

 [#assign cms=JspTaglibs["cms-taglib"]]   
 [#include "/autocomplete/paragraphs/macros/ajax.ftl"]  
 [#-- TODO This link and script MUST BE MOVED to a file into the theme --]    
 <link href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css"   
    rel="stylesheet" type="text/css"/>  
 <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js">
    </script>
 <script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/jquery-ui.min.js">
    </script>
 [#-- End TODO --]
 [#assign contentLink= mgnl.createLink(content)!]  
 <script>  
 jQuery(document).ready(function() {  
    jQuery("input#autocomplete").autocomplete({  
       source: function( request, response ) {  
          jQuery.getJSON('${contentLink}', {term : request.term}, function(data) {  
             response(data);  
             });  
          },  
       select: function( event, ui ) {  
          jQuery.get('${contentLink}', { uuid: ui.item.uuid},function(data) {  
          jQuery('#ajax').html(data);  
          });  
          return false;  
          }  
       });  
    });  
 </script>  
 [@cms.editBar /]  
 <div>  
    Find Contacts: <input id="autocomplete" />  
    <div id="ajax">  
    </div>  
 </div>

Note that the links to jQuery UI cannot be placed directly in the script as I have done here. The code above is just a demonstration so you can see what files are needed. See jQuery Autocomplete documentation for details.

The paragraph script renders an input field that has an ID autocomplete. The source for this field is a JSON object provided by the paragraph model via an AJAX call. The JSON object provides contact names starting with the string you type in the input field. When a contact is selected, a second AJAX call asks the paragraph model to render a contact paragraph using the UUID of the selected item.

Autocomplete paragraph model class

The paragraph model class for autocomplete looks like this.

 public String execute() {  
    String uuid = MgnlContext.getParameter("uuid");  
    //first it will run the autocomplete  
    if(StringUtils.isEmpty(uuid)) {  
       return renderAutocomplete();  
    } else {  
       return renderParagraph(uuid);  
    }  
 }

There are two method calls in the execute method:

renderAutocomplete returns a JSON object of contact names and UUIDs.
renderParagraph renders a contact paragraph for the selected UUID.

renderAutocomplete method

The renderAutocomplete method looks for the contact information by givenName and then constructs a JSON object with two fields, label and uuid, and sends it to the response.

 private String renderAutocomplete() {  
    String autocomplete = "";  
    String repositoryId = "data";  
    String dataType = "Contact";  
    String propertyName = "givenName";  
    String term = MgnlContext.getParameter("term");  
    if(StringUtils.isNotEmpty(term)){  
       String statement = "//element(*, "+ dataType +")[jcr:like(fn:upper-case(@"    
          + propertyName + "),'%" + term.toUpperCase() + "%')]";  
       Collection<Content> nodes = QueryUtil.query(repositoryId, statement , "xpath");    
       autocomplete +="[";  
       Iterator<Content> it = nodes.iterator();  
       while (it.hasNext()) {  
          Content node = it.next();  
          autocomplete += "{ \"label\":\"" + NodeDataUtil.getString(node, propertyName)   
          + " " + NodeDataUtil.getString(node, "familyName") + "\", \"uuid\": \"" 
          + node.getUUID() +"\"}";  
          if(it.hasNext()) {  
             autocomplete += ",";  
          }   
       }  
       autocomplete +="]";  
       try {  
          MgnlContext.getWebContext().getResponse().getOutputStream().print(autocomplete);  
          } catch (IOException e) {  
            // TODO Auto-generated catch block  
            e.printStackTrace();  
       }  
       return RenderingModel.SKIP_RENDERING;  
    }  
 return super.execute();  
 }

renderParagraph method

The renderParagraph method is bit more complex because what we want to render is of type Contact. Instead of using the renderParagraph method from MagnoliaTemplatingUtilities, we have to render it using ParagraphRendererManager.

 private String renderParagraph(String uuid) {  
    String repositoryId = "data";  
    String paragraphName = "contact";  
    Content ajaxContent = ContentUtil.getContentByUUID(repositoryId, uuid);  
    if(ajaxContent != null) {  
       try {  
          if (ajaxContent != null && ajaxContent.isNodeType(ItemType.CONTENTNODE.getSystemName())) {  
             MagnoliaTemplatingUtilities.getInstance().renderParagraph(ajaxContent,   
                MgnlContext.getWebContext().getResponse().getWriter(), paragraphName);  
          } else if(ajaxContent != null && !ajaxContent.isNodeType(ItemType.CONTENTNODE.getSystemName())) {  
             //this bit of code is needed as content is not a contentnode, is a datatype from data repo.  
             Paragraph paragraph = ParagraphManager.getInstance().getParagraphDefinition(paragraphName);  
             ParagraphRenderer renderer = ParagraphRendererManager.getInstance().getRenderer(paragraph.getType());  
             renderer.render(ajaxContent, (Paragraph) paragraph, MgnlContext.getWebContext().getResponse().getWriter());  
          }  
       } catch (RenderException e) {  
          // TODO Auto-generated catch block  
          e.printStackTrace();  
       } catch (IOException e) {  
          // TODO Auto-generated catch block  
          e.printStackTrace();  
       }  
    }  
    return RenderingModel.SKIP_RENDERING;  
 }

Contact paragraph model class

For the Contact paragraph, I just used the one provided by STK and changed the model to get the content from the UUID provided.

 public String execute() {  
    String uuid = MgnlContext.getParameter("uuid");  
    if(StringUtils.isEmpty(uuid)) {  
       uuid = getContent().getNodeData("contact").getString();  
    }  
    HierarchyManager hm = MgnlContext.getHierarchyManager(DataModule.getRepository());  
    if (!StringUtils.isEmpty(uuid)) {  
       try {  
          contact = hm.getContentByUUID(uuid);  
          } catch (RepositoryException e) {  
             throw new RuntimeException(e);  
       }  
    }   
    return super.execute();  
 }

Download the code for this example from the Magnolia SVN. It is just a working sample to demonstrate this functionality and might be removed at some point so better grab it quick!

Follow-up on Magnolia User Group in Prague

Grégory Joseph — Wed, 14 Dec 2011 15:41:06 GMT

On November the 24th, almost 3 weeks ago, a few lucky people met in Prague, Czech Republic. The second ever Magnolia User Group meeting was held. Chances are you heard about it if you follow Magnolia posting, but please read … Continue reading →

Rendering Paragraphs with AJAX, Part II

Teresa Miyar — Tue, 29 Nov 2011 13:50:00 GMT

In Rendering Paragraphs with AJAX Part 1, I showed a basic example of an AJAX paragraph in Magnolia CMS. We loaded an paragraph via an AJAX call and rendered it on the page.

Now we will see how to send parameters on the AJAX call and display changes by using the model class.

For a use case, suppose you have to display a large amount of content. To make the content easier for the user to browse, you add pagination. You only want to update the paginated content when the user clicks a Previous or Next button.

You need a way to tell the server what page the user is currently on. The server can then provide the previous page or the next page. In order to do this you need a model class, a paragraph definition and a Freemarker template script (.ftl file).

Template script

Add the following code to your Freemarker template script:

[#assign pageIndex = model.pageIndex]
<script>
function next() {
    jQuery.get('${ctx.contextPath}${content.@handle}.html', 
{index: '${pageIndex}'}, 
 function(data) {
         jQuery('#ajax').html(data);
     });  
}
</script>
<div>
   Page: <span id="text">${pageIndex}</span>
</div>
<a href="javascript:next();">NEXT</a>
</div>

The content paragraph to be rendered is inside the div element that has an ID ajax. The script assigns the value that comes from the model method call to a variable pageIndex. In the script, an AJAX call reloads the current paragraph, passing a new parameter index with the value we assigned earlier.

In a nested div element, we write the current value of the variable on the page.

On the last line, we create a NEXT link that the user can click. The click will execute the AJAX call, run the paragraph model, and return the new pageIndex value.

Model class

Now let's see what the model class looks like.

public String execute() {
        
    String index = MgnlContext.getParameter("index");
    if(StringUtils.isNotEmpty(index)) {
        pageIndex = Integer.parseInt(index) +1;
    }
    return super.execute();
}

public int getPageIndex() {
    return pageIndex;
}

The class has two methods:

Overridden execute method that reads the parameter we sent by clicking NEXT and adds 1 to pageIndex.
getPageIndex method to retrieve the value of the member variable pageIndex.

Paragraph definition

The rendered NEXT button looks like this on the page.

Blossom 1.2.3 & Blossom Data Extension 1.0 Released

Tobias Mattsson — Tue, 22 Nov 2011 14:42:00 GMT

Today I have released version 1.2.3 of Blossom and Blossom Data Extension 1.0, an extension for using Blossom style dialogs with the Magnolia Data Module. It introduces a new annotation @DataTypeDialogFactory which is used for creating dialogs for data module types. It has the same feature set as @DialogFactory and is used in the same way.

In this release the feature set TabBuilder is expanded adding support for the multi select control, the include control and for adding any control by type. It's now also possible to get the dialog and the DialogCreationContext from the TabBuilder.

This is an example of how a dialog used for the type 'category':

@DataTypeDialogFactory("category")
public class CategoryDialog {

    @TabFactory("Settings")
    public void settingsTab(TabBuilder tab) {
        tab.addEdit("name", "Name", "");
        tab.addEdit("maxResults", "Max results", "");
    }
}

To use the Data Extension you need to add it to your pom.xml

<dependency>
  <groupId>info.magnolia</groupId>
  <artifactId>magnolia-module-blossom-extension-data</artifactId>
  <version>1.0</version>
</dependency>

Add this line to your blossom-servlet.xml or equivalent.

<bean class="info.magnolia.module.blossom.extension.data.DataDialogExporter" />

And if you're using classpath scanning you'll also want to add an include-filter for the new annotation.

<context:component-scan base-package="package-containing-dialogs" use-default-filters="false">
  ...
  <context:include-filter type="annotation" expression="info.magnolia.module.blossom.extension.data.DataTypeDialogFactory"/>
</context:component-scan>

For more details see the Blossom Data Extension wiki page.

Webinar - How US Navy used Blossom to integrate Spring Applications with Magnolia CMS

Tobias Mattsson — Mon, 07 Nov 2011 15:50:00 GMT

I have some exciting news to share!

As many Blossom users are already aware, Campbell Ewald used Magnolia CMS and Spring Framework for building navy.com. On November 15th there will be a webinar on how they did it and how Blossom made their app integrations straightforward. It will be hosted by Campbell Ewald's Matt Dertinger, Magnolia's Sean McMains and myself.

The webinar is for Spring developers of all levels and you will learn how to develop content rich websites with Spring. It will take you through setting up your project and with examples show how Blossom solved real use cases for the navy. Matt will also show how they used it with RESTEasy and took advantage of Bean Validation (JSR-303).

Register now, I've been told it's starting to fill up already.

See you there!

UPDATE
The webinar recording is now online.

Mobilize your Magnolia Final Result

Samuel Schmitt — Wed, 02 Nov 2011 22:39:14 GMT

In the previous post of this series, I explained how to provide from a website running on Magnolia 4.4 a mobile website. The result was already acceptable but we found a lot of drawbacks. Now, in this second sprint I will try to solve the drawbacks with “easy” workarounds and to provide an even [...]

Rendering Paragraphs with AJAX, Part I

Teresa Miyar — Thu, 27 Oct 2011 12:35:00 GMT

Ever wondered how to reload just some paragraphs on your page? Imagine you have pagination and you want to reload just the paginated paragraph when clicking previous/next? Is Magnolia CMS capable of this without complex coding? Yes, and on this post you will find some ways of achieving this.

First thing to know is, since Magnolia CMS version 4.x paragraphs are autorenderable. What does this mean? It means you can copy the path of a paragraph, paste it in the address bar of your browser and you will see the paragraph rendered. Try the following URL from our demo site, it will render the teaser of the Article page.
http://demo.magnolia-cms.com/demo-project/main/00.html

What can you do with this? It means you don't need to create a servlet or anything to render a paragraph dynamically on a page. Just a call to the appropriate script will let you load any paragraph on our page.

Here is a sample using JQuery. Add this code into a .ftl file. You also need to create a paragraph definition and add it to be used in a template.

<script type="text/javascript">
function loadArticleTeaser() {
  jQuery.get('${contextPath}/demo-project/main/00.html',function(data) {
    jQuery('#ajax').html(data);
  });
}
</script>
<div id="ajax">
</div>

<a href="javascript:loadArticleTeaser()">Load Teaser via AJAX call </a>

The JQuery call (http://api.jquery.com/jQuery.get/) will get the specified URL and, on success, will run the method that loads the result (paragraph) from the AJAX call into a div with ID "ajax". To run the whole thing you just need to click the "Load Teaser via AJAX call" link.

This is a basic sample of an AJAX paragraph. In the next post you will see how to send parameters and process them in the paragraph model class.

Don’t deploy Magnolia: deploy your project.

Grégory Joseph — Tue, 25 Oct 2011 18:37:41 GMT

In the previous episodes of this series of posts, we have built a Magnolia CMS-based project, and learnt about how to make it self-configurable. It’s deployable as-is, in your container of choice, but it is not production-ready: for example, you … Continue reading →

Fun with MooWheel

rah003 — Thu, 20 Oct 2011 01:28:28 GMT

Did you ever tried to visualize dependencies between pages on your average website? If so, you probably know what kind of pain it can be. The relations tend to be messy and any kind of chart displaying them is not easy to read.

The other night I was looking for some charting library and run across MooWheel.

Using the Wheel for rendering the deps you get reasonably readable chart for smaller site and something colorful and nice to look at for the big ones.

The only drawback I found so far is that size of generated canvas grows with the size of the site and at some point it will just not fit any screen you have around. Does anybody know of any good JS library for rescaling rendered canvas or for redirecting output of JS rendering into image?

I'll probably include rendering of this chart as part of the admin UI for Content Dependencies module of Magnolia so that you can generate such charts for any kind of Magnolia powered site.

Some food for the eye:

Enjoy,

Jan

Attachment	Size
demo-project.jpg	116.58 KB
demo-project-w-hierarchy.jpg	162.44 KB
demo-features.jpg	125.96 KB

Ever heard of REDbot?

rah003 — Mon, 17 Oct 2011 13:50:49 GMT

Somebody shown me the tool called Red Bot the other day. The tool will check the headers of responses sent by your server, the compression of the content during transfer, server clock as well as modification dates claimed by your content. The info it gives about each page of the site is broken in 3 sections - General, Content Negotiation and Caching.

When I saw the tool, I thought it might be useful to provide this information to admin directly in Magnolia, to be able to check on each and every page while browsing the site.

Magnolia RedBot integration module is what I came up with during my 20 hours long flight last week.

Module let you to check the site using the REDbot, and stores the results within Magnolia, exposing them as additional column in the Website tree.

Additionally it can also produce tree map from the results either in TM3 format for the TreeMap browser developed by University of Maryland for the overview of your whole site or in Google TreeMap format for interactive browsing of the results. And of couse one can also browse the raw results directly in the Data Module.

The results are not retrieved just-in-time, but instead to speed up the browsing and lower the load on the site, they are periodically refreshed using the scheduler.

Here's few examples of how the results look like when seen via Tree browser:

and via Google Tree Map:

If you think this might be useful for your Magnolia powered site, feel free to get the module snapshot and install it. By default it contains results of analysis ran against the demo-project so if you have instance with STK and demo-project laying somewhere around you can try that as well.

If by any chance you find out you like the module and want to make it better, let me know and you can get the commit rights for it ... or you can just contribute patches as usual.

Resources:

Enjoy!
Jan

Attachment	Size
redbot-treeview.jpg	101.07 KB
redbot-gtreemap.jpg	103.35 KB

Mobilize your Magnolia First sprint

Samuel Schmitt — Mon, 17 Oct 2011 09:04:02 GMT

After this short introduction, we are ready to build our first mobile website with Magnolia EE. Why using the entreprise edition? I need the Extended Templating Kit module which provides multisites features (you will see later why). This post is a bit technical, so if you don’t know well Magnolia CMS, I recommend you [...]

Mobilize your Magnolia

Samuel Schmitt — Sun, 09 Oct 2011 16:34:41 GMT

Few weeks ago I did a prototype with Magnolia EE 4.4.4 illustrating how to “mobilize” a website. In the upcoming posts, I will explain what I did and then you will be able to provide a mobile version of your website running on Magnolia. But before starting 2 remarks: First, to understand the next [...]

Hi everyone, take a seat… It’s my first blog post!!

Samuel Schmitt — Tue, 27 Sep 2011 19:46:57 GMT

Finally my website is updated with this new blog section. First I really would like to thanks my girlfriend, she followed my “requirements” and did a great design, I would like to link to her website but this one is not done yet, even not planned (maybe one of my next projects). But for sure, [...]

Resources: Capturing Data for Faceted Search in Magnolia

Sean McMains — Tue, 27 Sep 2011 15:38:27 GMT

As you Magnolia-watchers have doubtless noticed, there’s a new section on the Magnolia corporate website: Resources, a faceted search directory of media assets that are available through our site. The new page makes it easy to plow through a ton of available content to find what you want to see, and we’re pretty proud of [...]

Tips & Tricks: Make activation comment mandatory

Teresa Miyar — Tue, 27 Sep 2011 10:32:00 GMT

With this tip, you can make everybody to write a comment when they send an activation request, though I cannot guarantee that comment would be meaningful!

Step 1. Set property required=true in activation dialog.

Step 2. Add the following code to the saveOnClick property of the dialog.

if(document.getElementById('comment').value != '')  {window.close();opener.mgnl.workflow.WorkflowWebsiteTree.submitActivation($('mgnlFormMain'));} else {alert('Must write a comment for activation.');}

Don’t configure Magnolia: let your projects configure it.

Grégory Joseph — Mon, 12 Sep 2011 16:30:15 GMT

In the previous installment of this series of posts, we have created a new Magnolia-based project, including a reproducible build. We have a webapp that can be started in an IDE, or outside of it. You might remember we added … Continue reading →

Don’t build Magnolia: build your projects.

Grégory Joseph — Mon, 05 Sep 2011 09:56:41 GMT

This is the first of a series of posts, where I will attempt to consolidate a set of practices for creating, building and deploying Magnolia projects. Why, you ask ? Over time, Magnolia has grown into a fairly complex, but … Continue reading →

Creating site navigation from data nodes

Teresa Miyar — Mon, 29 Aug 2011 09:34:00 GMT

This solution has been implemented for Magnolia Shop Module (contributed by fastforward).

The aim is to create menu navigation based on nodes in the data repository. The navigation should be displayed on an existing site as section navigation. This way, when you navigate to the section, product categories defined in data repository will be used as items in the vertical menu.

Note that the breadcrumb is also updated with the product categories.

Assuming we know how the default navigation works in STK, we do the following:

Create customized navigation classes. One class will provide the navigation model and the second will define the navigation item that provides us with the item title and URL.

See ProductCategoryNavigationModel and ProductCategoryNavigationItem as examples. The getItems method returns the relevant nodes from the data repository. Constructor parameters for both classes depend on what you need for your implementation. In this particular case the parameter is specific to the shop, the shop name, so that we can create a correct link from the data repository.

Create a template model class that instantiates the customized navigation and assigns the model class to our template. Doing it this way, you keep the default navigation for all site content that is not part of the shop.

See ShopSingletonParagraphTemplateModel where the navigation is instantiated.
```
public ProductCategoryNavigationModel getProductCategoryNavigation() {return new ProductCategoryNavigationModel(getCurrentShop());}
```
As we are also customizing the breadcrumb, look at the getBreadcrumb method as well where items from the data repository are appended.

Once we have the model class ready, we add it to our template configuration

Freemarker templates.

We optionally need a new verticalNavigation.ftl.
The only change in vertical navigation is to call our custom navigation that we created with a new name:
```
[@renderNavigation navigation=model.productCategoryNavigation /]
```
And we set the template file in the site configuration of our custom template definition:

Three Ring Circus: Making Content, Code, and Configuration Work Together

Sean McMains — Wed, 24 Aug 2011 14:39:26 GMT

Since I started working at Magnolia, I’ve been asked one question over and over, more than any other: “Can I please have some money?” This is because I’m a father. The next most common question I’ve been asked, however, is this: “I have content authors writing content on my production system. I have developers creating [...]

Opening the door to semantic search in Magnolia

Grégory Joseph — Thu, 18 Aug 2011 17:49:34 GMT

In the past couple of months, by pure coincidence, we have been in contact with two independent companies providing semantic search services. Less coincidentally, customers have been asking for semantic search features in Magnolia for months. Trending topic ? Yeah, … Continue reading →

Adding extra styles files to an existing theme

Teresa Miyar — Tue, 12 Jul 2011 13:16:00 GMT

The question raised when creating a new module: how can I add the styles files of my module to the pop theme?

This guide shows how to add the installation task and how to bootstrap the content, but if you don't want to code anything, at the end of the blog there is an explanation on how to do it directly on the author instance:

Step 1, Create the new styles file i.e. myextrastyles.css

Step 2, Put the file in the module resources folder following STK theme structure, src/main/resources and the path shown in the following screenshoot:

Step 3, Add an installation task on your module versionhandler.

protected List getExtraInstallTasks(InstallContext installContext) {
final List installTasks = new ArrayList();
installTasks.addAll(super.getExtraInstallTasks(installContext));
installTasks.add(new InstallResourcesTask("/templating-kit/themes/pop/css/mystyles.css", 
   "processedCss", STKResourceModel.class.getName()));

Step 4, Update the theme configuration. In order for the theme to find the new style file, the file has to be configured in the theme configuration.

Step 5, Export the configuration of our file shown in Step 4. Once exported you can place the file (config.modules.standard-templating-kit.config.themes.pop.cssFiles.myextrastyles.xml)
in the bootstrap folder of your module.

NOTE: All this can be achieved without any code, you just need to set the file in the theme configuration (Step 4) and upload this new styles file into the resources workspace.

"Open Source" a differentiator no more

Boris Kraft — Wed, 29 Jun 2011 07:46:00 GMT

There is an interesting discussion around a recent blog post by Matt Aslett of the 451 group. (they do churn out great articles, don't they?).

Matt notes that "Open Source" as a differentiator is being dropped by more and more commercial open source projects, and backs it up with some anecdotal evidence. This of course caught my interest, as I have been discussing this topic internally at least for the last two years… and we made the decision to change the communication, and currently work on defining a new tagline (away from "Simple Open Source Content Management").

So yes, the trend is clearly there. Open Source is neither a primary value proposition nor a primary differentiator (anymore, if it ever was). Simply put, just because software is open source doesn't mean it works for you.

You would not differentiate your product as "the closed source alternative to X", would you? So why the other way round?

As a product and business models mature, realities change. When Magnolia CMS started with an "Enterprise Open Source" business model in 2006, this model was in its absolute infancy. It worked for Red Hat, but that was about it. We regularly had to educate prospects about the viability of our business model, not always successfully so. (For those interested, Magnolia CMS has been growing 50% per year since 2006).

Today "vendor-driver Open Source" or "Commercial Open Source" or "Enterprise Open Source" have become mainstream. It has become clear that the oversight, direction and long-term view of a vendor has benefits for an Open-Source project, and for these benefits to materialize, a revenue stream that finances the product is essential. This in turn has lead to companies looking at Open Source no longer as "Free (of cost) Software" but as "Software with a lower TCO and higher flexibility".

Once you realize this change in customer perception, dropping open source as a differentiator or value proposition is only the logical next step.

For Magnolia CMS, this will mean we'll focus more on communicating primary business values to our customers.

Having a strong community to share your knowledge, ideas and gripes, as well as ask for or provide help will make a great difference in how enjoyable your daily work with a product like Magnolia CMS is. And sharing or learning from extensions that others provide certainly is a big part of an Open Source community.

Being able to understand and quickly adapt the code of a product that needs to be integrated and adapted to custom needs as much as a Content Management System does, is incredibly beneficial for any company.

But the fact that Magnolia's source code is open should be the deciding factor only once all other things are equal. In our daily interactions with customers we learned that for them, Magnolia is foremost a great product (and great company), and only then Open Source.

Magnolia CMS, Red Herring Award and entrepreneurship

Boris Kraft — Wed, 01 Jun 2011 07:01:00 GMT

When I first came across Red Herring, it must have been the late 90's or early in the new millennium, I thought this is a very interesting magazine. And when I saw companies being listed as a Red Herring 100 winner, I was hoping to one day be amongst them.

Fast forward to 2011, and Magnolia has reached that milestone. Will this change everything? Hardly. Earth will still rotate around the sun (unless you are a creationist, in which case it probably is the other way round); and all the world will not suddenly flock to Magnolia's website to try out our content management system.

But. And here is the "but": when you start out to build a business, you (hopefully) do so with a good reason (why are you doing this?) and dreams (what do you want to achieve?). And while your dream my be to write the best content management system on the planet, there are smaller, more tangible aspirations, which are often inspired by what you see elsewhere. The Red Herring award was such an aspiration, and that is why Magnolia (and myself) have reached another milestone.

For entrepreneurs, hitting such milestones is a confirmation that they are on the right track, that their aspirations can be fulfilled and their dreams eventually become reality.

For future entrepreneurs I hope you have your own dreams and aspirations, no matter how big or small, and that they too may come true for you.

And should the Red Herring Award be one of your aspirations, I encourage you to aim for it. Alex, founder of Red Herring, is certainly an interesting person to meet, modest but with great experience. He likes to give advise and simultaneously tells you that 90% of the advise anybody will give you is not going to help you. And meeting fellow entrepreneurs, people with ideas, ambitions, success or failure under their belt, certainly is a thing to aim for.

So here is one piece of advise you can take or leave: next time there is a Red Herring Award, apply for it. And even if you don't, or don't make it to the finalists, much less the winners, go there. The event is open for technology entrepreneurs, and if you are open to meet like-minded people, to exchange ideas or just learn about what others are up to, the Red Herring event is an excellent venue.

Top 5 Reasons I’m Looking Forward to Magnolia 5

Sean McMains — Tue, 24 May 2011 19:30:24 GMT

I’ve been working with Magnolia for a number of years now, and have seen it evolve from a great idea without much meat on its bones to a rich, flexible CMS that can be used for a huge variety of tasks. Even in its current mature state, however, there are areas that can still be [...]

Open Source 2011 Survey sees flexibility as driver

Boris Kraft — Wed, 18 May 2011 09:15:00 GMT

The Open Source 2011 Survey (answered by 455 participants, 60% non-vendors) has lead to some interesting results.

I would like to highlight the question "what makes open source software (OSS) attractive". Here are the three main drivers that make OSS attractive from a customer's perspective:

Freedom from Vendor lock-in
Lower costs
Flexibility

"lower costs" no longer dominates the list like it has in the past 3 years. This year "freedom from vendor lock-in" is the number one attraction of open-source software. And it is the first time that "flexibility" is in the top three.

For Magnolia that plays right into our value proposition:

no vendor lock in, since our customers have access to the source code, can choose between a large network of implementation partners, and we support open standards so it is easy to move on should you want to (incidentally, our customers prefer to stay with Magnolia once they have experienced the difference great software can make to their business results and staff's happiness)
Lower costs has moved down from the top spot, and it should. Magnolia competes on value, not (licensing) price. Which doesn't mean we don't provide an excellent deal – Magnolia's Standard Templating Kit will significantly reduce your total cost of ownership, and no matter what we charge for Magnolia, the STK benefits alone outweigh the price.
Flexibility – a recent independent analyst report has found Magnolia CMS to be the most flexible CMS system on the market (free download after registration). This is no coincidence. We know that every customer has different needs, and we know that the web is evolving faster than I can type this blog. It is only natural we ensure Magnolia CMS can easily be adapted to every whim of your marketing boss, integrate with every legacy backend that is powered by electricity and incorporate the latest fad printed in glossy magazines typically read by your CEO in trans-atlantic business class flights.

If you want to learn more about the Open Source 2011 Survey results, the 451 group has a report you can download from their website (registration necessary)

Twitter and Spring Social in Magnolia

Tobias Mattsson — Sun, 08 May 2011 19:40:00 GMT

Tweets on 'summer' embedded in a page.

Integrations with social networks are everywhere. All the big social sites offer javascript widgets that you can easily drop into your pages and display things like recent tweets, facebook likes and so on. Though recently there's been some voices raised saying that these widgets sometimes don't blend nicely with the design of the rest of site. I've seen this especially on cms blogs reviewing high profile sites as they launch or relaunch with new designs.

So, last weekend I decided to find out how much work it would take to display a Twitter search using Spring Social with Blossom, the Spring integration for Magnolia CMS. Magnolia calls reusable components that you can snap into a page paragraphs. I wanted a paragraph that an author could add to any page to show relevant tweets about its topic. The author supplies the search query and the maximum number of tweets to display.On the right is the end result.

Twitter provides a RESTful API that can return JSON or ATOM. There's a lot of functionality in there and most of it requires OAuth authentication. For this example we'll do a simple search which doesn't require authentication. Spring Social offers an OAuth implementation that is compatible with Twitter and seems to be minimal effort to use. A twitter search using the API is done with a request like http://search.twitter.com/search.json?q=summer. Spring Social uses RestTemplate and parses the response using Jackson to return plain java objects representing the tweets.

Since Blossom is an extension of Spring Web MVC that lets Spring controllers be embedded into the content of a page the twitter search paragraph is implemented as a controller. The interface provided to the author to enable filling in the search query and the maximum number of tweets is provided by Magnolia using dialogs. By adding methods in our controller and annotating them Magnolia will call them when the dialog is to be displayed and for validation when its submitted. The view for displaying the tweets is a JSP.

In the source below you'll see that Spring Social makes things really easy since it will request the Twitter API and return the tweets with just one line of code.

@Controller
@Paragraph("Twitter")
public class TwitterParagraph {

  @RequestMapping("/twitter")
  public String twitter(ModelMap model, Content content) {

    String query = content.getNodeData("query").getString();
    int maxResults = Integer.parseInt(content.getNodeData("maxResults").getString());

    TwitterTemplate twitterTemplate = new TwitterTemplate();
    SearchResults searchResults = twitterTemplate.searchOperations().search(query, 1, maxResults);

    List<Tweet> tweets = searchResults.getTweets();
    model.put("query", query);
    model.put("tweets", tweets.subList(0, Math.min(tweets.size(), maxResults)));

    return "twitter";
  }

  @TabFactory("Settings")
  public void settingsTab(TabBuilder tab) {
    tab.addEdit("query", "Query", "Search phrase on Twitter");
    tab.addEdit("maxResults", "Max results", "Number of tweets to display at most");
  }

  @TabValidator("Settings")
  public void validateSettings(DialogTab tab) {
    if (!StringUtils.hasText(tab.getSub("query").getValue()))
      AlertUtil.setMessage("Query must not be empty");
    if (!NumberUtil.isPositiveInteger(tab.getSub("maxResults").getValue()))
      AlertUtil.setMessage("Max results must be a positive number");
  }
}

If you haven't used Magnolia or Blossom before this screenshot might be helpful to see what the dialog presented to the author looks like. The methods annotated with @TabFactory and @TabValidator are used to provide the user interface and validate the input.

And here's the source for the view.

<h2>Twitter</h2>
<div>Recently about <a href="http://twitter.com/search/${query}">${query}</a></div>
<ul class="tweets">
<c:forEach items="${tweets}" var="tweet">
    <li>
        <div>${tweet.text}</div>
        <div class="signature">
            <img src="${tweet.profileImageUrl}"/>
            <a href="https://twitter.com/${tweet.fromUser}">${tweet.fromUser}</a>
            <div class="date"><fmt:formatDate value="${tweet.createdAt}" pattern="d MMM HH:mm"/></div>
            <div style="clear:both;"></div>
        </div>
    </li>
</c:forEach>
</ul>

So how much work was it? I think I spent less than an hour setting it up and writing the java code, followed by a couple of hours on the view and css to get it decent enough to show in a blog post ;-)

To try it out you need to add their milestone repository since Spring Social has still to reach its 1.0 release. Here's the maven snippets you'll need.

<repository>
  <id>org.springframework.maven.milestone</id>
  <name>Spring Maven Milestone Repository</name>
  <url>http://maven.springframework.org/milestone</url>
  <snapshots>
    <enabled>false</enabled>
  </snapshots>
</repository>

<dependency>
  <groupId>org.springframework.social</groupId>
  <artifactId>spring-social-core</artifactId>
  <version>1.0.0.M3</version>
</dependency>
<dependency>
  <groupId>org.springframework.social</groupId>
  <artifactId>spring-social-twitter</artifactId>
  <version>1.0.0.M3</version>
</dependency>

Pushing Magnolia: Creating a Command

Sean McMains — Mon, 02 May 2011 19:17:02 GMT

When Magnolia CMS is set up normally, it generates content on a page-by-page basis as it’s requested. The HTML is never written out to the filesystem, but is generated on the fly by the app and then cached in memory. This “pull” approach has a number of advantages: content is only rendered when it’s actually [...]

Magnolia Apache Solr integration

Federico Grilli — Tue, 19 Apr 2011 20:07:00 GMT

Last week I finally released the magnolia-solr-module on Magnolia's Forge. The module aims at bringing Apache Solr outstanding search features into Magnolia. For those who don't know Solr:

"Solr is the popular, blazing fast open source enterprise search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, rich document (e.g., Word, PDF) handling, and geospatial search. Solr is highly scalable, providing distributed search and index replication, and it powers the search and navigation features of many of the world's largest internet sites."

Solr is used by some of the largest companies in the world such as apple, ebay, zappos, gettyimages and salesforce, to name just a few. Recently The Guardian (which has the second highest readership of any on-line news site after the New York Times) has chosen Solr for its content API.

The reason for integrating Magnolia and Solr is a very simple one: have the best open source tool for a given task do the job. In my case, I like to manage and publish contents with Magnolia CMS (of course, I am biased towards Magnolia ;)) and its easy to use, intuitive interface, and then index and search those contents with Solr.

In the step-by-step tutorial accompanying the module I explain how to achieve this. There I also explain how to customize the module in case its default behavior does not suit your needs.

So, if you need blazing fast search for your Magnolia-based website, give the module a go and enjoy Magnolia+Solr integration!

Oh no, I've become creative

noreply@blogger.com (Andreas Weder) — Mon, 18 Apr 2011 14:41:00 GMT

Seen in Amsterdam in the Parkhuis de Zwijger, a platform fostering creativity and innovation. I found this especially funny, since a conference on online B2B marketing took place at the time I took this picture - plenty of folks in suits around me.

The 10 most important features of a CMS

Boris Kraft — Mon, 18 Apr 2011 09:12:00 GMT

In a recent blog post entitled "Features Impacting Open Source CMS Selection " we learn that 3,365 people answered the question: “When selecting a CMS, how important are the following features?" as part of the latest Water & Stone report on open source content management systems.

79.7% of the participants in the survey were from small to medium-sized businesses (less than 100 employees, so the answers might not translate directly to Magnolia EE customers who are typically a tad larger (e.g. EADS, Johnson & Johnson, Unilver and the US Navy). Still, there are many Magnolia Community Edition users that fit the bill, and so let's have a look of how Magnolia stacks up on the 10 most important features a CMS should have.

Flexible User Permissions – nearly 70% of respondents think this is very important. So does Magnolia, of course, which not only allows you to create ACL's Groups and Roles but also supports external authorization and authentication via LDAP and NTLM. All content in Magnolia is stored in a JCR-170 repository, which means all content is protected through access control.
Open API – covered: read the Magnolia API.
Search Engine Optimization – Magnolia and especially its best-practise Templating Kit (STK) got this aspect covered extensively, starting from friendly URLs to support for the Sitemap protocol. We even have written a 30-page Magnolia SEO tech brief describing how to apply search engine optimization (SEO) to enterprise websites by employing best practices together with the built-in tools in Magnolia CMS.
Content Tagging – since Magnolia 4.1 we allow you to categorize content using Magnolia's Content Categorization module. Watch the video showing you Magnolia's content categorization (this feature is shown starting at 9:09 minutes). There is also a community modules for tag clouds that takes a different approach.
Configurable Workflow – well covered thanks to our integration of a third-party workflow module. Workflow is documented on our official documentation page. WHile most people get along well wit Magnolia's out-of-the-box 4-eye-workflow, there are nearly no limits to what the underlying engine can do.
Content Versioning – yes, Magnolia CMS creates versions of content and includes a diff view to see the differences between them.
Social Media Integration – provided via Frisbee, a Magnolia module that provides
- Google Map (v3) integration (single and multiple markers)
- Flickr Slideshow, with custom query builder (tags, full-text search, author based search..)
- Facebook integration (SDK, iLike, meta tags, reading values from page properties)
- ShareThis and AddThis integration
- Twitter integration (last tweets, tweet this, retweet)
Multi-Lingual Support – coming from Switzerland, we breathe multi-lingual. For an example, see Sony's Singstar site. Magnolia CMS also allows you to export content into a translation-office friendly XML file to externalize content translation.
Multi-Site Management – read the case study how Texas State University is running 300 sites on Magnolia CMS. Magnolia's best-practise Templating Kit provides multi-site support in the Enterprise Edition.
Mobile Publishing – Magnolia CMS has always been output-format agnostic, and while we currently ship no demo templates to show how content could look differently on mobile devices (a rather trivial exercise), Magnolia's STK demo shows how content is rearranged based on available screen estate (example starts at 5:30). Also, you may be interested to learn that Texas State University has an excellent Magnolia-powered iPhone app for their students; and recently voters in Switzerland very able to view voting results via a Magnolia-powered iPhone app.

Well, this concludes my little roundup of how Magnolia CMS supports the features Water & Stone's asked readers to rate in their survey. I think these are quite interesting, but note that readers had to rate these preselected 10 features, so it could be that some features are even more important (they just weren't on the list).

Magnolia recently won what is very likely the biggest Open Source CMS license deal on the planet. The feature that made the customer decide for Magnolia in the end? The fact that Magnolia didn't crash under high load, unlike the last remaining (closed-source) competitor on their short list.

And what about ease-of-use?

"We chose Magnolia CMS because it is easy to use for both our staff and our users." - Silke Radlherr, Team Leader, SWM

To learn how Magnolia's ease-of-use helped a $7B Utility Build its Brand on the Web, read our case study about SWM.

And to read what our users think about Magnolia, read the testimonials.

Magnolia Conference Call for Papers & registration open

Boris Kraft — Thu, 14 Apr 2011 13:20:00 GMT

We have launched the new Magnolia Conference site, and are now accepting proposals for presentations. This is the third time we do the Magnolia Conference and judging the success of the last two, you don't want to miss it. As in the last two years, we'll start with a partner day on Wednesday September 7th, followed by the public part of the conference on 8th & 9th.

This year we'd like to hear more from our ever growing list of successful customer projects, and I fully expect that the business track will be packed with cool stuff and interesting case studies. The technical track will certainly be surprising as well - last year we have seen presentations about Spring integration, Konakart integration, Ruby on Rails integration to name but a few. Also Joonas of Vaadin fame did show you what makes the Vaadin GUI framework so attractive.

Speaking of which, this year's conference will finally see Magnolia 5 and its new Vaadin-powered GUI. This will of course be the biggest reason to join, and I for one look forward to sharing the excitement with you. If you haven't done so already, be sure to check out our Magnolia 5 space on the community wiki, where you can track our ideas and comment on them.

If you care for a glimpse of what the conference is like, check out the 2010 Magnolia Conference archive. JBoss's community Manager Mark Newton calls this

one of the best Java CMS events I've been to

which is a really nice way of saying that you'll enjoy your stay.

If you register before the end of April you pay half the price of registering in September, so if you know you want to come, don't hold back. We also plan to offer developer workshops regarding Magnolia 5, details to follow. Workshops will cost extra, and be limited in availability. As a thank you for you early birds, conference ticket holders will get notified first.

So now, either register or submit a proposal for a presentation - in either case we'll be happy to see you at the Magnolia Conference 2011.

Magnolia CMS 5.0 - Milestone 3

Philipp Bärfuss — Wed, 13 Apr 2011 15:00:00 GMT

The new UI architecture and framework is built! Finally we have a solid fundament and feel that we are on the right path. We urged to have a more final AdminCentral though, but decided not to rush into anything and didn't want to build upon something half-baked. As a result we can now present an extraordinary customizable and pluggable UI.

Watch our technical video featuring a short demo of the milestone 3, some architecture slides and a sample customization module:

In the next milestone we will focus on the page editing and templating. Naturally we will also catchup on the AdminCentral and dialogs to round over the impression.

Coupons with Imaging module

Antti Hietala — Tue, 05 Apr 2011 19:30:00 GMT

In this post I show you how to create coupons using the Magnolia Imaging module. I start with a background image and overlay the special promotion text. Campaign specific details are managed in the Data module while static text is configured in the Imaging module.

Let's start by registering an image generator. For this purpose I use the ImageOperationChain generator since it allows me to execute multiple image operations one after the other. My image operation chain will be called coupon and it outputs PNG files.

The first image operation in the chain, loadImage, loads a background graphic. I am using the ClassPathImageLoader class which can retrieve an image from the classpath. (You can also load from DMS, website or external URL.) By default, a Magnolia webapp's classpath includes any JARs in /WEB-INF/lib and any classes and resources in /WEB-INF/classes. I copied my background graphic into the latter and named it coupon.png. Here's the operation configuration.

When I request the image I need to pass an existing page in the URL. This is how the parameter provider factory works. I can see the image at http://<host>/<instance>/.imaging/coupon/website.png. This is a Christmas coupon with some red lights and space for text below.

Campaign management in Data module

For managing the campaigns I created a custom data type in the Data module. The campaign entry dialog allows editors to enter a discount percentage, product and validity period. I entered a Christmas campaign that offers 25% discount on a single in-store product.

The Data module stores the information in the data workspace. The discount percentage, for example, is stored in /campaign/Christmas/percentage.

Text overlay

The TextFromNode class can retrieve content from any workspace and overlay it on top of the image. In the percentage operation I fetch the discount percentage from the Data module. I need to pass the workspace name and path in the request URL, http://<host>/<instance>/.imaging/coupon/data/campaign/Christmas.png.

The percentSymbol operation overlays the % symbol using the FixedText class. The symbol is given in the text property. This works fine for static strings that don't change often. See Text overlay to learn about the nodes and valid values.

I added the text "off" also as fixed text and requested the image. Here's what is looks like at this point.

Adding the product description, validity period and legal disclaimers works in a similar fashion. Changing typeface, font size and positioning I was able to make the design more interesting. Here's the final result.

When the next campaign kicks in, all you need to do is ask your graphic designer for a new background image and create a campaign data item in the Data module.

Background image credit: George Deputee and Juliancolton2 on Flickr.

Controlling AdminCentral access

Antti Hietala — Thu, 31 Mar 2011 08:14:00 GMT

AdminCentral is a Magnolia CMS user interface where administrators and editors work. In this post I show how to configure menu permissions for a custom user role.

AdminCentral provides menus for common tasks. When you click a menu, workable items are displayed on the right.

You can hide menus and move them around to promote often-used items or deny permission to items that users should not be able to access. Magnolia CMS ships with typical roles such as superuser, editor and publisher. While a superuser can see everything, editors only see items that are relevant to their job.

Permissions for custom roles

Suppose your organization has a very specialized editor role, Category Editor, who is responsible for maintaining a taxonomy of categories. Categories are tags that help site visitors find related, interesting content.

Categories are managed in a custom data type under the Data menu. The demo-project website has an example taxonomy consisting of categories such as Culture, Family and Finance. The Category Editor needs access to the Data > Category menu only.

You can approach setting permissions for this role in two ways:

Top down: Start with a more powerful editor role and remove permissions until only the ability to edit categories is left.
Bottom up: Start with zero permissions and keep adding until the Category Editor can do their job.

Magnolia CMS ships with a demo-project-base role that provides many basic permissions common to all users. It's a good starting point so let's choose the first option: top down.

Create category-editor role

Create new role category-editor and new user jsmith. Assign roles demo-project-base and category-editor to user jsmith.

Now open another browser instance and sign in as jsmith. You should see three menus: Website, Documents and Data.

The Category Editor doesn't need the first two menus or the Contact submenu so let's remove them.

Hide menus

Edit the access control lists (ACL) attached to the category-editor role. Deny access to the following nodes in the config workspace:

/modules/adminInterface/config/menu/website$
/modules/adminInterface/config/menu/dms$
/modules/adminInterface/config/menu/data/Contact$

The demo-project-base role already grants access to the same nodes so you need to make the deny rules "win". If a user has multiple ACLs through role and group assignment that specifically list the requested resource, the ACL with the longest pattern determines the permission. The order of the rules is not considered. This is a critical point. Use the dollar sign ($) to mark the end of the path, which makes the deny rule longer.

Here's what the Category Editor sees after the ACLs have been applied. Menus are now perfect but the editor cannot edit the data items. Categories have a crossed-out pen icon to indicate this.

Grant access to data

Add an ACL in the data workspace that grants Read/Write permission to /categorization node. Now the items are editable.

Lock the backdoor!

Menus are not the only way to access content in AdminCentral. They just provide convenient access to often-used items. If you are restricting access per security, not just for convenience, make sure you lock down the content too:

Workspaces store the actual content. Make sure that any role you choose as a basis does not grant access to a workspace that users should not be able to access. In our example the demo-project-base role does not grant any unnecessary workspace permissions. You can control workspace access with an ACL. Select the workspace from the controlled space dropdown.
Trees are customized views into specific data. Users can view trees with a direct URL if they know the name of the tree, for example http://[host]/[instance]/.magnolia/trees/website. Each module can register its own trees. Look in /modules/adminInterface/trees to get an idea. As long as you restrict permissions to workspaces correctly, trees will honor the permissions.
Pages provide specialized tools such as exporting, importing and querying. Users can access pages with a direct URL too: http://[host]/[instance]/.magnolia/pages/jcrUtils. Like in trees, content cannot be accessed through pages as long as the workspace is locked down.

Find pages using any paragraph in Magnolia

rah003 — Wed, 23 Mar 2011 08:41:24 GMT

Somebody once said that the best ideas are the most simple ones.

Here comes one I had this morning when asked for example of page using this or that paragraph in Magnolia:

select * from nt:base where mgnl:template = 'stkTeaser'

Login to Admin Central, go to the JCR Queries, set target repository to website, limit result types to mgnl:content and type in the query above. Of course, also replace the "stkTeaser" with what ever paragraph you are looking for and you are done. The result will list all the pages using given paragraph.

The one problem you might run into is that you actually don't know the name of the paragraph. Again the query comes handy here:

select * from nt:base where jcr:path like '/modules/%/paragraphs/%' and type is not null

In this case set repository to "config" and limit results to "mgnl:contentNode" type.

Spring Web MVC with Content

Tobias Mattsson — Mon, 21 Mar 2011 16:39:00 GMT

The idea that sparked me writing the Blossom Module for Magnolia CMS was to bring the CMS and especially the content into Spring Web MVC not the other way around. Controllers should be the building blocks when composing pages. The latest version 1.2.2 brings a small but significant piece to the puzzle. By adding a custom WebArgumentResolver you can add content objects to the argument list in annotated handler methods.

This is an example of a paragraph that displays a contact form where the author that created the page specified which office will be receiving the filled in form. The office is fetched from a database and passed to the view where details such as its address are displayed.

@RequestMapping("/contactForm")
public String contactForm(ModelMap model, Content page, Content paragraph) {
    model.put("office", officeDao.getOfficeById(paragraph.getNodeData("office").getString()));
    return "contactForm";
}

To enable it you need to add the BlossomWebArgumentResolver to your AnnotationMethodHandlerAdapter.

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
  <property name="customArgumentResolver">
    <bean class="info.magnolia.module.blossom.web.BlossomWebArgumentResolver" />
  </property>
</bean>

BlossomWebArgumentResolver provides support for a few more arguments that is handy to have handed directly to your handler method. They are: AggregationState, WebContext, Context, User and MgnlUser.

Category cloud with images

Antti Hietala — Fri, 18 Mar 2011 08:11:00 GMT

This post was inspired by Amit Patel's question on how to add images in a Magnolia category cloud. Thanks Amit!

What is a tag cloud?
Tags are words or short phrases that describe content such as articles or photos. A tag cloud is a weighted lists of those tags displayed as a group where popular tags are given more visual weight than less popular tags. The visual weight is accomplished by making popular tags larger or bolder.

Here's a tag cloud from Flickr with tags that people use on their photos.

Another cloud with trending Twitter topics.

Magnolia category cloud
Magnolia's category cloud paragraph has the same principle. Articles on a website are tagged with categories to make it easier to find related content. Categories can be displayed in a cloud just like tags. The Magnolia category cloud is an editorial paragraph rather than compiled automatically from popularity statistics. This means that editors can set the weights to promote categories that are hot to give a boost to active campaigns or new content, for example.

Add an image control to Category dialog
The quickest way to add images to each category is to copy the photo upload mechanism from the Contacts data type. Both Contacts and Categories are managed in the Data module so repurposing elements is a snap.

Add an image control in Category dialog:

Go to Data > Config (Dialogs).
Copy /modules/data/dialogs/contact/personalTab/photo to /modules/data/dialogs/category/mainTab.
Rename the copied node to icon.
Change the label to "Icon".

Now you can add images. Get some nifty icons from the Web and add them to your categories.

Render images next to category labels

Edit the categoryCloud.ftl paragraph script. It's in the Categorization module JAR. You can also test this out by creating a script in Templating Kit > Templates and referencing it from the paragraph definition instead.
Assign images to categories.

[#-- Assigns: Macro for Item iteration --]
[#macro assignItemValues item]
    [#-- Assigns: Get Content from List Item--]
    [#assign itemName = item.@name]
    [#assign itemDisplayName = item.displayName!itemName]
    [#assign itemLevel = item.level]
    [#assign itemLink = model.getCategoryLink(itemName)!]
    [#assign itemIcon = item.icon!]
[/#macro]

Render the icons.

<li class="${itemLevel}">
  [#if item.icon?exists]
    <img src="${stk.createImageLink(itemIcon)}" />
  [/#if]
    <a href="${itemLink}" >${itemDisplayName}</a>
</li>

To finish off, add a category cloud paragraph on the page and admire your handywork!

@Hackergarten

Daniel Lipp — Thu, 17 Mar 2011 13:11:00 GMT

Yesterday (late) evening there was the Magnolia Night at Hackergarten. Next to our host Hamlet D'Arcy and 4 Magnolia fellows, there was 7 attendees from various companies. After a short introduction to the product we quickly choose the topics for the night.

We ended up splitting into two groups. Mine was trying to dig into the recently created OpenSocial Container module and especially attacking the currently missing OAuth integration there.

I have to admit we did not get something to run (in contrast to the other group) but this was not really surprising considering the fact that all group members (except me) had never before worked with Magnolia nor had knowledge about OpenSocial. Next to some deeper insights into OAuth we had a lot of nice conversations and were discussing many Magnolia and/or OpenSocial related aspects.
Considering that most of as had already worked some 8+ hours before and that Basler Fasnacht was still going on outside this is quite an outcome I'd say ;-)

Especially striking: again it turned out that the social in OpenSocial doesn't really help to convince people that this is something extremely useful for less social use cases. That's why I added a short intro to our module's Wiki page especially pointing out that there's a whole bunch of big companies using it for there less social apps.

To summarize I can say it was a great evening and I got to know a bunch of cool hackers. I bet the others liked it as well...

Thx a lot Hamlet for hosting the whole event and providing food & beer!

Using Magnolia for Mobile Content

Sean McMains — Thu, 10 Mar 2011 17:08:55 GMT

When we started work on version 2.0 of the Texas State Mobile app for the iPhone, the biggest new feature that the Marketing department wanted to see was a “What’s New” screen. Their idea was that they could use it to accomodate all of the folks who wanted a presence in the mobile app, but [...]

Adding Flickr images to Magnolia CMS

Teresa Miyar — Thu, 10 Mar 2011 14:39:00 GMT

This is a step-by-step guide on how to create your custom DAM and plug it into Magnolia CMS. Will allow you to add images from external services like Flickr, as well as adding images from other servers using their url (It comes with a forge module!)

This is a sample handle for external image/video urls, very basic as it does not add the imaging support for now.

* Requirements - Standard Templating Kit Module

1. The Asset

We need to create our own Asset class that will implement the interface Asset

If we want to have exact same behavior as in STK/ETK we will need to find a way to store 'meta data' (caption, description) of our assets, we could use the data module for that matter.

In this sample we wont store any metadata for the images, nor use the imaging support.

That leaves us with just one method to implement 'getLink' and this will be the value stored when we open the dialog to select an image.

public String getLink() throws DAMException {
return link;
}

Creation of link is on the class constructor, as easy as this

link = nodeData.getString();

2. The handler.

Should extend class AbstractHandler . We will extend from AbstractHandler that has the methods to read the configuration, that leaves us with two methods to implement as needed: getAsset and getAssetByKey. In this case we implement getAsset to return an instance of our Asset.

final String name = getNodeDataName(node, nodeDataPrefix);

Important thing to note here is that we need to get the name of the nodeData that has the url of our image. When you set an image using the dam controls, you name your node as i.e. 'myimage' and on saving you will get a nodeData with the name you gave plus the name of the dam control used. To make it simpler a call to the method getNodeDataName will give you the real name with which your node has been saved. In this sample it will contain the exact url of our image, no need of further processing.

final NodeData nodeData = node.getNodeData(name);

This line above gets the node data, now with the right name.

return new UrlAsset(nodeData);

Here is where we return our asset.

3. The controls (configuration).

Need to add the configuration for this external dam. For that we create a new node under our site configuration. There we put the handler we are going to use and the control/s in which we will store the image information. See image:

And to finish this post there is a module in Magnolia forge magnolia-module-urldam with the code to add an external dam handler.

Magnolia Module OpenSocial Container is out

Daniel Lipp — Mon, 07 Mar 2011 08:16:00 GMT

About one month ago I was writing about a PoC having the aim to integrate existing webapps into Magnolia-powered websites by bringing OpenSocial to the Magnolia world. This PoC could successfully be finished a couple of days ago. All envolved developers as well as the project owners were really happy as - thanx to the power of OpenSocial and Magnolia CMS - all requirements could be fulfilled. In order to do so we only had to dive into OpenSocial and write few lines of java, javascript and freemarker. This was enough to construct the Magnolia OpenSocial Module and transform the gwt-based webapps into first class gadgets.

The requirements were:

be lightweight: We just store a gadget title and its URL in magnolia. To be able to do so we just need a magnolia instance with the new module installed.
preserve the existing web-apps as far as possible: Having understood how the mechanism works, it only took about 2 hours per app to convert into a gadget.
allow to render different views for each app (minimized, maximized): We just used the home and the canvas view as defined by OpenSocial. The js files of Apache Shindig already supported them - the gwt-apps came with two corresponding views that could be mapped to the ones of OpenSocial.
allow communication between the apps: OpenSocial pubsub mechanism is also provided with Apache Shindig so we only had to activate the feature.

Of course many deliverables of the PoC are very customer specific. The good news is that the new OpenSocial module is not - and it'll be available to you in a few hours...

I created a short screencast to show were we currently are:

Seeing separate gadgets being rendered within magnolia was already quite impressive. When we put in the converted GWT-Apps at the customer's side, OpenSocial revealed its real power:

Styles of the container and of all the gadgets were aligned so it really looked like an enterprise portal. On top - using the pubsub feature - gadgets can easily interact with each other. I'd be really surprised if we'll not see lots of Magnolia empowered websites hosting gadgets within the next few months.

Me I'll jump back to Magnolia 5.0 development now, but will keep an eye (or more) on the new module - you probably should do so as well...

Magnolia CMS 5.0 - Architecture manifests

Philipp Bärfuss — Thu, 03 Mar 2011 08:52:00 GMT

After few weeks of Magnolia 5.0 development and again focussing on the UI architecture, I have finally assembled slides and diagrams to give insights into our doing. Some of the concepts are very drafty but most of them are already reflected in the latest codebase. When we deliver the milestone 3 end of march, we hope that the base architecture will be set in stone ;-)

Magnolia CMS 5.0 - Architecture

Magnolia CMS 5.0 - Overview
An other high level presentation describing our goals and plans can be found here:

Upgrades with Magnolia

Sean McMains — Wed, 23 Feb 2011 18:26:05 GMT

During my stint at Texas State University, we adopted Magnolia CMS around 2007 after a disastrous two-year dalliance with another enterprise system. Since we wanted to be as responsive as possible to our users’ varied (and often changing) needs while still keeping our CMS reasonably stable, we decided to do once-a-month releases to fix bugs and incorporate new [...]

An ode to refactoring

noreply@blogger.com (Andreas Weder) — Fri, 11 Feb 2011 10:48:00 GMT

If you're a user experience professional or just interested in the field and have read books (e.g. this one) on how to best design the user experience of an app or site, you know that there are many ways to design, fix and extend a user interface. Most of us work iteratively, repeating the same steps over and over again, taking in additional requirements and tasks along the way, until we've reached our goals - or the project deadline.

My work on Magnolia 5 actually has several, concrete goals, which i tried to summarize on this wiki page of the M5 UX space, but the overall character of my main task is clear:

We want an evolution and no revolution of Magnolia's user interface.

I'm taking great care to build on what is already here, especially if it comes to AdminCentral. The administrative interface of Magnolia has both been successful and is a visual landmark - its green background, the lights indicating activation success or failure and, in general, its usage patterns both simple and effective at the same time have shaped everybody's first impression of Magnolia substantially.

As a developer, while I enjoyed building a new app, I always also enjoyed reworking an existing code base. Take what's working. Try to fix what's broken. If you can't fix it, come up with something new or different that plays well the existing pieces. I love to refactor code.

Refactoring code is very demanding, if your code has no or the wrong structure. You can only move in very small steps, if there are no or only broken tests. Since nobody is willing to wait until you've finished your changes, part of the task is to keep things running while you work. It takes a significant amount of time to reshape existing code, if - how a boss of mine put it once - the acre hasn't been dug over frequently. Refactoring is part of development, at any time, under any circumstances. You can't always start new. You don't want to simply rewrite pieces, partly because that would also mean loosing many insights gained so far and repeating the same errors.

But once the mist has disappeared, structure appears, concepts become clear, refactoring becomes something enjoyable, your code shines.

Refactoring is cool. It is kind of like renovating a bridge without being able to close it down for traffic. Building an underground train station without interrupting service. Reconstruction work at a major place in a city with only slightly rerouted traffic.

So that's what I do: I refactor AdminCentral. It's demanding, it's passionate, it's adventurous. And boy, it's such a cool job.

More about old new AdminCentral in the next couple of weeks.

Raising the Bar in CMS Usability with Vaadin

Boris Kraft — Wed, 09 Feb 2011 09:37:00 GMT

We want our next major release to provide the very best administration interface for Web-based content management on the market.

Go ahead. Read that again.

Yes, we really do believe Magnolia 5’s GUI will be better than any other web based CMS on the market. That is a strong aspiration, agreed, but then again it’s been Magnolia’s core aim from day one: “Simplicity on an Enterprise Scale” for us means a CMS that is intuitive to use and works well for enterprise use cases. We have shown Magnolia CMS can cover enterprise use cases. Now its time to deliver on the usability part.

Setting a goal means adjusting focus. Magnolia 5’s focus is on user experience.

Magnolia 5’s usability shall amaze content authors with a high-usability interface not just when using a desktop browser, but also on an iPad and other mobile devices with a touch screen. With such high goals, you better choose a very good toolkit for building Magnolia’s new Graphical User Interface (GUI).

At Magnolia Conference 2010, Philipp and Daniel talked about Magnolia 5.0, and specifically about how we were evaluating Vaadin as our framework for the next-gen AdminCentral (our administration interface) in Magnolia 5.0. After a lot of debate (both internally and with the community) and some proof of concept development, we finally decided to stop tinkering and take the decision to go with Vaadin as our toolkit of choice for the Magnolia 5.0 GUI.

Show Me the Veggies!

If you'd like to see the Vaadin/Magnolia synergy in action, take a look at above video. This is a proof of concept. Things will look completely different with the final Magnolia 5.0, but it shows that Vaadin is able to work for the things we have in mind. It also shows a nice idea about building a graphical dialog editor.

Consistent User Experience Across All Input Devices

Magnolia's tagline is "simple open source content management" and we take this to heart. We want content authors (and developers) to be delighted with every aspect of Magnolia. Very simply, Vaadin helps us meet this goal because the people that build Vaadin share our philosophy. They really care about the user interface.

Out of the box, Vaadin comes with some great-looking UI components, which certainly helps for first impressions. And not only that, but it lets you put them together into a slick and intuitive interface without leaving behind a trail of messy code. However, shiny widgets alone don’t make a good user interface. With Andreas, Magnolia has a dedicated and experienced user interaction designer on its team who completely shares our vision of how things should work. Andreas has worked for months defining basic interaction patterns and hammering out how an interface must work to support not only mouse but also keyboard and touch as input devices for common Magnolia operations. So the next time you hit the down arrow on your keyboard to navigate down through the AdminCentral tree, it will actually work!

Touch support means Magnolia’s administration interface will work on an iPad and other mobile devices requiring touch support. It also means that Magnolia 5’s AdminCentral will likely be completely accessible, a feature often requested by governments but hardly found in any existing CMS.

One benefit of how we will utilize Vaadin, using shared components and pure Java packaging, is that the overall user interface will be much more consistent, regardless of whether a module comes from Magnolia's core developers or from an external contributor. This means shorter learning curves and more shiny, happy users.

Standardization and High Security

If you’re a Magnolia developer, you probably already know that our current AdminCentral client is tightly coupled to server-side architecture, and we use a custom JavaScript library to handle AJAX requests in the client. We never set out to conquer the world with our GUI libraries, but back when we started, there was no alternative to writing our own. With Magnolia 5.0 we finally have the chance to switch to an existing, established, well-proven, documented and (externally!) maintained library instead of having to work with our own. This allows us to focus on stronger traits, like building great user interfaces instead of fixing browser incompatibilities in GUI widgets. And it allows everybody else to use a library they can use across many other projects.

Standardization is a good thing and Magnolia has used existing code and supported standards wherever there was a match with our needs. The GUI library really is the last major part of Magnolia that was non-standard, simply because what we need did not yet exist.

Besides using a standard GUI library, one of our original technical goals for Magnolia 5.0 were to decouple AdminCentral from the server. Alas, our research made it clear that still no GUI framework exists today that fulfills all requirements at once. Vaadin comes with built-in listeners and data binding for its UI components, and it's already tested to work on major browsers, so it covers a lot of what we need. The framework is server-side, which brings a lot of benefits for every developer working with it, but it also means the coupling between client and server is not quite as loose as we originally envisioned it. Still, there is a lot to like about it:

Rich widget framework
Out-of-the-box theming
Java developer friendly
- Close to Swing
- GWT based (Java -> Javascript)
- Can integrate any GWT-components
- Rare GWT-compiles (compared to plain GWT)
Testing with pure JUnit
Apache License
Well documented

As Philipp discussed some time ago, Vaadin uses server-side events, which could impact performance, an issue that is particularly critical if you wish to provide a snappy user interface on the web. While we've seen that a server-side framework in itself doesn’t imply worse performance than a pure GWT approach (an alternative we considered), we will need to invest more effort on that end to achieve what we want. On the positive side, running an entirely server-side architecture makes the system more secure, and Vaadin's JSON-based UIDL allows for future extensibility. Vaadin is helping us kill multiple birds with one stone here: we're reducing server load, increasing security, future-proofing our work and creating a better user experience at the same time.

Open Source and Community Support

Like Magnolia, Vaadin is an open source project, and it already has a strong community base, excellent documentation and a dedicated team of developers who are improving it on a daily basis. Vaadin UI components are all written in Java and so, if you know Java, you can extend them, share them with the Magnolia community, and build cool stuff on top of them. That is one major reason we like it: with Vaadin, you don’t have to be a JavaScript wizard to build great applications for the web browser. And let’s face it, if you were, you’d be working for them.

For those of us who like to be home at least occasionally, Java is a fantastic choice to build applications, and Magnolia 5 with Vaadin will make it easier than ever to build extensions for Magnolia and help the Magnolia community grow, because now, you can also go wild on the front-end.

The best GUI Tool for Our Needs

We've been trying out Vaadin about eight months ago and while many challenges have been overcome for the original proof of concept, the real work still lies ahead of us. In our review and testing, we found that Vaadin consistently scored at or near the top in criteria such as productivity, security, theming, collaboration and community backing. With Magnolia 5 GUI development starting in earnest, we’ll soon have much more to say in terms of real-world experience. Ultimately, there is no silver bullet. Just like when you have to choose a Content Management System.

Learn More about Vaadin and Magnolia 5.0

If you’d like to learn more about Magnolia 5.0, you can see presentations about our Magnolia 5.0 roadmap from the community day at Magnolia Conference 2010. Then, check out the Magnolia 5.0 wiki pages. Learn more about Vaadin in this presentation by Joonas Lehtinen, also from Magnolia Conference 2010.

Magnolia getting (even more) open & social

Daniel Lipp — Thu, 03 Feb 2011 08:59:00 GMT

Recently, we were asked to integrate several existing web-apps (mainly GWT-based) into one Magnolia empowered website to build something like an enterprise portal.

Among others, the integration should
- be lightweight
- preserve the existing web-apps as far as possible
- allow to render different views for each app (minimized, maximized)
- allow communication between the apps

First decision was whether to go for a client-side integration (iFrames & more) or a server-side one like the Java Portlet specifications (JSR 168 and 286). It was quickly agreed to choose client-side because these are more lightweight by nature and reuse of the existing web-apps (especially the GUIs) should be straightforward.

So the next question was the classical make or "buy". Should a proprietary portal be developed, or is there anything existing that could fulfill our needs? Further analysis revealed that OpenSocial - the emerging standard for client-side, lightweight web-app integration and it's reference implementation Apache Shindig offer almost everything we were looking for - for free! So everybody agreed to opt for this approach.

Some people might ask why a standard originally developed for satisfying the demands of social network sites should be a good match for a lightweight enterprise portal. Well, it's because OpenSocial offers much more and can hence be a good match for various enterprise usages. In addition that's precisely the direction it is envolving to (see enterpise-opensocial).

By using OpenSocial/Shindig we get
- a well established standard (would take a lot of time to define yourself)
- gadget-to-gadget and gadget-to-container communication
- an easy way to reuse GWT-based web-apps as they can easily be transformed into OpenSocial gadgets

- a sophisticated security mechanism (OAuth)

- and more...

That's what I call a jumpstart.

We took the default approach to dig into OpenSocial by installing Shindig v2.0.2 as ROOT.war in Tomcat. I was really impressed when playing around with the samples. On the other side, trying to change the context path or the used port quickly stopped our container from working properly :-(

Plain Shindig wasn't our main focus so we then started creating an OpenSocial container within Magnolia encapsulated in a regular OpenSocial-Container module referencing Apache Shindig. Actually, this is somehow similar to what quite a few other companies did in the last 1-3 years. Here we quickly encountered similar problems as described above.

As we could not find good documentation on how to configure Shindig the right way and especially on how to create a OpenSocial container based on Shindig we started looking into the sources. There, Shindig revealed a well defined and understandable structure, so we're now realizing what issues are to be solved next and can hence steadily progress. In the meantime I stumbled over a Slideshare-presentation of one of the major contributors of Apache Shindig. Especially slide 30-40 helped me a lot in understanding what we have to do...

Although still being in a proof of concept, we already have the strong feeling that this will become a very valuable extension to the Magnolia ecosystem.

So stay tuned - I'll keep you up to date!

Ps.: blogger itself is based on OpenSocial

Link popularity

Antti Hietala — Wed, 02 Feb 2011 11:18:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at increasing your site's link popularity.

Search engines place strong emphasis on your site’s link popularity. Links from external sites, especially highly ranked ones, increase your site's rank. The more links targeting your site from external sources the better.

There are countless ways to build links and a comprehensive discussion on this is beyond the scope of this paper. Some ways that Magnolia can help to build incoming links are:

By developing a blog on an external domain to promote your main site. The Templating Kit allows you to manage multiple sites in a single instance.
A forthcoming social media module will facilitate effortless integration with social media networks that have become a must for success on the Web.
Social bookmarking provided in many Magnolia templates.
Friendly URLs make creating external links intuitive and easy to create.

Keywords in page titles and meta elements

Antti Hietala — Tue, 01 Feb 2011 09:40:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at inserting keywords in page titles and meta elements.

Page titles are an extremely important SEO factor. Search engines give titles considerable algorithmic weight and use them as headings on search results. Titles should include keywords and, where appropriate, your company name for branding purposes:

<title>Magnolia - Finance, Insurance & Banking</title>

Description meta elements on the other hand do not add much to page relevance, but should not be neglected:

<meta name="description" content="Magnolia's largest group of Enterprise Edition customers is from the...">

Their content often appears below the title in search results:

The relevance of keywords stipulated in the keyword tag once had great impact, but this is no longer true. Actual page content is now far more relevant. Still, a keyword tag should be included:

<meta name="keywords" content="Finance, Insurance, Banking">

Magnolia produces the title element from the page title automatically, so this aspect is never overlooked. Inserting keywords and descriptions is done in the page info dialog:

These fields can be made mandatory with a simple configuration change in AdminCentral. If an editor fails to provide the description, page abstract is used automatically as a fallback. Authors don't need to fill the field to be SEO compliant.

Magnolia and ModeShape

rah003 — Sat, 29 Jan 2011 12:33:38 GMT

It had been a while since we started to test Magnolia with ModeShape. It took few changes in the code here and there and it would not have happened if not for a big help from the JBoss folk.

There were multiple obstacles we had to deal with. But as of Magnolia 4.4.2 and ModeShape 2.4.0 the things seem to be finally ready and you can download Magnolia configured to run with ModeShape as backing repository. By default it comes preconfigured with HSQLDB as a backing database, but there are also config files for running repo with MySQL or in-memory. If you feel adventurous, there is also guide on how to setup modeshape to be backed by the InfiniSpan.

With this release you should be able to get working Magnolia installation with Modeshape and use it as a base for your own setup. This release should be considered experimental and not used in production systems. And as an experimental release there are still some rough edged that need to be taken care of:

the performance using same backend db is lower compared to same setup with JackRabbit. Performance improvements are planned for the ModeShape 2.5 release.
Sometimes after restart it is not possible to log in, this might be also accompanied with the stacktrace in the logs about missing anonymous user account. Usually it is enough to restart the instance to fix it.
Also when shutting down the webapp, it might happen that ModeShape fails to close the sessions with registered observers. In such a care killing the process should make it stop without any side effects.

Also if you find out anything else not working in this release, please report it.

Thanks.

Optimizing images

Antti Hietala — Fri, 28 Jan 2011 08:48:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at optimizing images.

Great images enhance your site visually and enhance SEO rankings, provided they are properly optimized. Google and other search engines offer image-specific searches. A high rank in these searches increases your visibility. Search engines cannot read the content of images, and therefore must rely on accompanying text and tags.

Best practices include:

Image alt attributes with a short description of the image, for example.
Keyword-rich image file names. yellow-roses.jpg is far more descriptive and relevant than img003.jpg.
Size and quality optimized for quick loading. Crisp, sharp images look better in thumbnails displayed in search results, and are more likely to be linked to by other webmasters.
Captions that aptly describe the image assist vision-impaired users.
Width and height specified in the element. Many browsers render a page before images are downloaded. When dimensions are provided, other page elements wrap around them correctly, improving the initial user experience.

Images can be stored in Magnolia's built-in document management system or uploaded at editing time. When the DMS is used, a two-phase failsafe mechanism ensures that alt tags, appropriate file names, and captions are included:

At upload time, details such as image source, copyright, subject line and size are captured. The fields provided for this purpose in the DMS are based on the Dublin Core Metadata Standard. If the original file name contains spaces, Magnolia replaces them with hyphens. In the event that an editor fails to include the information requested in the dialog, the source and subject-line are used as fallback.
When inserting an image to a page, the information read from the DMS can be changed once again. If the fields are configured as mandatory, an editor cannot insert an image without providing suitable alt attribute and caption. This enforces best practice compliance.

As a result, the page template renders crawler-accessible HTML code:

Magnolia Imaging module ensures that high-quality, web-optimized images are used uniformly throughout the site. The module generates multiple variants from a single source image, resulting in considerable time-savings for editors. Sizing and cropping happens automatically, based on CSS rules. Built-in filters that scale and crop images can also be used for effects such as text overlays, which allow crawlers to read image text. It is possible to configure a standard output format and resolution for all images, and control the behavior of images in each area of a template.

Redirecting traffic

Antti Hietala — Wed, 26 Jan 2011 08:17:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at redirecting traffic.

Redirecting is the practice of sending requests to alternative destinations. Typical reasons to redirect are:

Pages have moved due to site re-organization but search engines and users still have the old URLs in their indexes and bookmarks. Without redirection traffic going to the moved pages is lost to 404 errors.
Identical URLs serving the same content lead to duplicate content issues as crawlers mistake each URL for a separate site. This is known as the "canonical URL issue" in SEO parlance. It is not uncommon to have example.com, www.example.com, and example.com/index.html deliver the same content. Sometimes there is a valid need to display the same content on multiple pages.

These factors adversely affect SEO but they can be corrected by redirecting the incoming request to an alternative URL. There are several ways to redirect, but the only search engine friendly way is a 301 permanent redirect, which ensures that your hard-earned page rank is transferred to the new location. Contrast this with a temporary 302 redirect which is disastrous for SEO as page rank is not applied towards the new location.

Redirects are typically cumbersome to implement on a Web server. Responsibility over Web server configuration often falls to another team and is out of reach for authors and editors, even for technical CMS team members. Fortunately, Magnolia allows you to configure redirects directly in AdminCentral.

A permanent 301 redirect is easy to do with virtual URI mapping. The request can be redirected to the same domain or another one. For example, when visitors request winter2010.com, you can redirect them to example.com/marketing/campaigns/winter2010, the actual location of the content. Short addresses are easier to market and remember.

In addition, the Templating Kit includes a Redirect template that allows authors to set up a redirect page and define where the incoming request should go. Both internal and external pages can be identified as redirection targets:

If you read more about the canonical URL issue on SEO blogs you will come across the "canonical URL tag". It is a link element in the page HTML head that tells crawlers that the page is actually a copy of the page given in the href attribute, and that page rank should be attributed to that page instead.

<link rel="canonical" href="http://www.example.com" />

The canonical URL is almost the same as 301 redirect in terms of SEO with the following exceptions:

301 redirect redirects all traffic (crawlers and visitors). The canonical meta element is just for crawlers.
301 is a stronger signal that multiple pages have a single, canonical source.
301 can redirect traffic to another domain, while still counting existing page rank towards the new location.
Canonical URL is sometimes favored over 301 because you don't need to ask developers to implement it. But as seen above, this is not an issue in Magnolia since editors can do their own virtual URI mapping in AdminCentral.

Categorizing content

Antti Hietala — Mon, 24 Jan 2011 08:40:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at categorizing content.

Usability and SEO go hand-in-hand. Categorizing content allows visitors to find related and similar content with ease. Logical, keyword-rich categories provide intuitive navigation of a large collection of content. Categorization offers a range of opportunities to improve internal linking, visibility, and keyword density. Common uses of categories are tag clouds, and links to overview and landing pages.

Although content tagging is an effective technique, tag clouds in particular have been abused. Bloggers saw them as a keyword-stuffing opportunity, and search engines have developed techniques to combat this trend.

Magnolia allows you to create custom categorization taxonomies. You can tag articles with categories to support browsing of related content. This feature can be extended and adapted to suit your needs.

By default, you can categorize any page based on the Article template. Categories are displayed as related links in the article header:

Magnolia provides an editorial Category Cloud which allows editors to assign weights to categories. The more weight a category has, the bigger it shows in the cloud:

The Category Overview template lists all articles within a category and suggests related categories:

Preventing broken links

Antti Hietala — Fri, 21 Jan 2011 09:41:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at preventing broken links.

Broken links can lower your site's rankings. Google mentions this specifically in its SEO guidelines. Broken links are also a source of irritation for users.

While you have little control over changes to external links, you can inadvertently break internal links in a variety of ways, such as when changing site structure or deleting content that has incoming links.

A process should be in place to regularly validate all links on a site.

Magnolia has safeguards to prevent broken links:

A hierarchical content store ensures that there are no orphaned pages that have no incoming links. All pages belong to a hierarchy, and each page has at least one incoming link - from its parent.
Each page has a unique content ID for use as an internal link target. Dialogs provide a user-friendly browser for locating the target. Authors don't need to know the unique ID.
The unique ID stays the same even when the target page is moved or renamed. This allows for flexible site reorganization without breaking the links. The same mechanism is used when linking to documents in the document management system (DMS). Internal links to non-existing pages and documents will not be rendered, avoiding broken links.
A reference view lists any incoming and outgoing links. A message on shows dependent content on deletion and deactivation.
A custom 404 "not found" page can be displayed for broken incoming links. You can provide helpful alternatives such as sitemap tree or a search box to find the desired content:

Magnolia does not check for outgoing broken links but third party link checker tools for this purpose exist.

HTML links

Antti Hietala — Wed, 19 Jan 2011 15:42:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at inserting HTML links.

Navigation links should be rendered as HTML to make them easy for crawlers to read. Search engines take the anchor text of a link into consideration when indexing it. Graphics and Flash objects, used by many designers to control look and feel, normally cannot be crawled. Alternative text descriptions should be provided. Use of uncrawlable elements also hinders users who do not have the required browser plug-ins.

Since the navigation system is a site-wide collection of links to topics, links should be consistent throughout the site. Navigation is also a perfect opportunity to include descriptive keywords.

The Magnolia Templating Kit offers four navigation structures out-of-the-box: horizontal, vertical, breadcrumbs, and meta-navigation. All of them render links as HTML. Consistent navigation is enforced throughout the site using the same template.

Shallow site architecture

Antti Hietala — Mon, 17 Jan 2011 13:18:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at providing a shallow site architecture.

Site architecture is critical to SEO. Many sites grow organically and their architecture becomes a maze-like, illogical complex. A clear structure provides both the user and web crawler with a positive navigational experience.

As a rule of thumb, the flatter the structure, the better. The higher a page appears in the site structure, the more likely it will be ranked high by a crawler. Crawlers seem to determine the depth of a page by the number of directories present in the URL, giving more relevance, for example, to /books/art than to /books/bestsellers/hardcover/art. A one or two layer limit is recommended, but for larger sites this is not always feasible.

It is also important to maintain consistency throughout your site. All pages should follow the same format, and once established, you should endeavor to stick to the URL guidelines. Where possible, avoid the use of sub-domains as crawlers may view them as separate from your main domain.

Magnolia stores content in a hierarchical content repository. Editors see the hierarchy as a tree where each page belongs to a branch and has a parent node:

Organizing a site as a hierarchy enforces consistent structure. Pages and branches can be rearranged via drag-and-drop.

Magnolia allows you to manage an unlimited number of sites in AdminCentral. Each site has its own site tree, to keep the hierarchy shallow. You can map unique domain names to each site, creating microsites for campaigns, for example. To a crawler, these appear either as unique sites (www.winter2010.com) or as parts of your domain (winter2010.example.com).

Sometimes it is difficult to avoid deeper structures. For example, you may want to create a campaign inside your main site at /example/marketing/campaigns/winter2010. Adhering to the shallow hierarchy principle is possible even in this case. Magnolia allows you to shorten the URL with URI mapping. Visitors and crawlers access the campaign site at www.example.com/winter2010 while the content is served from the true location deeper in the hierarchy.

Search-engine friendly URLs

Antti Hietala — Fri, 14 Jan 2011 08:30:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at creating search-engine friendly URLs.

URLs are an important SEO element for search engines as well as users. Search engines are more likely to index static, short, clean URLs. Users appreciate their readability too. While most crawlers can follow dynamically generated URLs, there is evidence that when dynamic parameters are appended to a URL, the crawler only follows them to sites considered to have high importance. Request parameters should be avoided in the URL, as the crawler may view several URLs pointing to the same content as duplicates, lowering page rank.

Good

http://www.yoursite.com/books/hardcover

Bad

http://www.yoursite.com?p=72&s=0

Page URLs should:

Include important keywords, as keywords are highlighted in search results. Most SEO experts agree that including them in a URL is important. Keywords also increase the likelihood of a visitor clicking through to your site.
Have short, case-insensitive words, separated with hyphens.
Be descriptive of page content. Both from the SEO and usability perspectives, an obvious URL is a good URL. URLs get pasted, shared and written down, so the more obvious the content, the better.
Avoid the use of meaningless numbers and extraneous information.

Magnolia produces clean, human-readable URLs by default. Dynamically generated URLs are converted to crawler-friendly static ones. Request parameters are not appended to URLs.

Some systems append session IDs to a URL. A session is typically needed when a user logs in. A user's shopping cart is an example of content that would be stored in a session. Appending session IDs to URLs is a security issue. A URL that contains an ID cannot be copied without the risk of inadvertently handing the session to another user.

Good

http://www.yoursite.com/cart

Bad

http://www.yoursite.com/cart?jsessionid=undn2i50l4

Magnolia is session-less until the user logs in. At that point, a session ID is stored in a cookie instead of appending it to the URL. This avoids the duplicate content issue and makes URLs safe to copy and share.

When creating internal links, Magnolia uses the title of the target page as anchor text by default. The title typically includes the most relevant keywords about the target page.

Minimizing length and trailing slashes will make URLs easier to copy and paste, and fully visible in search results. A Magnolia URL is equally valid, regardless of whether you include an .html suffix or slash:

http://www.magnolia-cms.com/clients/references
http://www.magnolia-cms.com/clients/references.html
http://www.magnolia-cms.com/clients/references/

Restricting crawler access

Antti Hietala — Wed, 12 Jan 2011 09:38:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at restricting crawler access.

While SEO is mostly about about enticing that crawlers to your content, there are some pages you may not want them to access. These include administrative, password protected, and paid access pages.

A robots.txt file restricts crawler access on a site-wide basis. The file is typically placed in the root directory of your site. All legitimate crawlers it check fro the presence of a robots.txt file, and respect the directives it contains. Even if you do not want to restrict access, it is advisable to include a robots.txt file because the absence of one has been known to produce a 404 error, resulting in none of your pages being crawled. This can also be the case if the file is not constructed correctly. Specific crawlers can also be denied access by entering their names or IP addresses in the file.

The following example instructs all crawlers to keep out of the private and temp directories and denies access to a specified crawler.

User-agent: BadBot # replace 'BadBot' with the actual user-agent of the bot
Disallow: /private/
Disallow: /temp/

It is also possible to exclude individual pages with a robots meta element in the page HTML header.

<html>
<head>
<title>...</title>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
</head>

Relevant values for the robots meta element are:

NOINDEX prevents the page from being included in the index.
NOFOLLOW prevents the crawler from following any links on the page. Note that this is different from the link-level rel attribute which prevents the crawler from following an individual link. For anti-spam reasons, it is generally better to use the rel attribute with value NOFOLLOW for individual links.
NOARCHIVE instructs the crawler not to keep the page in the engine's public index. With Google, this prevents a cached copy of the page from being available in search results.

Preventing crawlers from following undesirable links can help combat automated spam. This method is endorsed by all major engines. Adding a rel="nofollow" attribute to a link allows control on an individual link basis. It can be used to reference external content while not endorsing it, and overcomes the necessity to exclude the crawler from all links on a page.

<a href="http://www.badsite.com" rel="nofollow">

You can use all the above access restriction methods in Magnolia:

Editing a robots.txt file is vastly simplified in that Magnolia produces clean, human-readable URLs such as http://www.magnolia-cms.com/support-and-services.
At a single-page level, templates set the robots meta element in the HTML header to "all" by default, allowing full crawler access. Options to change this behavior can be offered to editors with minimal configuration directly in AdminCentral. Customization would involve adding a field in the Page Info dialog definition and a minor tweak to the paragraph template.

Sitemaps

Antti Hietala — Mon, 10 Jan 2011 18:46:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at creating an XML sitemap.

While most crawlers will find your site on their own, best practice is to keep them informed by providing an XML sitemap that lists your site's URLs. The document includes additional metadata about each page, such as when it was last updated, how often it changes, and its relative importance to other pages on your site.

The Sitemaps XML protocol (sitemaps.org) is supported by all major search engines. You should include a reference to your sitemap's location in a robots.txt file.

Magnolia's Google Sitemap module generates your sitemap XML document automatically. It finds all the pages on your site and allows you to easily set priority and change frequency in the user interface. No XML editing is necessary. Default values are provided should you prefer to tweak just the critical pages.

The generated XML is compliant with the Sitemaps protocol so that it is ready for submission. If you manage multiple sites in the same Magnolia instance, you have the option to create a separate sitemap for each site.

Magnolia's Sitemap template is an additional component, unrelated to the XML sitemap. It allows you to include a sitemap page on your site without coding or configuration. It serves as a further navigational element, by offering an overview of content. This feature follows SEO best practices by assuring that each page is accessible by at least one static text link.

W3C compliant code

Antti Hietala — Thu, 06 Jan 2011 09:50:00 GMT

This post belongs to a series about search engine optimization (SEO) with Magnolia CMS. Today we look at creating W3C compliant code.

In order to crawl and index a website, a search engine has to be able to read and interpret its code. A page coded in compliance with standards developed by the World Wide Web Consortium (W3C) is simpler for search engines to parse.

The standards page at W3C lists more than 100 specifications, ranging from accessibility to XSLT. While this can seem overwhelming, four of the standards are key:

Valid code (HTML, XML, XHTML)
Semantically correct code
CSS
DOM and ECMAScript

Valid code

The Magnolia Templating Kit is a best-practice framework that produces valid XHTML. The templates can be used to build compelling websites quickly and efficiently without the need for technical expertise.

The use of XHTML markup is declared with a DOCTYPE element, as you can see in the source code of any page created using a Magnolia template.

The page validates against the Document Type Definition (DTD) declared in the same element. The structure of a Magnolia page conforms to the document type by having an html element with the XHTML namespace declared, a head element including the title element, and a body element. All elements and attribute names are written in lower case and attribute values are enclosed in quotes. All non-empty elements (e.g. p, li) are properly terminated with a closing tag. All empty elements (e.g. br, hr, img) are properly terminated with a trailing slash (<br />).

Semantically correct code

Semantic markup describes the meaning of a page in terms of content, rather than the design.

In Magnolia templates, heading elements (h1, h2, h3 etc.) are used in the correct order without skipping levels, lists are used to list items, and tables are only used to present tabular data, not to create page layouts. Try removing CSS, JavaScript and images from your code. Is the code still understandable? Does it make sense to a reader? If yes, then it is semantically good code.

CSS

Cascading Style Sheets change the appearance of page elements by assigning styles to them. A style sheet gives a consistent appearance to an entire site. Semantic XHTML and CSS can improve your rankings, as it leads to better crawling, faster website response, and better accessibility and usability, which gives you higher conversions and increases your linking chances.

The look and feel of a Magnolia-based website is controlled by a single CSS file. Since the XHTML structure is designed to be styled with CSS, appearances can be changed without touching templates. Designers working with CSS don't necessarily need to know anything about Magnolia in order to create a compatible site design. They can start with the static HTML prototype that ships with the system, pick an HTML structure that is a close match to their original design, and then modify it further.

Magnolia CSS includes some browser-specific properties such as -moz-border-radius that are not part of the official CSS specification. Such properties are not used in areas critical to usability and fall back to standard properties gracefully.

DOM and ECMAScript

Document Object Model (DOM) provides a scripting language such as ECMAScript, the standardized version of JavaScript, easy access to the structure, content and presentation. DOM is future proof; it will allow any scripting language interact with the document. As long as you site has useful content, JavaScript code will plays virtually no role in SEO optimization. The only thing that matters is where the code resides.

Magnolia uses jQuery, the most popular JavaScript library. jQuery is a cross-browser library designed to simplify client-side scripting of HTML. It supports DOM element selection, traversal and modification. The entire library is stored in single external JavaScript file rather than embedded in the page HTML. An external file saves bandwidth by reducing page length, yielding faster downloads.

Search Engine Optimization

Antti Hietala — Tue, 04 Jan 2011 15:44:00 GMT

This is the first post in a series on search engine optimization (SEO). I will be looking at key SEO factors identified by the SEOmoz.org consulting group and pitting them against Magnolia CMS, a Web content management system.

This series should be interesting to online marketers, people employing web communications, and anyone looking to increase their site rank. Download all posts in a single PDF.

What is SEO?

The purpose of SEO is to enhance the volume and quality of traffic directed to a website via search engine results. Search engines aim to provide users with the most relevant results, while webmasters attempt to tweak their sites in order to move it up in the rankings and attract profitable, organic traffic. SEO began in the early 1990s, and quickly degenerated into a tug of war between search engines and webmasters. For each new weighting factor introduced by the engines, crafty webmasters invented means to circumvent it. As a result, many undeserving sites achieved high rank at the expense of great sites providing valuable information. The Web became cluttered with content designed to satisfy the engines as opposed to users.

Today, SEO is practiced in a more cooperative environment in which search engines provide advice to webmasters. The engines will probably never fully disclose the algorithms that drive their crawlers, but the fundamentals of SEO are firmly established.

Google is the dominant player, with more than 80% of the search market, followed by Bing, Yahoo, AOL and Ask, according to the findings of statowl.com:

Coming up next

In subsequent posts I will cover the following SEO best practices:

M&M - Magnolia and ModeShape

rah003 — Mon, 03 Jan 2011 13:27:16 GMT

End of the last year and beginning of this I've spent trying to get Magnolia work with ModeShape. There were issues with both of the apps. On one end, Magnolia had issues with the Modeshape session data refresh strategy, on the other one, Modeshape was sometimes stricter then JCR spec required it to be when it came to queries. All of those were elementary issues that were relatively easy to overcome and I got Magnolia on ModeShape running and working fine.

The next task was to create a bundled webapp so that anyone who wants to try this combo can just grab it and run. Again, this was easily achieved ... few exclusions in poms necessary, but apart from that smooth ride.

Last but not least task before the release was to choose persistence configuration. During my testing, I was happy to use in-memory persistence which of course meant I had to re-install on restart, but was also pleasantly fast.

The default bundle of Magnolia with JackRabbit as a repository comes with Derby to make configuration as simple as posssible (of course for production use you will reconfigure the DB to something else, but to get you quickly started, Derby is small, fast and seamless to get running in the embedded mode).

Obviously, I choose to do the same for ModeShape, but unfortunately, current version of ModeShape doesn't run on Derby (see MODE-XYZ and HHH-3434 for details). Having failed to use Derby I moved on to the next embedded DB - HSQLDB. There i ran into an unexpected issue. I could get the configuration that would perform well, but would not persist data, or I could get the configuration that would persist, but performance would be awful. It was all about the configuration string. Using jdbc:hsqldb:mem:... made DB perform well, but would not persist any data. Using jdbc:hsqldb:file:... or just jdbc:hsqldb:... would persist the data, but would be terribly slow. :(

The next I moved on the H2 DB, but run into same issue as with the HSQLDB - either fast or persistent. Somehow I don't think that this feature is specific to the DB implementation, but has to do something with the hibernate configuration. Searching Hibernate docu, however didn't reveal any obvious solution to the problem.

And just so you know I'm not exaggerating when I claim that the DB is slow - with Derby & JackRabbit, I get Magnolia CE + STK installed in few minutes. In-memory ModeShape config takes about 2 minutes, however HSQLDB or H2 & ModeShape, it takes about 1.5 hour.

So at the moment I'm stuck in trying to make out some working configuration that doesn't require external DB and yet is still persistent. For those interested, here's the config file used to run against HSQLDB, the one for other databases is nearly identical, barring the different dialects, connection strings and drivers.

Latest updates:

Using MySQL the installation runs for about 10-15 minutes, so it is much better then other DBs, but still few times slower then same config with JackRabbit.
Other people confirmed in IRC (#modeshape @ freenode) performance issues with importing middle to large amounts of data.
I somehow suspect that my issues have something to do with the fact that Magnolia keeps multiple sessions open and performs refresh on change.

Blossom 1.2 released

Tobias Mattsson — Thu, 23 Dec 2010 11:56:00 GMT

Magnolia Blossom 1.2 has just been released.

This release brings a bunch of new features and fixes two important bugs. A new sample is also available, its a webapp project that requires nothing more than a plain maven installation to start up.

The biggest new feature is spring integration in content2bean bringing dependency injection and AOP. This can be used directly from your spring xml files to load beans from the repository. When changes are made in the repository the bean will be transparently reloaded. This allows for easy reconfiguration of a running application.

The new annotation @InitSaveHandler allows you to customize the savehandler to use for saving a dialog.

There's also a few additions that make writing controllers even easier. For instance you can get the Content object passed directly to your handler method and you can return redirects by returning the uuid prefixed with the name of the repository. As an example; return "website:" + content.getUUID(); would return a redirect to a page.

The sample is available in our subversion repository. Check out the sources and run mvn jetty:run-war to start it up. Consult the reference documentation for more details.

Cheers and merry X-mas!

Add some Balsamiq to your mockups

noreply@blogger.com (Andreas Weder) — Tue, 14 Dec 2010 10:49:00 GMT

I've been creating mockups intensively over the last couple of weeks. I've used Balsamiq Mockups for all of them. This is an Air-based tool which provides for rapid and easy creation of mockups for all kinds of applications, web and mobile apps.

It's a great tool. I'm sure you've heard about it already, since this product just hit a sweet spot. Mockups allows to quickly add elements from a pre-existing library of UI components. You can configure their most vital aspects using toolboxes and you fill in content using simple text areas supporting a wiki-like syntax. Components quickly snap to a grid and align themselves with their siblings.

Sketching with Balsamiq Mockups

The app is a breeze to use. It has hit a sweet spot, because creating mockups is about sketching and the quality of sketching lies in quickly drawing something with coarse precision, but just enough detail. When you sketch, you don't care about exact measures, but you want to make sure that UI elements are aligned properly so that the implicit order and grouping you define can be easily grasped. If this is the case, your ideas are understood and thus sell better.

In the latest version of Mockups, Balsamiq have added a powerful new feature called symbols. You can now create your own library of custom components and add them to your mockups. You may override aspects such as colors, text and the position of sub elements in every symbol instance. More than that: if you change your symbol, your changes are being propagated to your mockup next time you open it. Mockups even does a good job in preserving your overrides.

The Symbols feature demonstrated

Symbols is a great time saver, but also a well designed extension to the existing concepts, which, at the same time, allows you to bundle your components, pre-existing components and actual mockups in a natural way.

I'm using Mockups for actual interface design and sometimes visualise concepts with it as well. Now, I thought at the beginning that I could use a larger list of pre-defined icons. More UI components. More features. But I've found that most of the time, the simplicity and restrictions of the app helped me focus on the actual work at hand. After all, my work is about designing interfaces, not graphics or web design. And if something is really missing, a corresponding site with additional mockups and Photoshop are there to fill the gap.

Oh, and it comes in various plug-in flavors. We use the Confluence plug-in to directly place mockups inside our wiki pages. A click and I edit the mockups from within the page - unfortunately without the Symbols feature for now, but we can expect this to be retrofitted rather sooner than later.

If you don't know Balsamiq Mockups, give it a spin and see for yourself. Trust me: you'll get used to the sketchy look. And your customers as well.

Groovyness - the agile paragraphs

Philipp Bärfuss — Wed, 08 Dec 2010 16:37:00 GMT

Back on track. After releasing Magnolia CMS 4.4 my mindset moves back to Magnolia 5.0. While playing around with groovy to merge the changes from the 4.4 branch back to the trunk I came up with a idea which I would like to share and get some feedback from you.

Using a groovy builder (DSL) we could make the paragraph definition very concise

include the dialog definition in the paragraph definition
add a closure for rendering the content

example: text and image paragraph

What we get:

no configuration (update, ...)
a single concise definition (all in one place)
agile

Note: this will not replace any other ways of defining paragraphs or dialogs its just a groovy alternative. But since we allow pragmatic registration of dialogs, paragraph, ... in Magnolia 5.0 such an implementation should be rather trivial.

Magnolia 4.4 is released !

Grégory Joseph — Wed, 01 Dec 2010 16:24:35 GMT

Good news: Magnolia CMS 4.4 has just been released! If you’re here, you’ve probably already seen the official announcements, be it in the newsletter, the user-list, the forum, Facebook, or even press releases, so you know all about the new … Continue reading →

Groovy Secret Santa

Grégory Joseph — Thu, 11 Nov 2010 11:14:01 GMT

Just had a little bit of fun coding this: import org.apache.commons.mail.SimpleEmail def persons = new File('/Users/gjoseph/Desktop/magnolia-secret-santa-people.txt').readLines('UTF-8').collect { def data = (it =~ /^(\p{L}+) (\p{L}+) $/) return [ f: data[0][1], l: data[0][2], e: data[0][3] ] } def santas = persons.clone() Collections.shuffle(persons) … Continue reading →

Region Editing vs. The Cloud of Bars [Updated]

noreply@blogger.com (Andreas Weder) — Wed, 10 Nov 2010 15:32:00 GMT

[Update: Region Editing has been renamed to Area Editing - the wiki page describing the concept has moved to here.]

Did that image look familiar to you?

This is how a page using an article template typically looks like. For each major area of the page, represented by a paragraph containing other paragraphs (a collection paragraph), you'll find an edit bar and a new bar. The two are not visually connected. For every sub paragraph of any such area, there's one additional edit bar. You end up with what I call the Cloud of Bars.

I've been working on page editing lately and have come up with a concept I call Region Editing. It's probably nothing new. The idea is to hide most bars when you actually don't need them, while still showing the top-level bars to make the page structure apparent immediately. The same page looks like this when using region editing:

The page structure is clear - even if you imagine there'd be no grey backgrounds -, there's fewer bars and the preview has already improved quite some while you're still editing the page.

I've written a page on region editing in the User Experience wiki space. It describes what I'd like Magnolia to do for me (the Story), then talks more about the actual flows and requirements (the Desired Behaviour), and, most interesting probably, it sports a number of Mockups illustrating how I imagine this to look like and which are based on both the story and the behaviour description.

Please have a look and let me know what you think - leave a comment or start a discussion in the "Development" forum on the Magnolia Forge.

Wait, why don’t you know about our Forum yet ?

Grégory Joseph — Wed, 27 Oct 2010 11:35:22 GMT

4 months ago, I was whining about the fact that I couldn’t find a good-enough forum software. In the background, we always wanted to improve our own forum; there were many shortcomings and the task seemed daunting. Well, that was without … Continue reading →

Magnolia 4.4 brings staged deletion of pages

noreply@blogger.com (Andreas Weder) — Tue, 26 Oct 2010 16:00:00 GMT

"I can work on a site first and without worry, then publish the changes when I'm ready, but a page is deleted immediately? With no way to undo this?" I bet you've heard this before, especially when you've taught somehow how to publish content with Magnolia.

The next minor release of the Magnolia CS will sport a first shot at a long-awaited UX improvement, the staged deletion of pages. Starting from 4.4, a page is no longer immediately deleted and immediately removed from a subscribed instance, but instead is marked as "deleted" first, then removed during activation. So if you've configured a work flow on your systems, a reviewer may actually reject or accept the deletion, and if you're running without work flows, then you can still undo a deletion by restoring the previous version of the page before activating the change.  

It's not yet optimal, I think, but it's a good start. A trash would be nice to have, a simpler way to not-delete a page marked as "deleted" and even a way to undo an entire deletion. There are some technical restrictions currently, which won't allow us to go down the full path, but I'm sure this already will make most of you happier.

Expect more improvements on page deletion in M5.

Welcome to MaUI

noreply@blogger.com (Andreas Weder) — Tue, 26 Oct 2010 15:52:00 GMT

Hi Magnolians, and welcome to my new blog focussing on the design and the development of the next generation user interface of the Magnolia product line.

I've joined Magnolia in October this year and will be responsible for shaping the user experience of our products, in particular the Magnolia CMS. While my dev team mates are busy working on the 4.4 release, I'm mainly focussing on Magnolia 5, or M5, in short. As you know, we plan to overhaul the user interface in the next big release. Since the time frame is ambitious, the first flows and mockups have to be discussed and ready for implementation in a few weeks already.

Magnolia's company culture is often described as open and communicative. I've felt that from day one - from the way ideas are discussed internally, from how concepts are readily published on freely accessible pages on the wiki, to the pleasantly creative atmosphere of our work place. I'm excited to work with a great team on a great product. I've started this blog as an attempt to keep up this spirit of openness and to keep you all posted on what's going on on the UX side of things.

Magnolia (or obinary, how the company was called back then) has made a big impact a few years ago by providing an easy-to-use CMS on top of state-of-the-art JCR and Java technology. It has been an excellent choice for a Java-based content management system from day one - and it still is. I've first got to know the product with release 2.1, if I remember correctly, and have developed several webs with it since then. So I do know all its good sides, but have also seen some of its darker areas. And while the interface was top-notch back in 2004, development on it has stalled somewhat. That's why my position was created and that's why improving the user experience is one of the main goals for Magnolia 5.

I'm looking forward hearing from you, through comments, feedback, emails or even the issue queue. Also make sure, you make your voice heard in the community forums of the Magnolia Forge, because now is the time to request new UI features or improvements to existing functionality. I'd like to know what you like about Magnolia and where you see room for improvement.

Thanks for participating - or just following this blog.

Magnolia CMS 4.4 - Milestone 1

Philipp Bärfuss — Thu, 21 Oct 2010 10:25:00 GMT

The team has finished its first sprint of Magnolia 4.4 development. As you might know, we aim to deliver some acutely missed enterprise features with this release.

If you want to see some of the features in action please have a look at the video done by Federico:

Features we have implemented in the first sprint:

Diff view (EE). We have implemented a visual diff based on the rendered HTML output.
Translation export/import (EE). Export and import of translatable text to and from CSV files. The export uses the dialog configuration to determine what should be exported and what not.
Soft locking (EE). Show a warning message if other users have a page open in the edit mode.
ModeShape support. Magnolia can now be backed with the JBoss JCR repository implementation.
FCKEditor update. We updated to 2.6.6. The most interesting feature in this version is a SpellChecker.
Early paragraph execution. Paragraphs sometimes want to execute logic before the page rendering starts. This is needed to perform operations like forward and redirect. This is now possible due to a new filter which executes the model in an early phase. This enables us to build multi-step forms (see next sprint).

In the second sprint, which will be the last one, we will mainly work on:

De-coupling deletion and de-activation. The immediate de-activation of content on deletion was always problematic. We have worked out a concept and are about to solve the issue.
Reference view (EE). A page which lists content that references a page and content the page references. This can be used to build a warning message on deletion and to show dependent content in the workflow dialog.
Multi-step forms (CE/STK). Enhancement of the form builder so that one can build wizard-like multi-step forms. Each step is created as a sub-page. Each step validates and the status is kept in the session. The concept is based on the new early paragraph execution.

Finally we want to thank Aperto (diff view), MediaCatalyst/Sony Europe (translation export/import) and fastforward (FCKEditor update) for their substantial contributions.

You can download the bundles from our Maven/Nexus repository. Be aware of the fact that those releases are definitely not meant to be used in production.

Magnolia Tech Briefs

Antti Hietala — Mon, 18 Oct 2010 09:56:00 GMT

We started publishing a new type of document this week: Tech Briefs. These are short technical articles on trends and hot topics we get asked about a lot.

The series starts with two Tech Briefs:

Performance and high availability. By good performance we understand the capability of a system to serve multiple simultaneous requests in reasonable time under heavy load. High availability refers to the degree of operational continuity in a system. In this brief we examine a Magnolia setup that focuses on performance.
Cloud. Cloud computing is a hot trend. In a cloud, infrastructure services are provided like a utility - think water or electricity. CMS administrators benefit from simplicity as they no longer need to know all the details of the underlying technology. Can Magnolia run in a cloud?

The briefs are also available as PDF. Print and read on your way home.

Sit, roll and start flow! Commands in Magnolia CMS

Antti Hietala — Mon, 18 Oct 2010 07:29:00 GMT

Commands are custom actions executed at pre-defined trigger points. Magnolia CMS uses them to send email, flush cache, take backups, import and export data and many other common duties.

A command can perform virtually any task you can write in Java like send a Tweet or upload a photo to Flickr. You are not limited to features inside the CMS itself.

Here's how commands work. A command definition makes the command available to the system. Below is a definition for the deactivate command. Its purpose is to pull a web page down from the public instance.

As you can see, the command definition has just one property, class, which identifies the Java class that should be executed when the command is called (DeactivationCommand).

Its counterpart command activate is a bit more complicated:

activate is actually a chain of three commands:

version creates a new version of the page.
startFlow starts an activation workflow.
alert sends a workflow notification to the recipient's Magnolia inbox.

When you call the parent command the children are executed one-by-one from top down.

Command definitions can contain other properties besides class. The startFlow command has a property workflowName which identifies the workflow that should be launched. Defining properties rather than hard coding them gives content editors more flexibility. Editors can replace the default approval workflow with a custom one by simply assigning it to the activate command, without having to touch code.

To find more examples of command definitions, sign into the demo (u/p: superuser/superuser) and execute this JCR query in the config repository in AdminCentral > Tools > JCR Queries.

select * from nt:base where jcr:path like '%/commands/%'

You will find the corresponding Java business logic in the SVN repository:

See also: Commands in official documentation

Vanity URLs with Magnolia CMS

Antti Hietala — Thu, 07 Oct 2010 07:18:00 GMT

Vanity URLs are short, easy to remember Web addresses used for campaigns, microsites and landing pages. They are a key Internet marketing tool. In this post I whip out my vanity cane, clip on my grill and show you how to get vain with Magnolia CMS.

A vanity URL typically contains a word or phrase that describes a specific target such as a campaign slogan. When a user visits the vanity URL they are redirected to the actual target site. The URL can be constructed using a:

trailing path: www.shell.com/eco-marathon
domain prefix: experience.virgin-atlantic.com
domain suffix: www.amazon.de
entirely unique domain name: mynavyfuture.com

The URL is often reproduced in print ads, hoping that the short and snappy look makes it easier to remember.

Magnolia CMS provides two approaches to creating vanity URLs:

1) Virtual URI mapping is used to create path-based vanity URLs. In this mechanism a trailing path is mapped to an actual page. In the configuration example below, www.example.com/winter2010 is forwarded to www.example.com/marketing/campaigns/winter.

You can choose from three types of redirecting actions:

forward hides the true target URL from the visitor. The typed URL remains in the address bar.
redirect displays the true target URL in the address bar.
permanent 301 redirect is a search engine friendly option.

2) Multi-site support is used to create domain name based vanity URLs. This feature is available in Enterprise Edition Pro. It allows you to map complete domains, domain prefixes and suffixes to a site.

In the example below, a user who enters winter2010.example.com is redirected to www.example.com/marketing/campaigns/winter.

Unique domain names can be configured in a similar fashion. In the example below, both example.com and winter2010.com point to the same site. However, winter2010.com is mapped to a special campaign section of the site. A user who enters winter2010.com is redirected to winter2010.com/marketing/campaigns/winter.

Note! You must register domain names with a domain registrar first. Then make sure that DNS entries for the domain names you map point to the server hosting your Magnolia instance. Domain mapping in Magnolia AdminCentral alone is not enough.

Unconference 2010 - Magnolia 5.0 and Roadmap

Philipp Bärfuss — Fri, 24 Sep 2010 08:49:00 GMT

This year's Magnolia conference was a very great and inspiring event. At the community day we had few presentations related to Magnolia 5.0 which's slides we like to share with you:

Magnolia 5.0 - Three perspectives
A brief overview about where we stand and what we plan to achieve if Magnolia 5.0. You are missing the demo, but well ... there is still some valuable info in it.

Magnolia 5.0 'GenUIne'This is the presentation as given at the conference 2009 for those interested in the background.

Magnolia 5.0 - Why VaadinMy colleague Daniel Lipp talked about why we have chosen for Vaadin.

Magnolia 5.0 - JCR 2.0 and Content APISome insights about what JCR 2.0 means for us and how we can improve the current Content API and gain performance.

Magnolia Roadmap - Beyond 5.0About Magnolia 4.4 and STK 2.0.

Magnolia at JavaOne

rah003 — Tue, 21 Sep 2010 14:41:51 GMT

For anybody interested, we are giving a talk about repositories and content management in general on Thursday 12:30 at Hilton SF, Yosemite B. Session ID is S314239.

Feel free to drop by and ask also for Magnolia related questions should you have any. We have reserved some time also after the presentation should there be the need.

SwingX 1.6.2 released

rah003 — Tue, 21 Sep 2010 14:34:18 GMT

As it became almost a tradition we have rolled out next SwingX release just before the SwingLabs BOF at JavaOne last night.

You can get the release from our website, or directly from the java.net or also from the maven central repo. Please note that the artifactID has changed from swingx to swingx-core due to changes in the structure of the project.

Thanks a lot to all who contributed to this release with both the bug reports and the fixes.

Enjoy.

Why Vaadin - proof of concept

Philipp Bärfuss — Tue, 31 Aug 2010 15:20:00 GMT

Now, three weeks after deciding for Vaadin, we have finished the very first prototype.

To complete the current sprint we have released the result as the first milestone. We created a short video to demonstrate the current status so you don’t need to install it yourself. Please be aware that we have not focused on things like user experience design and theming. We just wanted to implement a mini AdminCentral and prove that Vaadin works for us.

Video: by Federico Grilli

Note: if you use the current milestone release you will have to point your browser to /AdminCentral/ as otherwise the old AdminCentral will be served. We will switch that as soon the new UI is functional enough.

Our experience
We had a quick start and were able to implement things like the tree view, accordion menu and dialogs very quickly. So Vaadin definitely fits our team and will fit other Java oriented teams well.

Extensibility
It is the ultimate goal to make the new AdminCentral extensible so that everybody can contribute rich modules and paragraphs to the system easily. As expected the server side characteristic of Vaadin helped a lot and allowed us the improve the wiring of the components:

Provider interfaces for the various elements (dialog field, accordion menu actions, ..)
No dependency on the Content API
DSL/Builder APIs can be build easily (not yet done)
All is instantiated/configured by Content2Bean

History support
We still need to improve things but the accordion menu already supports history, and if you switch the tree views (website -> config -> website) you will see that the state of the former selection is kept. We also want the complete status (selected page) to be “bookmarkable”.

Page editing
It was the goal to prove that we can embed a Vaadin application into an existing web page and that we can inject Vaadin components like the edit bars or dialogs. This worked, and since the client side coding is done in GWT, we did not need to leave the Java world. As always, once you leave the well-treaded path you have to overcome obstacles but we learned a lot, found traction and finally succeeded.

Now that the basics are done, we will have to optimize the initial loading time. The produced script is definitely not small (170k) and has to be cached. Setting the correct response headers will do its job. We also plan to add the edit bars already in the GWT entry point and only bind them later to the server side components. It might be that we even move bigger parts of the code to the client side, but since this is GWT backed code, it is not different from what we had to do in the "Plain GWT" approach.

Next steps
Many things were done and decided quickly so we need to finalize and clean up in the next sprint (the last before the conference). Therefore, we will improve the naming and streamline the architecture a bit.

Now that we can build the dialogs by code we want to show that it is feasible to write a nice dialog editor. How fancy is that!

Looking forward to discuss/argue at our conference ;-)

Why Vaadin - line of argument

Philipp Bärfuss — Wed, 11 Aug 2010 15:09:00 GMT

While I told in my former post how it came that we left the GWT/ExtGWT couple behind us and finally deciding for Vaadin, I want to elaborate why we think Vaadin is the best option.

First I will explain how Vaadin helps us to solve some of the crucial problems and why it is so effective to build the new AdminCentral with it. Afterward I will response to some valid concerns raised by the Magnolia CMS community.

Benefits

Server side execution
Executing UI events on the server is controversial - more on that later - but it has tremendous benefits.

Reflection can be used. While GWT code can't use reflection server side code can. This is for instance very helpful when we transform dialog definitions into real dialogs.
Security respected. At any time we can use ACLs to define what should be possible in the UI.
Less web services. The UI is build on the server, but rendered on the client. So there is no need to define additional services for receiving dialog and tree descriptors.
We just have to expose the content related stateless REST services.
Agility. With GWT it is difficult to support agility as you cannot change the final code without compiling it. With Vaadin we can for instance use our powerful Groovy support.
Magnolia API. Full Magnolia API can be used and no DTOs are needed.
Testing. All code can be tested with normal junit test cases. Even the UI code. The server side widget is linked to the client side widget by annotation.

Efficiency
We are a small team and efficiency matters, as time-to-market is crucial.

Collaboration. The two communities and the backing companies are looking forward to support this collaboration and to help each other to make this successful.
Documentation. Vaadin's documentation is just great. The Book of Vaadin, which is freely available, makes it easy to get started.
Compilation. No GWT compilation is needed unless a new client side widget has to be written which should be rarely the case once AdminCentral is rolled out. Composite widgets are not requiring any GWT coding.
Theming. As many other things theming is a service provided by Vaadin. Once we decided for a design it will be easy to implement a Vaadin version.

Third party and custom modules
It will be much easier to adapt the AdminCentral and plugin module specific UI than if we had chosen for GWT. Firstly one hasn't to perform GWT compilations and secondly reflection/injection will be used to plugin into the AdminCentral.
It is the ultimate goal to make the AdminCentral extendable and usable for more generic content management related use-cases.

Performance Concerns
After the decision was made the community raised concerns about the performance of such a solution. Originally I shared this concerns but want to explain why I think they are not justified or at least don't neutralize the benefits.

Factor in the scenario
We are going to develop the AdminCentral and not the next generation gmail application. The AdminCentral is the backend and is typically used intranets.

Number of Requests
The server side event handling will lead to more requests and will add the network latency to most of the user interactions. This sounds dramatic in the beginning but is it really true? Let's have a closer look.

Scenario A) Ask for data (GWT) = send event (Vaadin)
Most of the user interactions will result in a request to the server. The only difference is the reason for sending it. While GWT will ask for the data to show or send some data, Vaadin will send the event information.
Examples:

creating a page
moving a page in the tree
open dialog
click save button

Scenario B) One request to rule them all
Note that any client side UI will also request data from the server. So it is actually not unlikely that a client which uses stateless REST services will send more requests to assemble the data its needing.

A typical use-case is opening a dialog for paragraph editing which needs additional information to fill a table or read information from a page we are linking to.

GWT (2 - 3 requests):

event -> execute open-dialog action
ask the server for the dialog to open and its descriptor (might be cacheable, but not necessary due to some complex rules like paragaph to dialog mappings, ..)
populate the dialog -> request to fetch the data details
we need some sub-nodes to fill in a table -> request to fetch the data

Vaadin (1 request):

event -> immediate request to server
event handler builds the dialog (this is fast as no rendering is involved)
some data is read. Reading additional information as meta data and sub-nodes are at hand
bind the data to the dialog
Vaading sends back a JSON representation of the UI changes
client side rendering engine applies the changes

Here we actually save requests by Vaadin's roundtrip approach.

Scenario C) Visibility changes - Vaadin says not No to client side events
In other use-cases as clicking on a tab or navigating in menus none of the frameworks sends events to the server. In both cases it is client side code which toggles the visibility.

Conclusion
While we surely expect to have more requests, we don't think that we talk about doubling the numbers of request. In fact I believe that we will not see an increase bigger than about 10-20 %.

Responsiveness of the Demos
Some stated rightly that the ExtGWT examples are snappier. In my opinion this is due to the fact that the examples just don't use server side services to read the data. But is this a realistic scenario? How often will you perform user interactions without having to read or send data?

Example: Sorting in the table
Client side sorting is a nice thing to do, but normally you will request the data on demand (paging). How will you sort the data which you have not received yet?

Optimize where you expect the biggest performance gain
While we can discuss for a very long time about the client performance I think that an end user will judge the overall performance including search, filtering of data, ...

And here we can do much on the server side. I prefer to invest time on that end than to optimize the very last bit and byte sent over the wire.

Content API

return iterators not collections (same as JCR)
don't apply the security checks, delegate that to JCR (possible since JCR 2.0)

JCR / Content Structure

mixin for metadata instead of using a sub-nodes
versioning friendly structure: extra node to separate paragraphs and subpages
use more and proper node types: searching, ..

I am very sure that the resulting responsiveness will benefit much more from this kind of improvements.

Proof of concept
As for now we have decided for Vaadin but still we are just entering a proof of concept phase in which we want to proof that Vaadin is really the better choice. Here are the scenarios we explicitly test.

Page Editing
Here we expect some GWT coding. It is sufficient if the dialogs and toolbox can be Vaadin components.

show that we can inject behavior into existing HTML: add edit button which opens edit dialog
mouse over: show paragraph information on mouse over
inline editing: proof that inline editing will work

Tree Grid
Vaadin is working on the tree grid. If we find some shortcomings they will most likely help to improve it.

move: drag and drop
context menu: per node type
editable row

Paragraph
If we use a technology to build the new AdminCentral we want to ensure that it can be used to write more complex paragraphs as well. As an example I take the page commenting. Each page has a commenting paragraph. The scenario is different as it must work for high traffic websites too.

initial form should not create a session (the page should be served by the cache)
coexistence: two independent Vaadin paragraphs

Conclusion
We really think Vaadin has great potential and deserves its chance. Still we are new to that technology and will have to verify that our assumptions are right.

We won't rush into anything

Why Vaadin - the Odyssey

Philipp Bärfuss — Wed, 11 Aug 2010 08:42:00 GMT

Before I write why we have chosen Vaadin I have to wrap up how it came that we queried our first choice: GWT/ExtGWT.
After the first two Magnolia 5.0 sprints we realized that we have to reconsider our initial decision. We still liked the GWT approach but also faced some challenges which justified such a step.

All in one compilation. To optimize the resulting JavaScript code GWT removes unused methods and shortens the names. While this produces minimal and fast code, the outcome is unpredictable and prevents method calls from one module to the another unless they were compiled in the same step. In Magnolia CMS you will install additional modules or update them at run time. This requires a recompilation of the whole AdminCentral unless other tricks are applied.
We planned to re-compile on demand but this conflicts with the exhausting compilation time. Delivering non-optimized JavaScript was also considered. And finally we opted to expose some methods by using gwt-exporter but this would reduce the interoperability of modules.
Compilation time. The GWT compilation time increases with the number of inherited modules (ExtGWT is quite heavy) and the produced permutations (browser, languages). If we want to support 5 browsers and 10 languages this multiplies compilation time by 50. At this point the compilation already took 2 minutes on a local computer and 12 minutes on our Hudson server.
This is not so relevant while developing due to the fantastic development mode but it contradicts our concept of executing a compilation on Magnolia module installation/update. Possible workarounds are: use a draft compilation first or compile permutation on demand but it seems like a mine field.
MVP pattern. As recommended we wanted to apply the MVP pattern but ExtGWT has its own concept of handling events and this conflicts with the proposed approach by Google. The goal is that the presenter layer can be tested with normal JUnit test cases without extending GWTTestCase which runs a browser under the hood and is terribly slow. We could wrap the ExtGWT components but this won't lead to a slim architecture design and to billion of interfaces.

So we dropped ExtGWT and designed a plain GWT approach:

Use gwt-exporter to expose a plugin mechanism
Use GWT 2.1 which brings a new MVP framework (at the time milestone 2 release)
Write our own widgets or write a wrapper for few components

It is not surprising that we brought the ExtJs/Javascript approach back on the table at that point. Once this happened the Vaadin supporters realized their chance and raised their hands. While I never liked the server side part of Vaadin and excluded it from earlier evaluation phases for that reason, I was desperate enough to reconsider that decision ;-)

We launched a survey and filled a decision table.

Survey

None of the approaches won the survey but the Vaadin community got attracted and this lead to same phone calls with Joonas Lehtinen, the CEO of IT Mill - the company behind Vaadin. So we realized that there is potential for collaboration for the two communities and companies.

Decision Table
We dropped the ExtJs/Javascript for the simple reason that we didn't have enough motivation and knowledge to go for it. Some think we are lame but have you ever tried to make a cool product with an unmotivated team which in addition lacks the skills to fulfill the task? I hope not.
While Vaadin got the most points (39 points), GWT (29 points) was not yet dismissed as the decision table was only meant to give us an overview and we have not weighted the criteria.
So we ended up with having the two valuable options:

Plain GWT
Vaadin

Team Voting
At the end we had a final voting in the team. The result was 4 against 2 in favor of Vaadin.

So that was it: Vaadin

Reasoning
In the next blog post - following today - I will explain why Vaadin was the prize winner and how it solves some of the bigger problems we faced with the plain GWT approach.

Magnolia CMS Technical Guide now online

Antti Hietala — Fri, 30 Jul 2010 07:21:00 GMT

I started writing a white paper on Magnolia CMS architecture couple of months ago. I initially targeted analysts and CTOs, thinking 10 pages would be optimal. After reviewing drafts with Philipp we felt we had to cover more topics and match architectural features to business benefits. The paper turned into a book!

Magnolia CMS Technical Guide has new architecture diagrams that make complex topics such as the templating mechanism and clustering easier to understand. I also talk about why we chose the JCR Java Content Repository, explain the module system and show internationalization examples.

Magnolia partners can download a PDF from the secure partner site.

Day to be acquired by Adobe - implications?

Boris Kraft — Wed, 28 Jul 2010 11:30:00 GMT

Today, Adobe announced to buy Day Software, another WCM manufacturer based in Basel, Switzerland, who uses the same technology foundation as Magnolia. As an initiator of the JCR standard and main contributor to Jackrabbit (the JCR reference implementation), Day is certainly important for the JCR ecosystem.

Let's have a look at the possible implications of the deal for Magnolia.

Adobe bought Omniture not even a year ago for 1.2B$, which was/is the leader in web analytics. With Day's CQ (their CMS), Adobe now has the final part in their portfolio to create, analyze and publish content. (I couldn't find out yet what part "Adobe Publish" plays. Seems to be an SaaS platform, so probably not competing with CQ.)

With Adobe, Day can now enter the US market, something that was difficult until now (even if they are no longer Day). Adobe buying Day further validates the JSR-170 standard, makes Magnolia's technology stack better known and more attractive for potential buyers. Interest in Magnolia will rise along.

Adobe might well underplay the repository part and the visibility of JCR might decline in turn. We typically do not sell Magnolia because of JCR (although it does happen), and once we have a prospect, saying that he gets the same repository technology he would buy from Adobe will certainly be soothing any worries. Good for Magnolia again.

On the technology side, Adobe will either strengthen JCR and keep Day's CTO and JCR brainchild David Nüscheler, or David will leave to pursue his vision regarding repository technology elsewhere. David will get a lot of $ out of the deal, so he will have little reason to work in a direction he doesn't like if the alternative is to spend the rest of his life on his own island watching whales make love in sunset.

In either case, it should not mean too much worry for repository implementations. Even if Day under its new owner stops contributing to Jackrabbit, JBoss just launched ModeShape (tested extensively using the best test app they could get - Magnolia CMS). Good thing Magnolia is independent of the underlying repository implementation.

The business aspects

Adobe is building huge integrated application suites and I bet that CQ will not become cheaper by being part of that. On the contrary, Adobe aims to provide value through an integrated publishing chain for the customer (creation, analytics, publishing) and will monetize that value.

Adobe buying Day brings insecurity to the current Day prospects (and clients) and will result in more prospects leaning towards Magnolia. In addition, many people don't want to talk to the likes of Adobe because they rightly fear that Adobe will sell them every product in their portfolio, even if all they ask for is a WCM.

The market will split between those seeking an expensive integrated application suite (Adobe Livecycle) and those seeking a powerful and focussed WCM product that is easy to use, extend and integrate with their business needs (Magnolia CMS).

Summary

Adobe buying Day will be good for Magnolia and Magnolia customers; it will most likely not be good for Day customers (the aim of a takeover rarely correlates with the goals of the existing customer base, otherwise the existing customers would have bought something else). Thanks to Adobe buying Day, Magnolia's technology stack will gain more credibility, and with clients like the US Navy (navy.com), EADS.com, Sony Playstation and many other multi-nationals in its portfolio, it is easy to see that Magnolia CMS is a very credible alternative to becoming dependent on a single integrated product suite delivered by a rather closed-sourced billion $ company.

Still looking for “the” perfect forum software

Grégory Joseph — Mon, 14 Jun 2010 17:58:31 GMT

Since a couple of weeks, I’ve been looking, on-and-off, for “the” perfect forum software. The Magnolia community needs a (new, better) platform. At the moment, we’re relying on a wiki (good for draft documents, not so much for discussions), an … Continue reading →

JavaOne updates

rah003 — Tue, 11 May 2010 08:14:00 GMT

Two talks at JavaOne this year:

S313580 - "Swinglabs Dev Update" with Karl and Alex ... I hope guys will do most of the talking :D
S314239 - "Building Content Management solutions based on Java Content Repository" together with Greg

BTW for those wondering what is happening with the swinglabs.org, server have been recently moved around yet again. It is now in so secure location that I can't even access it anymore and server is also not able to reach outside to java.net to retrieve content from svn and/or existing releases binaries.

It's all kind of sad, but I hope the access issues can be solved out soon and server will be back. If not I'll try to setup another build server and mirror of the site in some alternative location.

Osborn's Checklist

Philipp Bärfuss — Tue, 27 Apr 2010 12:42:00 GMT

The second method we applied during our Magnolia 5.0 kick-off session is a pearl of a creativity technic. The method is simple but will produce useful outcome in many scenarios.

Following the checklist as found at :
- http://www.ifm.eng.cam.ac.uk/ctm/idm/tools/concept/osborn.html

Other uses	New ways to use as is? Other uses if modified?
Adapt	What else is like this? What other idea does this suggest? Does past offer parallel? What could I copy? Whom could I emulate?
Modify	New twist? Change meaning, colour, motion, odour, taste, form, shape? Other changes?
Magnify	What to add? More time? Greater frequency? Stronger? Higher? Larger? Longer? Thicker? Heavier? Extra value? Plus ingredient? Duplicate? Multiply? Exaggerate?
Minify	What to subtract? Smaller? Condensed? Miniature? Lower? Shorter? Narrower? Lighter? Omit? Streamline? Split up? Understate? Less frequent?
Substitute	Who else instead? What else instead? Other ingredient? Other material? Other process? Other power? Other place? Other approach? Other tone of voice? Other time?
Rearrange	Interchange components? Other pattern? Other layout? Other sequence? Transpose cause and effect? Change place? Change schedule? Earlier? Later?
Reverse	Transpose positive and negative? How about opposites? Turn it backward, upside down, inside out? Reverse roles? Change shoes? Turn tables? Turn other cheek?
Combine	How about a blend, an alloy, an assortment, an ensemble? Combine units?

I admit that this technic fits best situations in which you have to overwork an already existing something - like in our case a CMS ;-) It is less useful if you start from scratch. But this is why I find this method so great. Then isn't it more often the case that you rather overwork something than that you start from scratch? And unfortunately one uses creative technics mostly when starting a project but less once you are in the process of maintaining it! But this is the correct moment to use a technic like this, because you will systematically over-think the current solution and will improve it.

I also like the method, because it can be used with any team and it is easy to convince others to use this method: common lets verify it against this checklist!

To often we just focus about features to add but forget that we could change things or even remove components to make it better.

Other uses? Modify? Magnify? Minify? Rearrange? Reverse? Combine?

So easy is that!

Using Magnolia's inplace-templating for hot-fixes

Boris Kraft — Tue, 27 Apr 2010 12:37:00 GMT

I just realized that we forgot to provide a mechanism for the Google-Site-verification meta-tag when we migrated our corporate homepage to Magnolia 4.2 two months ago. For those not acquainted with the subject-matter: this is a way to prove to some third-party service you actually own the site (as in "have the right to modify content"). There are various ways to do so, but the fastest and least intrusive is to add a meta-tag to your html-head section like so:

<meta name="google-site-verification"
content="eGPInzT6lx6Kff8Hb2T3SCvUmnjVWeBg76G_y7PXxBk">

Now, in previous versions of Magnolia that would mean I have to grab a developer, explain what I need and hope she finds time for my request within her tight schedule. Even if she wouldn't be overly busy, starting up a development environment (IDE), checking out the project sources, adding the needed functionality, testing, and then deploying to a live instance (which more likely than not involves someone from operations, too) would be a matter of least an hour, but more likely a week would go by before you see the change in production – plus it is definitely not worth the effort for such a small and single change.

So, after this somewhat long introduction to the issue at hand, Magnolia has a solution that is simple enough for me to use. It is the "inplace-templating" module, which we install by default with Magnolia STK (but STK is independent). It simply allows to edit Freemarker templates directly in the browser, and then enable and activate them.

Here are the simple steps:

1. find the main template in the Templating Kit menu:

2. Open the editor and add the missing meta-data field

3. Check enable template (see above screenshot)

4. Activate the template

Done.

You can check the site's html source to see the change:

So not only is it really trivial to adapt your templates on the fly (BTW, you can also map the templates repository to your filesystem via WebDAV and use your favorite text-editor to change the templates); the real benefit is that you can use this mechanism to do urgent hot-fixes without involvement of anybody else.

Once things work as expected, simply notify your developer and she will roll the hot-fix into the next regular release. This way, nothing gets lost, and the whole process is highly efficient.

Inverse Brainstorming

Philipp Bärfuss — Tue, 27 Apr 2010 12:08:00 GMT

We made our Magnolia 5.0 kick-off session to define what 5.0 is all about. In this session we opened our mindset and used creativity instruments to approach Magnolia 5.0 in a less technical way.

If found this very inspiring and would like to present the two technics we used.

Lets start with the inverse brainstorming.

Sometimes it is hard to find good solutions or new meaningful features. This is especially the case if one sticks to the very same topic for quite a while. What to do? We used a destructive variation of the good old brainstorming.

One simply inverses the question and hence we tried to find ways how to make things worse.

Some of our favorites?
- direct xml editing, upload with FTP
- support IE6 ;-)
- rewrite the JCR layer
- more editions
- drop CE
- develop it offshore
- write less tests
- don't use any libraries

Oh yes, that is fun, but in the analysis we saw how meaningful this statements are. It helped us to realize how easy it is to diverge from what we really should do. It is also surprising how some of the items could have been raised in a common positive barnstorming session but probably for the wrong reason.

With this method one can definitely trigger real thinking.

Try it!

Magnolia's Standard Templating Kit reduces project risk

Boris Kraft — Tue, 20 Apr 2010 12:27:00 GMT

Today, basic web content management functionality has become a commodity readily available in a thousand shades. Where does Magnolia CMS provide value not available elsewhere? It depends on your specific use-case. To some people, Magnolia's usability is key. Others need Magnolia's flexibility, the ability to easily integrate and adapt to any business requirements or Magnolia's outstanding scalability.

However, no matter what your use-case is, to provide value, your website will typically be custom-built on top of what any "commodity CMS" provides. And it is here that Magnolia CMS provides unique benefits not found anywhere else, as you'll see in a minute.

With version 4, Magnolia CMS has introduced a ton of functionality for the front-end (publishing side) of content management. The "Standard Templating Kit" is a powerful framework to create your own custom sites. It provides:

core logic to make custom templating easier and more powerful than ever before
support for accessibility, SEO, multi-site and multi-language content
about 50 production-ready content types ("paragraphs")
nearly 20 production-ready page templates based on typical use cases (e.g. home page, section, article, event, news etc.)
a configuration framework that allows you to extend, replace or customize any aspect of STK

To showcase its functionality, a complete production-quality website is provided as an example that can be easily adapted to your needs and provides an excellent starting point to define your requirements.

As should be clear from the above list, the STK provides significant value in itself. Consider the following graph. It compares the functionality provided by a demo site, a kick-start-kit or Magnolia's Standard Templating Kit (STK):

We know that the STK provides you with a significant head start, because so much of what you need is already provided. The next graph shows the effort remaining to build your custom website given the previous examples:

Compared to other options, the Standard Templating Kit significantly reduces the effort to build your custom website. Less effort generally means you will be faster, but more importantly, it means your project will be much more predictable. You have less unknowns. And for project managers, "unknowns" means project risk.

This is why ultimately, Magnolia's Standard Templating Kit greatly reduces the likelihood of a CMS project failure.

To learn more, head over to the Magnolia CMS website, read about STK features or watch the videos highlighting Magnolia functionality.

Rendering Engine and Context

Philipp Bärfuss — Mon, 22 Mar 2010 17:22:00 GMT

In the fresh baked Magnolia 4.3 we introduced the rendering engine. Why? Well all started when I supervised the creation of some new architecture diagrams. My colleague is a technical writer, a good one, but still I had a hard time to explain the rendering process and potential integration scenarios.

At some point, lacking other explanations, I introduced the rendering engine which finally helped us to visualize the system. A backbox, a centralized thing responsible for taking a content and producing HTML results.

Here are the two diagrams (existing long before any line of code)

A) Request processing

B) Rendering Engine

More and more I started to use that inexistent thing. Finally when the gate keeper already started to close the gate I wrote two concept pages about how to implement that thing:

For Magnolia 4.3 we just introduced the rendering engine but not yet the rendering context which, once introduce too, will make all that really powerful. The context will provide things like: writer, outputstream, link transformer, parameters ... and will make the rendering completely independent of the request processing.

Funny is, that when I went back to my coworker and informed him that I implemented the rendering engine, he was only surprised that it didn't exist before ;-)

Growing the Community with the Magnolia Store

Boris Kraft — Mon, 08 Mar 2010 14:27:00 GMT

One of our goals for 2010 is to grow the Magnolia community significantly. We aim to do this on various levels, e.g.:

by providing better infrastructure
adding new communication channels,
improve the product
…and making what has been achieved more visible

The following new development definitely relates to last point in the list.

With 4.3 Magnolia CMS will sport yet another new feature – the Magnolia Store. The store will allow Magnolia users to check which modules are installed locally, download newer versions of these, download additional modules and view what is happening in the larger Magnolia community. Below is a first wireframe.

One of the reasons we want to provide this feature directly in AdminCentral is that today, the information which modules are available is maintained in too many places – at Magnolia itself, we list modules on the wiki as well as in the official documentation site. It would also be nice to have that info on the corporate site. Then some of the info is stored directly inside the module descriptors. Finally, contributors typically maintain that info on their own websites as well.

The results is a duplication of effort, maintenance hell, and most importantly it is difficult for users to find out about available modules. Today, the store looks as follows:

The Magnolia Store has been developed together with OpenMind (as you can see, the community is already hard at work) and will initially be hosted and maintained by Magnolia. It is implemented using Magnolia CMS. One of the ideas is that anybody who submits modules for the store will be able to get an RSS feed that allows him to to embed only his contributions on his own site.

Being server-side, we will be able to extend and modify the store's contents even after it is released. It will also allow us to track which modules are most interesting and add features like rating or commenting. Most of all, it should make the available modules more visible and motivate community members to contribute existing Magnolia modules.

Besides showing available modules, the store will also act as yet another communication channel, this time directly with the community. We will use it to announce available training sessions, new blog posts or anything else that the community might be interested in.

Eventually we will also directly support commercial usage of the store; for instance to sell modules or training. Right now, our main goal is to show you which modules are already available and provide a platform for our community to show their custom Magnolia extensions.

We are looking forward to see you join in and add your contributions!

From HTML to XML and beyond!

Teresa Miyar — Thu, 25 Feb 2010 13:38:00 GMT

What happens if you need to deliver same content but in different format? Sure you don't want to duplicate content. Well Magnolia CMS provides a feature that with little work lets you deliver same content in any format you need, it could be xml, or even html but optimized for newsletters.

How to do this? You need to select a template definition and add sub templates like in the image below.

This sample is using Magnolia CMS version 3.6 (feature also available for 4.x) with just one sub template defined that will render as xml when I request the page as url.xml and rendered as html when requested as url.html.

Because at the moment, sub templates do not work for paragraphs, in the template file that generates the xml content we will have to iterate through the paragraphs.

In my sample I used jsp, so I iterated main collection within a scriplet, by first getting the active page and then its children:

Content actPage = Resource.getActivePage(request);
if(actPage.hasContent("mainColumnParagraphs")) {
//some code
}

When using freemarker there is no need to use java:

[#list content.main?children as para]
[#assign paragraphContent=para]
[#if para.metaData.template='mgnlTextBox']
[#include "textBox.ftl" ]
[/#if]
[/#list]

One of my use cases was to generate a newsletter template for the web and a simpler one that would be supported by the mail clients.

RFP answer sharing

Antti Hietala — Thu, 25 Feb 2010 11:59:00 GMT

Responding to requests for proposal is hard work. An RFP is like a questionnaire. A prospective client looks for a solution to a particular problem and sends a request to several companies to find the best match.

The RFP document contains product requirements, problem scenarios, questions about your company's ability to deliver a system in time and on budget, and inquiries about support options.

At Magnolia we respond to quite a few RFPs. Writing comprehensive answers takes time and in-depth knowledge. The answers are out there but finding them at a moment's notice...well that's the hard part. Our partners who implement Magnolia Web content management around the globe face the same challenge. So we decided to give them a hand.

I collected answers from past RFPs into a single knowledge base. I edited them for reuse and shared them with our partners on Google Docs. Partners can access the knowledge base over the web and copy text directly into their responses. Full-text Google search helps find content quickly. I further grouped answers in a particular subject area such as "workflow" together. This speeds the writing effort further since questions are bundled together the same way.

To keep the content fresh and reliable, I go through it after each Magnolia release, write about new features, and weed out any phased-out content.

Want to become a Magnolia partner and grow with us?

Auto generate paragraphs

Teresa Miyar — Thu, 25 Feb 2010 09:02:00 GMT

By default Magnolia CMS STK comes with a mechanism to auto generate paragraphs in main and extras areas. This is very useful when you have the need of a paragraph to be present in all pages using some template. That paragraph could be modifiable or not and could be initialized with some default parameters or not.

If we have a look at the class SingletonParagraphTemplateModel, we can see that in the execute method has two method calls, one to generate a single paragraph in the main area (see stkSiteMap template) and the other one to generate any number of paragraphs in the extras area.

See below the template configuration for the main area auto generated sitemap paragraph

Nice thing is that you can extend this class or implement your own to generate any paragraph in any area of the page.

Below is the template configuration for the extras area auto generated paragraphs.

Magnolia Groovy module 1.0-m2 video

Federico Grilli — Tue, 23 Feb 2010 09:47:00 GMT

The Magnolia Groovy module 1.0 Milestone 2 has just been released. Briefly, what it does is adding first-class Groovy support into Magnolia's CMS at a deeper, system-wide level, allowing for managing Groovy classes and scripts directly within Magnolia's AdminCentral. The really innovative feature is the ability to plug in at runtime (almost) whatever piece of the CMS with a Groovy counterpart - no need for deployments and stopping/starting the servlet container. Of course, some common sense is highly recommended here and, though in theory possible, I would not endorse to rewrite and replace everything with Groovy, especially classes performing time-critical tasks. At least, not until Groovy will have become as fast as, if not faster than, Java ;-), which the guys working at Groovy++ seem trying to achieve. The video here will show this and other new features, such as easy hierarchy JCR navigation through nodes and attributes simply by using . (dot) notation (something similar to what Groovy does with XML with its XmlSlurper).

I18n authoring support on stage (Magnolia 4.3)

Philipp Bärfuss — Thu, 18 Feb 2010 10:21:00 GMT

Done! The i18n support for authoring is implemented and part of the Magnolia 4.3 milestone 2 release . Again I have created a video to quickly demonstrate how stuff works.

enabling i18n authoring
adapting a dialog
i18n & multi site support

I decided to add another interface configured at /server/i18n/authoring which is responsible to render the language chooser and which will adapt dialogs based on the i18n configuration. Hence it is possible to have your own implementations which could add extra tabs or duplicate the fields. If you are interested:

interface: I18nAuthoringSupport
default implementation: DefautlI18nAuthoringSupport

Oracle, Sun & Java

Boris Kraft — Tue, 16 Feb 2010 11:36:00 GMT

Magnolia CMS is running on the Java platform. According to Wikipedia:

Java refers to a number of proprietary computer software products and specifications from Sun Microsystems, a subsidiary of Oracle Corporation, that together provide a system for developing application software and deploying it in a cross-platform environment. Java is used in a wide variety of computing platforms from embedded devices and mobile phones on the low end, to enterprise servers and supercomputers on the high end. Java is used in mobile phones, Web servers and enterprise applications…

Now that the deal between Oracle and Sun is through, it is interesting to see what this deal could mean for Java, and in turn for Magnolia CMS. As stated above, Java is used anywhere, but most interesting for us it is used on enterprise servers and for enterprise applications. Now, if anybody on the planet can claim to be "enterprise", it's got to be Oracle. It is a safe bet that Oracle will be very interested to keep Java healthy, for various reasons:

many of Oracles enterprise applications are written in Java
many of Oracles customers run server software written in Java

In the last couple of years there was a lot of discussion about Open Source Java. Whatever the outcome there, as much as Oracle means enterprise, Oracle means proprietary. It is unlikely that Oracle turns into a major driver of Open-Source Java or Open-Source in general. That might be regrettable, but doesn't mean anything worse than Java has been under SUN, which until recently was not interested in Open-Source Java either.

Unlike SUN, Oracle makes heaps of money and can afford to drive Java further to increase its value chain and fend off the likes of Microsoft, who with their own proprietary .net platform are the only real alternative for the enterprise business Oracle is interested in.

What it means for anything Java that is non-enterprise is anyones guess, but that is of little concern for us, as Magnolia is running on a server.

So (enterprise) Java will be stronger with Oracle, and I for one am happy that a solid and strong company like Oracle is brewing our Java now.

i18n support in dialogs (Magnolia 4.3)

Philipp Bärfuss — Mon, 08 Feb 2010 18:00:00 GMT

Multi language support by maintaining a separate hierarchy per language has been supported since ever. In Magnolia 3.5 we added i18n support for multiple language sites allowing to have a single hierarchy. But we were still missing a nice built-in support for entering 18n data in the dialogs.

Till now the developer was forced to create a field per language (title_de, title_fr, ..). The positive thing about that was that one was able to place the fields as one pleased, by either putting them together in one place or having extra tabs per language. But the drawback of that was, that one had to add this fields per language and that once you wanted support more than 4 languages you had trouble to place the fields in a sensible way.

For instance it would be a nightmare to use STK in such a scenario as one had to adapt all the dialogs manually.

So we decided to improve that for 4.3. You will now mark a dialog field as i18n aware by adding an i18n nodedata to its definition. The dialog will then render the dialog accordingly based on the current language.

First we wanted to have the language chooser in the dialog but failed to find a solution which is nice and also not to complicated to implement (we will rewrite the UI for 5.0). So we came to the conclusion that selecting the language in the main bar of the page makes much more sense. The edit/new bar will then pass the current content language to the dialog. The dialog looks then 100% the same as in a single language scenario but is i18n aware in the way that it renames the field as marked to be i18n aware to the correct name: title_de, title_fr, …

Beside we will also support per site i18n configuration, so that one can work with quite complex scenarios.

Groovy.times{Magnolia}

Boris Kraft — Wed, 03 Feb 2010 13:57:00 GMT

Forbes has published an interesting article about CTO's favorite choices of programming languages. Its author Dan Woods argues that Groovy combines the best of Lisp, Ruby and Python, but in addition:

"From an operations perspective, Groovy is deployed like Java, so data center staff that can handle Java won't be surprised by Groovy."

Dan ends his article with the words

"… if you are starting from scratch on an advanced Web site, it will be hard to do better than Groovy"

Of course, we at Magnolia CMS could not agree more. Magnolia is written in Java and provides a fantastic framework to build web sites efficiently.

However, developing and deploying apps in an enterprise environment like the Java platform involves a certain effort. Typically, a developer uses an IDE (Integrated Development Environment) in which code is written, compiled, deployed to a test server and tested. This cycle is well defined and has massive benefits in the Enterprise world.

Now as Joe Walker rightly notes:

"There's a fairly obvious link between developer productivity and the edit/compile/test cycle. One of the big things wrong with Enterprise Java is that you swap the edit/compile/test cycle for an edit/compile/deploy/test cycle and one of the things right about PHP is that edit/compile/test is just edit/test."

When you quickly wish to try out something new, build a prototype or add a feature for a demo, a more agile framework would be considerably more fun for the developer, could save a lot of time and lead to a better result. More agile means that the edit-compile-deploy-test cycle needs to be simplified.

Enter full Groovy support in Magnolia. With the next release (4.3, out in March) we will introduce full-blown support for Groovy, which allows for a much more agile approach to implementing new functionality for your web site, while retaining the full power, scalability and security of the java-stack.

With Groovy you can add new functionality at runtime without a edit-compile-deploy-test cycle. The edit-compile-deploy-test cycle is reduced to edit-test like in PHP. This really cuts down on the time it needs to try out some stuff, build ad-hoc functionality or prototypes/demos. It will also be extremely helpful when building import scripts or run reports.

View Greg's video of what we have achieved with Groovy support in Magnolia so far.

Getting serious

Boris Kraft — Tue, 02 Feb 2010 16:13:00 GMT

Magnolia today announced the appointment of Andrew King as the new Head of Business Development for Magnolia Americas. Andrew is coming to us from competing Alfresco, and as such he brings with him excellent industry knowledge, and he gets Open Source. Combining his expertise with the outstanding product that Magnolia CMS really is leads to excellent motivation on all sides, and we look forward to make many more customers happy than we already did.

I am really excited about Magnolia making headway into the US. After all, I personally founded Magnolia Americas in summer 2007 and spend considerably time there laying the foundation of our success. With Andrew, we hired a "native" who understands the US market and has worked with European companies before. This will be of great benefit for our clients as well as our partner channel in the USA. Developing the latter is Andrew's first priority, in line with our corporate strategy of growing with our partners. Our non-compete partner strategy should be a strong incentive for potential partners in the USA, and we look forward to partner with some excellent companies in the USA.

Having Andrew on board is certainly a milestone for our US business. Expect more good news to come!

Configuration Inheritance (Magnolia 4.3)

Philipp Bärfuss — Tue, 02 Feb 2010 08:50:00 GMT

While developing the mutlisite support we realized once more how helpful it would be if one were able to inherit configurations instead of copying them. After some thoughts I came to the conclution that it might be rather simple to support this by implementing an other content wrapper which merges the content under the hood.

The wrapper checks the existence of a nodedata named 'extends' which can define a absolut or relative path to an other node.

You can see a demonstration in the following short video:

First I had to re-factor/improve the content API to make that wrapper extendable in a easier way. Then I have just created some tests and added the implementation. Once this was done I just searched the two places where I have to wrap the passed configuration before processing:

content2bean (used to build filters, modules, templates and various other components, ..)
dialog manager (responsible to transform a configuration into a dialog)

The merge is then performed as follows (taken from the javadoc):

node datas are merged and values are overwritten
sub content nodes are merged, the original order is guaranteed, new nodes are added at the end of the list

The mechanism supports multiple inheritances as such:

the node the current node inherits from can again extend a node
nodes laying deeper in the hierarchy can extend an other node

ModeShape - a unified content bus for Magnolia?

Boris Kraft — Wed, 27 Jan 2010 11:10:00 GMT

While Oracle is working on delivering everything you might ever need from a single vendor, the real world is a mess. Always has been, always will be. (Reminder: politics has to do with people, not technology).

The real world means that you have a lot of information hubs (call them silo's if they are proprietary and provide no open API to access their content). Content Management Systems like Magnolia CMS have provided a very open architecture to access these hubs, in part because Magnolia is running on the Java platform, which has been built for such integration, and in part because Magnolia's design is so open. However, each such integration still means the developer needs to understand the target API, a fact that quickly becomes expensive.

Wouldn't it be much nicer if the developer could just ignore the fact how and where data is coming from, and simply use JSR-170 to access it?

Enter ModeShape:

ModeShape (formerly "JBoss DNA") is a JCR implementation that provides access to content stored in many different kinds of systems. A ModeShape repository isn't yet another silo of isolated information, but rather it's a JCR view of the information you already have in your environment: files systems, databases, other repositories, services, applications, etc.

To your applications, ModeShape looks and behaves like a regular JCR repository. Using the standard JCR API, applications can search, navigate, version, and listen for changes in the content. But under the covers, ModeShape gets its content by federating multiple back-end systems (like databases, services, other repositories, etc.), allowing those systems to continue "owning" the information while ensuring the unified repository stays up-to-date and in sync.

So, if all goes well, ModeShape will provide a seamless extension of our existing content repository architecture. Instead of e.g. creating a new workspace and importing data from a third party system, you could just use ModeShape and add a connector to said system. If you are lucky, such a connector already exists. ModeShape is LGPL and as such I hope that it will gain wide adoption as a transparent wrapper for JackRabbit. Used in this way (provided the performance hit is small), nothing changes from the perspective of Magnolia (or the developer) but eventually, it will simplify content integration on the JSR-170 level, something that would definitely be a boost to the importance of the specification.

And with some luck, the world will be less messy even for those that don't shell out for Larry's vision of one provider for all things IT.

Happy Old Year, Happy New Year for Magnolia CMS

Boris Kraft — Thu, 31 Dec 2009 16:46:00 GMT

We are happy to say that 2009 has been the best year ever in Magnolia's corporate history. We are entering 2010 in a very strong position. We have a great team, a great product, great customers and our financial position is strong. Our license revenue has increased more than 60% for the third year in a row and has now reached about 75% of total revenue, clearly in line with our strategy to leave services to our partners and focus on product development, sales, marketing and education.

On the documentation front, the realization that documentation is as important as the product has resulted in significant more investment into documentation. While unfortunately, some of it has not yet left a visible trace, documentation has significantly improved in many areas. Most importantly, we have just added a full-time technical writer to our team and fully expect our vision for the documentation become a reality in 2010 (some pretty exciting ideas - stay tuned!)

In addition, 2 more new positions will be filled in January, making Magnolia bigger and stronger than ever. So expect great things form us in 2010 - and we expect great things from you! We have seen growing community activity, many cool modules have been developed and the Magnolia Conference was a personal highlight in my life. Thank you for your continued support!

So Happy New Year to all of you. We are looking forward to a fantastic 2010 together with you!

Magnolia Conference Keynote

Boris Kraft — Wed, 30 Sep 2009 19:41:00 GMT

Click to Play

STK Book

Philipp Bärfuss — Thu, 17 Sep 2009 09:25:00 GMT

Some weeks ago I have put down as much information in as little time as possible. The result can be found in the STK Book. It is for the moment the far best entry point for anybody trying to work with the STK. I also think that this pages contain some information valuable for those who are already familiar with the main concepts.

Dynamic Redirects

Boris Kraft — Tue, 11 Aug 2009 14:48:00 GMT

Have you been in the situation where you want to shorten URL's in your communication? For instance, it is time for a new Magnolia newsletter, the 8th one in our series. Our newsletters are located at http://www.magnolia-cms.com/home/news/newsletters/newsletter-8.html - not exactly brilliant from a communications perspective.

Magnolia allows you to add VirtualURIRedirects, and I have written about their usefulness before in the context of site restructuring.

For our newsletter, we typically add an entry in the configuration like this:

In other words, we add a static entry that forwards www.magnolia-cms.com/nl8 to our newsletter location deep within the site hierarchy, and makes it much easier to send out links or twitter about it.

So far so good, but today saw the 8th time I needed to add such an entry; and what is worse, I realized that we forgot the redirect for our 7th newsletter (which was sent out while I was on holidays, and the person doing the job did not know he had to add it).

Time to dig a little deeper into Magnolia, and avoid future work and worries!

Since sometime in Magnolia 3, you can use regular expressions in the VirtualURIMapping configuration. Here is what you need to do

copy an existing configuration
instead of the default class (aptly named "DefaultVirtualURIMapping") use the class RegexpVirtualURIMapping
define your match ("fromURI"), in our case "/nl([0-9]+)$" which means any URI starting with /nl followed by digits and nothing more (the $ means end of line). The parenthesis denote the dynamic part, which we need to determine the correct destination in the last step:
define your target ("toURI"), in our case the newsletter page deep within the hierarchy, with an added twist: we dynamically add our match to the page name, i.e. "newsletter-$1.html". In this case $1 means replace "$1" with whatever was matched in step 3 between the parenthesis. (And yes, you can have more than one set of parenthesis and reference the matches with $1, $2 etc).

The resulting entry should look as follows, and all you need to do now is activate your configuration and enjoy!

As you can imagine, this is also great for search-engine optimized landing pages.

STK 1.1, next level

Philipp Bärfuss — Thu, 02 Apr 2009 09:18:00 GMT

We improved STK based on projects and feedback given in workshops and I can say it is a major step forward. Doing that we added several new essential features and the concept planted in 1.0 are now building the fundamentals and are now applied more concisely.

Following some of the most prominent new features.
- fancy teasers / stages (caroussel, ..)
- new / events overview (calendar, ..)
- commenting
- categorization
- faq
- glossary

We will release in about 2 weeks a first beta or even a release candidate. For those who are most interested can download the milstone 4 version which we actually already use successfully in one of our projects.

2009 NBVP Future of Open Source results

Boris Kraft — Fri, 27 Mar 2009 08:55:00 GMT

The North Bridge Venture Partners 2009 Future of Open Source survey results have been published.

Fascinating for me is slide 13, which shows how the decision criteria for open source have changed from 2008 to 2009. Number one is lower TCO (unchanged). Access to code, which was #2 last year, has dropped to 5th rank in 2009. Now, "Superior Security" is ranked second, up from 7th place in 2008. Third rank is unchanged "Freedom from vendor lock-in" and new this year is 4th rank: "Better quality software".

So open source software is perceived as cheaper, better and more secure than proprietary alternatives. Sounds like a pretty good position to be in for any Open Source vendor.

2009 NBVP Future of Open Source results

View more presentations from bhouse.

The CMS Vendor meme - a.k.a. CMS vendor reality check

Boris Kraft — Tue, 17 Mar 2009 15:36:00 GMT

We have been challenged by Day to participate in the CMS Vendor Meme. To repeat:

The rules

A CMS vendor is challenged to honestly answer all items on the "Reality checklist for vendors" suggested by CMSWatch's Kas Thomas (aka the "we-get-it checklist for vendors").
If possible the vendor has supply screenshots, links or other means to make it easy to verify the answers.
The answers also need to be supplied in a short form of one to three stars (denoting "no", "sort-of", "yes").
Answering all questions on his blog allows the vendor tag some other WCMS vendors.
A tagged vendor should provide a link back to the blog that tagged him.

So here we go:
1. Our software comes with an installer program - Yes

Yes, download the EE trial and you can choose between various bundles meeting your needs, including an installer. All files are installed in a single folder, no additional software except Java is needed. To uninstall either use the uninstaller installed by the installer, or simply remove the folder.

2. Installing or uninstalling our software does not require a reboot of your machine - Yes

No restart required. Why are you asking?

3. You can choose your locale and language at install time, and never have to see English again after that - Yes

You can chose the installer language, but the default locale when you start up Magnolia is English. You can change that in the user preferences for each user separately, so if you have a globally distributed team speaking 15 different languages, no sweat.

4. Eval versions of the latest edition(s) of our software are always available for download from the company website - Yes

Not only eval versions, but even completely functional versions are available from Magnolia - a free trial of a complete Enterprise Edition or a completely free Open-Source Community Edition is available for immediate download.

5. Our WCM software comes with a fully templated "sample web site" and sample workflows, which work out-of-the-box - Yes

Oh yes. And not only is it a sample site, it is a a production-ready, search-engine-optimized, accessible site that works on any browser. CSS driven. XHTML. State of the art.

6. We ship a tutorial - Yes

We provide all documentation online, including a 300 page user manual. No registration required.

7. You can raise a support issue via a button, link, or menu command in our administrative interface - Yes

Yep, link to our issue-tracker is right in AdminCentral.

8. All help files and documentation for the product are laid down as part of the install - Sort of

All Magnolia documentation is online. Link is right in AdminCentral (see above). As a side-note, I don't think it is a great idea to deliver documentation directly with the product, because it bloats the download and is outdated before it is read.

9. We run our entire company website using the latest version of our own WCMproducts - Sort of

Nearly. Unlike Day, we did not have three years time to release our latest generation of software, and since we just released Magnolia 4.0 last week, I am afraid we did not have time to upgrade our site yet. We'll do it as soon as we have managed to call back all those prospects that inquire about us these days.

10. Our salespeople understand how our products work- Yes

Salespeople? That's a bit last century, no? But the people you talk to know how Magnolia works, because the people you talk to are the people who developed it.

11. Our software does what we say it does - Yes

Of course. We tend to say less and let the software speak for itself though.

12. We don't charge extra for our SDK - Yes

Of course not. We don't even charge for the software unless you want our supported Enterprise Edition.

13. Our licensing model is simple enough for a 5-year-old to understand - Yes

You can get one version for free. You get a better, supported version for 12k $ per server per year. Simple enough for a five year old.

14. We have one price sheet for all customers - Yes

Yes, and Magnolia prices are published on the web. We do give discounts to non-profits and educational clients, though.

15. Our top executives are on Skype, Twitter, or some similar channel, and: Feel free to contact them directly at any time - Yes

CEO Pascal Mangold: Twitter
CTO Boris Kraft: Twitter
... and we are always happy to talk to you on the phone or in person.

And we are tagging:

Jahia, Alfresco, OpenCMS, Hippo, EZ, Core Media, dotCMS

Do you ever buy bottled water?

Boris Kraft — Tue, 03 Mar 2009 09:16:00 GMT

Mark de Visser recently posted about Open Source pricing, asking "Is there a formula for what open source software should cost?".

I don't think there is - or should be - a formula for what Open Source software should cost compared to proprietary software. Foremost, there is rarely an exact proprietary equivalent to an Open-Source offering. Even if there was, the product itself is only part of what you buy. And even within the proprietary world, prices often vary widely for similar products. (Did you ever buy bottled water?)

But I agree that pricing should be straightforward and transparent in general. At Magnolia we originally tried per-user pricing but it quickly turned out to be too complicated, too many questions asked ("what exactly counts as a user"). We have had a per server pricing for the last 2.5 years and we have always published our prices on the web, easy to locate. This way, we minimize our effort, which is a big part of what Open-Source distribution is all about. We focus on the product, not on sales.

Now, this cost reduction can either be propagated to our clients through lower prices or through better software. I don't think the purchase price should be the first reason why you should look at Open Source. If you pay 1000 USD for a car that can only turn left, would you consider that a good deal? Thought so. So the real driver should be value, and the value proposition of Open Source is rather different from the value proposition of closed-source, proprietary software.

The real value of Open-Source is in the its openness, which for true Open-Source products goes far beyond source code availability. Some ideas:

If your IT team is working with an Open-Source product, they will have more interesting and more satisfying work to do and they will learn things that are actually useful for many years to come, as Open-Source products tend to be based on standards. The result is not only cost savings down the road (because your in-house-team can and wants to do more themselves), but also a generally better implementation because you have a motivated team close to the client. Finally, your IT staff turnover is reduced, which further improves your ROI.

So if you pay 20% or 120% for Open-Source compared to a proprietary product has little to do with the value you get. In fact, I would argue that Open-Source provides more value, which is exactly why Magnolia is Open-Source software.

Personalization in Magnolia for the Van Lanschot web site

Bananeman — Thu, 26 Feb 2009 12:50:00 GMT

(by guest author Edgar Vonk, software architect at Amsterdam-based full service internet agency Info.nl)

As described in the case study on the Magnolia web site Info.nl has recently created a new corporate and marketing web site for Van Lanschot Bankiers, the oldest independent bank in The Netherlands.

In this blog post we will shed some light on the technical realization of the personalization functionality that is part of this (Dutch) web site. The post will not cover details on the concept behind this functionality nor aspects concerning privacy.

The concept is based on Info.nl's model of Virtual Warmth where an online dialogue is sought with the potential client (prospect). The prospect can enter some details on his (or her) financial situation. The web site then displays topics (often concerning financial products) that are related to the prospect's situation. Also, any topics that are visited by the prospect during the active session are tracked and stored as part of the prospect's session. This way a 'personal file' is created on the fly:

Magnolia Enterprise

Info.nl has chosen Magnolia as its open source Java CMS of choice, which has resulted in Info.nl being a Magnolia implementation partner. In this case Magnolia Enterprise was chosen because of the extra features, guarantees and support that come with this edition. Info.nl deemed Magnolia Enterprise a good choice for the Van Lanschot case because of the openness of the product, the reliance on open standards, the extensibility (by means of custom modules) and the intuitive user interface.

Tracking visited topics

The visitor (prospect) is always anonymous. No personal data is stored by the system; hence there is no authentication mechanism. For each prospect a HTTP session is created in which the personal file is stored. Each time a topic is visited the ID (a JCR UUID) of this topic is stored in the personal file in 'last seen' order. Care is taken that topics are not stored twice. This online dialogue is implemented as a single-page-interface using AJAX technology. To realize this functionality a custom Magnolia Filter was written that was set to intercept all topic 'pages' using a virtual URI mapping. The screenshot below shows the filter in the Magnolia filter chain:

In our JSP templates the personal file data is then read from the HTTP session in order to show the list of topics visited by the prospect.

Storage and retrieval of the personal file

The prospect can also choose to save his personal file for later use. The prospect then receives an e-mail with a unique (machine-generated) link back to the stored personal file. The persistent storage of the file is implemented in a Magnolia Page (the Controller in the MVC pattern):

Using a virtual URI mapping this Page is activated upon a storage request. The visited topics are stored in the form of a comma separated list of unique IDs (taken from the current HTTP session of the prospect).

Retrieval of the personal file is done using the unique link that was sent in the e-mail. The associated page retrieves the corresponding personal file from the database and places this data in the current HTTP session. The web site then shows an overview page where the visitor can quickly navigate to any topics that were visited in his previous session.

During this process no sensitive data is stored that could be traced back to the visitor. The stored personal file does not contain any details about the visitor; the e-mail address and name of the prospect are not stored outside of the session.

User generated data and Magnolia

The hosting infrastructure consists of one Magnolia authoring and two Magnolia public instances. We thought about storing the personal files in the JCR repository (Jackrabbit) but decided on a simple custom database in the end. The reason why we chose this option is that using the JCR it would have been tricky to make sure that this 'user generated content' would be available to both public instances as well as to the authoring instance. A separate database that is shared by all three instances was easy to implement. I would be interested to hear from readers if they feel that JCR storage could have been a good option too, using Jackrabbit clustering as a way to synchronize this data across the Magnolia instances.

Result

Magnolia has turned out to be a good CMS for the realization of the new Van Lanschot Bankiers web site. Extending the product with custom functionality part of which was described in this blog post turned out to be relatively easy. This is due to the low learning curve of Magnolia, the openness and extensibility of the product and the reliance on open standards. And thanks to the intuitive interface of Magnolia the content editors of Van Lanschot have no problem in maintaining this dynamic web site.

STK: HTML and CSS structure

Philipp Bärfuss — Tue, 17 Feb 2009 15:01:00 GMT

I have copied a page which describes the HTML and CSS concepts behind the STK.

This is mainly important for designers working on new themes.

The base: content 2 bean

Philipp Bärfuss — Tue, 17 Feb 2009 08:37:00 GMT

Wolf asked me to elaborate a bit on all the billions of options you can configure in the template definitions (and site configuration). Before I start to do so I would like to point all to a new documentation page we have added to the documentation about generic configuration mechanism.

The essential chapter is the one about content 2 bean which describes how the configuration is transformed to java beans. The key point is, that if you want to know what you can configure you have to look at the java bean's code (resp. javadoc). This is also the mechanism which is used to setup up the module bean based on the configuration under /modules/mymodule/config

As a next step I will start to list most important properties of a STK template.

Release Notes

Philipp Bärfuss — Thu, 12 Feb 2009 08:31:00 GMT

Gregory finally published the release notes which contains all relevant information about changes (see also the sub pages summarizing API changes & cleanup ).

As a template developer you should especially read the new templating features page.

What is a Theme

Philipp Bärfuss — Tue, 10 Feb 2009 13:16:00 GMT

Philippe asked me to explain what a theme is. So I did on a new theme page.

STK: Themes

Philipp Bärfuss — Tue, 10 Feb 2009 09:57:00 GMT

In STK 1.0 we started to support themes. By default we deliver the theme-pop. I added a quick note about how to create a custom theme.

In the later run this definitely deserves an extra page.

FreeMarker: STK's template language

Philipp Bärfuss — Tue, 10 Feb 2009 09:45:00 GMT

There were controversy debates about the fact that we use FreeMarker as the main template language in STK.

So I have put some answers I have given on the user list to the main STK documentation page and wrote a Magnolia oriented FreeMarker primer.

Introduction to Standard Templating Kit

Philipp Bärfuss — Tue, 10 Feb 2009 08:32:00 GMT

Many days passed into the land since I have posted the last time. But now I think it is time to become a bit noisier ;-) I will try to assemble useful information about magnolia 4.0 and the new STK (Standard Templating Kit)

Doing so I will keep the interested audience informed on this blog. So don't hesitate to depose questions here.

One of the first things I plan to do is to make a kind of kick off screen cast.

So lets go!

Magnolia 4.0: Supersonic Templating

Boris Kraft — Thu, 11 Dec 2008 16:37:00 GMT

I am happy to tell you that we just hit our 5th anniversary, and times at Magnolia are truly exciting. We have had a phenomenal year 2008, and we have every reason to believe that 2009 will be even more successful for us – not despite, but because of the economic downturn.

Right now, everyone is trying to cut costs, and Open-Source has an excellent value proposition. Magnolia has reached a level of maturity that is probably well beyond many of our future client's existing infrastructure. Magnolia's list of clients is extensive and leaves no doubt that Magnolia can be used in many different and demanding settings. Any way you look at it, Magnolia could not be in a better position. I have written about many factors coming together in favor of Open-Source business in general and Magnolia in particular in my blog entry titled "The Perfect Storm".

So at Magnolia, we are happy, but not complacent. We like what we do, and we work hard to improve Magnolia. Our recent work has been on two fronts - the first one is Magnolia On Air, which we have launched to great acclaim at Gilbane last week. We will talk about Magnolia On Air at length in the coming weeks.

The other front is Magnolia 4.0, in which we introduce what I like to call "Supersonic Templating" – because you can create custom, feature-rich, and pixel-perfect websites faster than you can fly from Paris to New York.

A short intermission about templates in Magnolia

Templates are used to generate output from Magnolia-managed content. Magnolia allows you to tie together an interface to manage data with a publication mechanism. A template provides the smarts to publish anything. Typically, publication is to the web as HTML, but templates can also be used to publish to other channels and other formats – PDF or RSS are two other common formats that come to mind in the context of web content management.

So while templates typically define the look & feel of a web-site, they also provide functionality. For instance, a template can be used to pull data from a third system (e.g. the "content" stored in Magnolia could be the connection and query information to an external database. The template would then use that information to query the database and render the output).

As you can see, templating is quite fundamental to Magnolia. Hence, it only makes sense to further improve the way you define templates and to provide examples of what can be done with Magnolia.

~~~~~~~~~~~~~

So what is Supersonic Templating?

First and foremost we have added fully-fledged Freemarker support to write templates. Freemarker is a templating language that provides many benefits over JSP (which we'll always and fully support). For instance, it has no dependency on the servlet API. This allows as to do many things we could not (or not easily) do with JSP's. For a start, Freemarker allows us to store templates in the repository. This handily allows us to put templates under version and access control, activate them and use workflow on templates.

The fact that Freemarker doesn't depend on Java means that you can write templates without knowing any Java at all. Freemarker simplifies the templates considerably. Jan has shown a typical example where the new Freemarker template is one-third of the size of our previous JSP template. It makes it easy to distinguish HTML markup from Freemarker code. The new Freemarker support will make it extremely easy for newcomers to get started with Magnolia and allow veterans to reduce their maintenance effort significantly.

There are many other benefits templating in Freemarker brings to Magnolia, which is why we believe it will be the templating language of choice for many new Magnolia sites.

Introducing the Standard Templating Kit

In addition, Magnolia 4.0 introduces a "Standard Templating Kit" (STK). Unlike our previously shipped "Sample Module", this is a complete, out-of-the-box website that can and should be used in production. It provides "templating best practice" and an extensive set of ready-made functionality that can easily be extended without changing the STK templates themselves. This is achieved through a new concept of configurable templates.

The STK renders accessible and 100% CSS-driven HTML. The STK templates and other resources (CSS, JavaScript) are stored in the repository. To allow access to these resources for Magnolia newcomers, we have added a module called "In-Place templating" which makes the Freemarker templates available through a simple web interface. This allows anybody to quickly see how things are done and perform simple changes on the templates themselves right in the browser.

Even better, we are working on providing WebDAV access to the template repository (probably in 4.1), which allows you to simply map a drive to the Magnolia template repository and use standard client html editors to edit the templates and the css. In other words, it gets very very sweet.

We are fully aware that in complex integration environments, templates will be part of a custom module, under SVN version control, built using maven or other build tools and deployed using the Magnolia packager module. But I believe that these new, easy-access templating mechanisms will bring many new users to the Magnolia platform and increase Magnolia's visibility in the CMS space.

New form module

Magnolia 4.0 also provides a new form module that adds new form fields, validation and form processors (e.g. to store the form data in a database). Form fields now have assignable keys that can be used to retrieve values, for instance to send customized confirmation mails using the new Mail module.

New mail module

The new Mail module allows you to send any Magnolia page as inline-HTML and to use Freemarker in mail templates. This makes it very easy to provide news-letter-style functionality.

Other goodies

Along the way we have added other goodies – we make various objects available to templating in JSP and Freemarker. This includes the current content, a model, paragraph and template definition object. Configurable paragraphs allow you to hide complexity that you previously added to user-facing content-editing dialogs. In other words, Magnolia will be even more user friendly because anything that doen't have to be in a user-dialog can be put somewhere else.

Sites

We also introduce the explicit notion of a "Site". You can configure multiple sites and assign a configuration to a content tree. Not only does this significantly improve support for multi-site installations, it also makes it simple to switch the layout of a site with the click of a button.

Final words

As you can see, Magnolia 4.0 will have a lot to offer. Most of the above features have already been implemented in the first preview version, available for download here.

Standard preview disclaimer: the preview is buggy and things *will* change or might not make it into the final product at all.

Before we release 4.0 at the end of January 2009, we will add more templates and define the final packaging. Later in 2009 we plan to provide more support for Web 2.0 / community functionality, add the WebDAV support mentioned above and start implementing GenUIne, the new Magnolia 5.0 architecture. As you can see, we will be busy.

Magnolia On Air reactions

Boris Kraft — Tue, 09 Dec 2008 15:12:00 GMT

We have launched Magnolia On Air, our new broadcast content management system, at Gilbane last week. The reaction has been extremely positive. We were mentioned at Gilbane during a presentation by Forrester as a showcase for Open Source systems that provide Digital Asset Management. I have given various interviews, which was a great experience. We have had some serious interest from TV stations and a very large international non-profit organization.

One of the interviews was with Eileen Mullan of EContent, who has published her article about Magnolia On Air.

CMSWire has written a great article: "the real television (even with the benefits of OnDemand and TiVo) is struggling to keep its little antennae above water. But Magnolia On Air, the new Broadcast Content Management system from Magnolia, may be just what it needs to stay afloat".

Magnolia On Air is a collaboration between Magnolia and Futurelab, who brings extensive technological and vertical business knowhow to the solution. Right now we have finalized the first project for RTSI, the Swiss Italian Radio & TV Channel, who will replace their existing site with OnAir in spring. This means we have a fully working system, many components of which are tried and proven. The value of OnAir is in the combination and integration of the components and the marketing focus on the broadcasting industry.

I am sure we will be able to publish more details once RTSI goes live with OnAir, but it is already clear that the new power Magnolia On Air provides for the multi-media division of a broadcaster will speed up time to publish massively and reduce costs to do so significantly.

This is the first collaboration that results in significant value-add to our open-source platform Magnolia. We have received interest for many more such collaborations and it is well possible that this will be a major business driver in the coming years.

The perfect storm

Boris Kraft — Fri, 21 Nov 2008 18:57:00 GMT

Magnolia has been available as a java-based, free, simple-to-use Open-Source Content Management System for five years this month. We are in an amazing position right now - Magnolia is a great brand, a great and stable product, we have built a great team, we have an amazing client list, we are seriously cash-flow positive while most of our competition is either burning venture or making losses and we have two amazing products in the pipeline. We are in a position of strength in a massively overcrowded marketplace that will see many competitors vanish in the very near future.

And while the markets tumble and companies struggle to stay alive, there is a very real possibility that Magnolia will fit the bill for those companies that need to update their web infrastructure. Not only is it cheaper (or free if you choose the GPL'd variant), it is also following a completely different philosophy: Magnolia's focus from the beginning was ease-of-use.

Let's face it, the demands of knowledge workers have changed dramatically. IBM still tries to use a database driven web model as the basis for their web site deployments (and in doing so, cripples Magnolia in its projects to a text editor). How much longer will they get away with this in a world where anyone can sign up for free to create blogs like this one, or complete websites without involving a battalion of consultants?

Some wake up to this new reality. Today, if I read press announcements of our competitors, they read what we announced 5 years ago. "Easy for administrators, developers and users". "Joy-of-use". "Simplicity". Yes, but a press release is no substitute for the real thing, which is why these companies directly drive their clients and prospects to us.

Yes, requirements in a multinational corporation can be massively complex, but that doesn't mean you need to torture users with your outdated content management processes or unusable user interfaces. It means you have to take usability serious.

In today's climate, many of our competitors will be unable to sustain their outdated business model which is based on promises and good relations. The number of competitor's senior sales representatives applying for a job at Magnolia has reached a level of one per week. But guess what: our clients don't need senior sales representatives. They visit our website, download Magnolia, talk to our evaluation team to understand how they can make Magnolia fit their needs and if they are satisfied with the result, they become our clients with a simple email or fax message stating the number of licenses they wish to obtain. Did you see the need for a sales guy in this process? Neither did I. So "no sales" is the motto of the day.

Since Magnolia has minimized the cost of sales, it can invest more in development (hence our ability to innovate through tough times) and it can invest more in marketing. The next step our closed-source competition will do is cut down on marketing expenses. This directly enables us to reach a higher visibility with less marketing effort.

So the closed-source competition is loosing money, losing senior sales guys, (have to) maintain an old code base to somehow keep their clients happy (and increasingly fail to do so), and has to minimize their cost of operations (you don't believe that any of these companies will invest into anything in these times) to stop losses. Thus, they go down the death spiral ever faster.

Having dismissed Open-Source as an unmaintainable business model, they failed to seize the opportunity of building more with less. Now they lay off excellent developers (*). Thanks again.

For us, this is the perfect storm.

Magnolia 3.6

Philipp Bärfuss — Wed, 14 May 2008 17:09:00 GMT

Some of you might wonder what we are currently working on for the upcoming Magnolia 3.6 release. There are four enhancements which I will highlight in this blog entry:
- Performance
- Caching (API & Strategies)
- Backup / Migration
- Transactional Activation

In essence, Magnolia 3.6 will ease maintenance, boost performance and strengthen the robustness or our content management system in production environments.

Performance:
When talking about performance improvements, I mean significant improvements which are mainly beneficial for authors who create and manage content within Magnolia. Magnolia 3.6 will be up to 10 times faster for example when creating paragraphs, activating content, managing revisions, importing content, and more.

These improvements are mainly possible because we reduced the usage of mix:versionable (MAGNOLIA-2086).Additionally, we were also able to solve the memory related issues (MAGNOLIA-1998, MAGNOLIA-2099) and have already back ported the solution to Magnolia 3.5.

Caching:
We already finished development of a new and better API from scratch for Magnolia 3.6 which allows granular custom flushing and caching strategies. The new cache system allows to implement individual cache solutions which optimally meet the load patterns of a website to ensure high availability of every single content element. The default implementation is built on top of ehcache. The enterprise edition of Magnolia 3.6 will include pre-defined caching solutions that will substantially increase the number of requests served by Magnolia when hitting a cached page, the mechanism being that pages will be cached in the background before the existing cache for visited pages is being flushed. The solution also ensures that only one request truggers the caching process if multiple requests ask for the same not yet cached content.

Backup:
We wrote a backup facility which allows to restore revisions of content as well. This was not possible before, because only the latest version of a page has been imported in releases prior to Magnolia 3.6. Under the hood, the new backup happens in a persistence independent manner, which was not possible with jcr imports before. The new backup feature will be a nice tool for migrations from one persistence to another. This would be needed if you change the database or wish to profit from the new bundled persistence provided by jackrabbit 1.4).

Transactional Activation:
In former Magnolia versions there was no mechanism guaranteeing that newly created or updated content is being propagated to all public instances (so called “subscribers”) in a staging environment. In Magnolia 3.6, such content gets ether published to all public instances or not at all due to the new transactional activation functionality.
The content will be sent to each public instance at the same time so that the single publishing request does not get cumulated any more as in previous Magnolia releases. The transactional activation feature of Magnolia 3.6 makes sure that changes are only committed and published effectively once the content reached all subscriber instances successfully.

I am eager to explore this version in production :-)

If you would like to read more about the technical details of the upcoming Magnolia 3.6 release, visit the Magnolia Development Wiki. This is the place where we have today started to make our internal concepts, roadmaps and backlog available publicly. Please note the comment functionality at the bottom of each Wiki page – you are invited to add information or leave a question there.

Just in case you don't have an account for our Wiki yet, feel free to register.

Memory Fix, Backport to 3.5

Philipp Bärfuss — Fri, 09 May 2008 11:44:00 GMT

OK a backport to 3.5 was possible and the tests were successful. We will release a 3.5.5 containing this changes.

Further improvements, like having a mbean to reinitialize the system sessions, will be done for 3.6. I will now compare the two strategies to make a final decision what we make the default:
a) JCRSessionPerThreadSystemContext (would be saver as the sessions are not shared)
b) SingleJCRSessionSystemContext (used in current tests)

The main issue with a) was that the observation stops when you close a session so I had to add a hack to check for active observations and prevent closing in that case. But I would still prefer a) as each thread has its own session (thread save, sessions are alway up to date)