Magnolia 5 Alpha 3 is out

With Magnolia Amplify still in full swing (here are Boris’ keynote and Philipp’s in-depth look at Magnolia 5), we’re releasing the latest milestone of our Magnolia 5.0 development effort today: our repository server now carries the Alpha 3-1 release.

Here’s an overview of what has changed and what’s new in this release.


We’ve invested heavily to stabilize and solidify our internal APIs to ensure we offer a robust foundation for you to build your apps upon. We’ve reorganized and restructured the modules to more cleanly separate them. The diagram below shows what we’re aiming at and what we’ve mostly reached with this milestone.

Here’s a short video with some more details on these many changes the API team has been working on.

More digital asset management

Our new Digital Asset Management (DAM) has seen significant improvements in several key areas. We now have the beginnings of support for different metadata standards, with simple Dublin Core set to be delivered with 5.0. The integration with STK and the migration from the old DMS module to the new DAM have made big strides. We’ve also added a registry for asset providers, which will make the seamless integration of assets managed by external systems possible (think Flickr, Dropbox or a full-fledged DAM system).

The most visual and an impressive addition to the DAM module is the new image editor, shown above, which offers basic image editing operations. You can now crop, rotate and flip images and convert them to grayscale. And all this already works on the iPad as well. See it live in action in the video below.

Provide you own skin

On the UI part, we’ve had one big focus on improved theming of apps. Extending, re-using and redefining existing CSS definitions just got a lot easier with the addition of an @AppTheme annotation for apps and full SASS support. The increased consistency of the look and feel of many UI elements has allowed us to refine our visual design – more changes will be coming in the next releases. And lastly, dialogs may now appear modally against a sub app, an app or the entire web app and are properly stacked one upon another, when opened sequentially.

Under the hood changes in work flows

Most of the changes of the work flow team remain invisible in this release. The new Workflow API is almost finished now. We’ve also upgraded our new workflow engine jBPM to version 5.4, which proved to be more difficult than anticipated, but which also brings us a lot of good stuff we’d like to take advantage of.

On the front end side, work on the message details pane has seen quite some improvements. This feature will allow you to react on a message right from within Pulse. A promising concept we’re currently researching uses standard form definitions for configuring the display of message details. This could make it easy for a developer to set up powerful message panes with just little effort.

Build your own app – now!

We’ll run an “app week” now to see how well our refined APIs perform in the wild. Join us and build your own app:

Be warned, though, that there will be bumps on the road, as this is all very much work-in-progress. Our documentation is not yet complete and not always accurate, but we will adjust it in the coming weeks, so keep an eye out for updates.

Forge an app – and let us know how it went!

3 thoughts on “Magnolia 5 Alpha 3 is out

  1. Hi
    I’m glad to see work done on image editing tooling. We recently did an audit among our (many) web editors, and a thing that comes up a lot is that it’s hard to get the images right. Default cropping and scaling may have unpredictable results, and the editor has little control.
    What I see in the video above is nice, but if I understand all well, it doesn’t really align with our use case.
    When editors add an image to a specific place in the page, a certain target size and aspect ratio is coupled to that specific place/area/paragraph. So the crop/resize interface should take that into account, and fix the aspect ratio of the resize rectangle. That way editors will have full control on what part of their image will be used in the page.
    For that reason the global approach to imag editing seems unpractical.
    The way I see it (without any deep thought) it we need a workflow like this:
    1 add an image to a paragraph (component).
    2 the somewhere the target width/height is stored, perhaps a jsp tag in the template could take care of that.
    3 When the image is added, default cropping/resizing is applied, but a button is provided with the image in the page.
    4 click the button and you can crop/resize the image. A fixed aspect ratio triangle is provided that can be scaled and moved. The image variation that is thous created is stored in the context if it’s application on that page. If a dam handler is used that provides central storage and reuse (dms/simplemedia), the original is stored there and different uses of the image in different pages can use different croppings.

    I hope this helps. I’m not sure how different this use case is from the tool you have created so far, but this is the use case that we will have to implement some how.



    • Hi Ernst,

      thanks for your input. I think we briefly discussed the need for basic image editing in Magnolia at last year’s conference here in Basel, didn’t we?

      I agree that a fixed crop ratio, defined in a template or component definition (or the template itself), would be a very needed feature for crop. We, too, have many cases where we don’t want editors to be entirely free in choosing the width and height of their images. I’ll feed this into our dev process.

      One thing I’d also love see is to offer editors a set of pre-configured image sizes to choose from. As a template developer, you would define e.g. a small, medium and large image size for an image of a certain component, and an author would then be allowed to choose among these. I could thus choose to start the article header with a “large” image and only little text ,or rather a “small” image and more lines to read. And here again, the crop tool in the image editor would adjust its crop rectangle to match the size chosen, as you suggest, so that choosing a properly sized image section for any type of component and its defined image sizes would be a snap.



  2. Pingback: Magnolia 5 Alpha 3 und Release Datum | my container.

Leave a Reply

Your email address will not be published. Required fields are marked *


− 1 = four

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>