Page tree
Skip to end of metadata
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 87 rates


The mindmap as created during the workshop:


  • green might go into STK 1.5
  • red might go into STK 2.0


All exploded:

Download XMind file


We will improve the framework

  • separate framework templates/paragraphs and the base framework should get separated, the set of base templates should be smaller, extras as Glossary, FAQ, ... will go into an extra module
  • less paragraphs combine paragraphs like the various teaser groups into a single one. Magnolia 5.0 will support such dialogs in a better way, alternatively we could introduce tabs in the paragraph selection dialog

The STK is on a good path, but few things are too complex and should get improved.

  • imaging
    • the CSS selector based system is not transparent enough, we prefer a less flexible solution
  • resources
    • use same pattern as for template scripts: list of loaders (webapp, workspace, jar)
    • support binaries
    • far future caching
    • align with files in mgnl-resources
  • themes
    • better deploy process (zip upload)
    • configurable themes (few parameters, like color and font)
    • simpler base CSS (separate functional and style)

The focus is more on simplifying things rather than adding new features, still there are some we should mention here:

  • ajax provide a best practice example using the new direct-paragraph-request feature
  • social media integration to youtube, twitter, facebook, flickr
  • templates redirect, structure, iframe, ...

And beyond: we collected ideas which will be realized while developing 5.0, some of them are well known but requested so often that I still mention them here:

  • developer mode show developer related information: script executed, direct link to script
    • dialog to edit paragraph definitions (show script, direct editing)
  • usability
    • show template, paragraph name in the bars or info-box
    • direct upload to DMS (and preview) and support for search in the selection dialog
    • execute actions as activation directly in the page view
    • create page -> select template -> open dialog -> save creates page
    • visualization in paragraph selection list


The STK 2.0 kickoff workshop will be comprised of a small team of mainly developers that are experienced with STK and wish to improve it. The Goal of the workshop is to gather specific feedback, decide on features for STK 2.0 and define a roadmap as well as responsibilities for the further development (i.e. who does what). 

There is no obligation for the participants to work on the actual implementation, but the likelihood that a feature will be implemented will much increase if the person who wants it also provides it.

Agenda of the Workshop


Date, Time, Location

Monday June 14 & Tuesday June 15th
St. Johanns Vorstadt 38 (new office)
9 AM - 5 PM


We'll have a joint dinner Monday night unless we can't stand each other, in which case we will simply sit at separate tables (wink)


Rainer Blumenthal <>

Rainer Blumenthal is a Technical Project Manager at Aperto AG. At Aperto he has been realizing Magnolia projects since 2007. His responsibilites include the technical coordination and conception of IT-projects for clients like Volkswagen, EADS, Frankfurt School, degewo or INSM.

Rebecca Heinen <>

Rebecca Heinen is a Frontend-Developer at Aperto AG since October 2007. Her responsibilites include conception, construction and quality assurance of html-prototypes in use with css and javascript. Her special capabilities are in the fields: web standards, accessibility, usability, SEO and mobile web.
Rebecca Heinen graduated an apprenticeship for media design (balance point design, non-print) with Vipex GmbH in Cologne. Furthermore she finished a study for multimedia producing at SAE College in Cologne.

Ernst Bunders <>

My name is Ernst Bunders. I have been a Java web developer for about 8 years now. I am at the VPRO for nearly three years. During that time I worked a lot with a dutch object-oriented content management system called MMBase. In many projects I participated in I did the technical design.
I started playing around with magnolia for about half a year now, Investigating and customizing Magnolia and the stk on all levels.
Apart from creating many custom paragraph- and template model classes, I developed dam integration for the simple media module (which has been accepted as a patch). Currently I am discovering the inner workings of magnolia caching and preparing some optimizations to the standard caching configuration.

Nils Breunese <>

My name is Nils Breunese, I will be 29 years old tomorrow and I have been with VPRO since November 2008. Like all of my colleagues at VPRO we have started using Magnolia last year. Magnolia-wise I have been primarily working on building custom paragraphs and model classes and integrating with our own backend systems (mainly CouchDB at the moment).

More details about me can be found on my LinkedIn profile:

Mail from Gerbrand / VPRO

Initially we thought we would use the STK to get us started and would write our own 'VPRO Templating Kit' later on. Knowing a bit more we think we can keep using STK, especially as we can help make it better. We are currently discovering how to override the template classes so we can be more flexible about areas etc (this was the main worry for a time). This seems to go well and makes the use of STK for future projects much more viable.

Boris Kraft (Magnolia)

CTO and product owner. Started this initiative together with Aperto and ensured that STK also works marketing wise.

Philipp Bärfuss (Magnolia)

Head of Product Development. Working for Magnolia for about 5-6 years and worked out the main backend concepts of STK 1.0 and guided its development. He would like to streamline and simplify STK.

Christian Ringele (Magnolia)

Software Developer. Implemented the bigger part of the STK based on the static prototype delivered by Aperto.

Grégory Joseph (Magnolia)

Magnolia Developer for about 4 years and our future community manager. He will help to setup the future collaboration and is the author of the imaging module. Among other things he would like to improve the integration of the imaging module and the form processing.

Markus Erdmann (esense)

Frontend developer at esense and used STK to develop custom websites. He will provide feedback and ideas about possible improvements.

Media Catalyst

  • are not participating due to heavy project pressure
  • No labels


  1. Philipp, is there some sort of backlog somewhere for this? If not, I just wanted to drop this link: I'm sure people like Timo know these kind of CSS "frameworks" by now, and I wondered if we could make use of it; thus consequently benefit from existing stylesheets easily, instead of having our own set of elements ?

    I'm obviously interesting in the Imaging integration discussion; for this to be relevant/efficient, I hope I can find a day or two to prepare/investigate (as I think this will have a wider impact than it seems - i.e the DAM integration will probably be touched as well). While we're at it, we might consider how much of the imaging module will still be relevant, and where it should go, in the coming months/years: html5/css3 provide support for custom fonts, the canvas object does great things, and browsers have significantly improved the quality of their own resizing.

    1. No backlog, but adding this information here is a good starting point. Some quick answers: will raise the topic but for me it seams to go 180 in the other direction than what we are doing today. Our divs are driven by the semantic: intor, branding, main, section, teaser, .. (HTML 5 is very similar to that). But 960's approach is very much driven by the layout. Not sure if this can be mixed.

        • we might want to facilitate defining custom areas, as this is something most want to see

      imaging yes, as a first step I will write down how it works today and why. both the imaging and the integration must be overworked. but that won't be so easy.

      drop resizing less relevant, but you want to save the bandwidth too

      1. resizing and cropping is the most still relevant feature of the module, i was thinking of all the other possibilities it offers.

      2. Some thoughts...

        We have integrated 960gs in 3.6 and according what I see it is quite useful way of layouting.. it's true that 'semantic' way of thinking is a good approach but beeing compliant to some of the layouts engine speeds up template dev. (GSgrid or Yui grids ... or even jQuery Layout). L & F of mgnl divs should stay as is cos grid should be used for positioning mainly the columns renderer (master layout)... but with the freedom of applying it to any paragraph...

        Using GSgrid enables seamless small screen rendering around all layout elements plus it gives you pure css layout mashup. Changes to the philosophy used in magnolia is minimal (one select box choosing normal or cleared boxes in paragraph props)... like the most things we want to enhance magnolia with... (wink)

  2. VPRO has provided valuable feedback, see attachment

  3. Added the mindmap as produced in the workshop and gave a short summery.