Page tree
Skip to end of metadata
Go to start of metadata

Deprecated with STK

Standard Templating Kit (STK) deprecation (September 15, 2017)

Standard Templating Kit (STK) was deprecated on September 15, 2017 and will reach end of life on December 31, 2018.

The replacement for STK is Magnolia Templating Kit (MTK), first released with Magnolia 5.4 on July 3, 2015. MTK is quicker to learn than STK and requires fewer skills. MTK is aimed at the increasing number of front-end developers who looked for something leaner and less time-consuming. MTE is front-end framework agnostic, which means you can integrate it with any modern framework such as Bootstrap or Foundation.

STK timeline:

  • 2009: First release
  • 2015: Maintenance mode
  • 2017: Deprecation
  • 2018: End of life

With the the release of Magnolia 5.6 we have stopped producing preconfigured bundles and webapps with the STK based demo. If your still rely on STK, you can use it. However, you have to build a bundle or webapp with STK yourself.

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 119 rates

Image Variations Rules

Paragraph specific image variations

To write a rule for an image inside a paragraph, you can define a divClass property inside the parameters node of the paragraph definition. The matching of multiple classes is supported.


The imageClass property inside the parameters node is also used for matching. If you have your own class extending ImageModel.java you can overwrite the method getImageClass() and return a class depending on any criteria. The string returned here is also used for matching.

Template specific image variations

To write a rule for one specific template, you can define a divID property inside the template definition. The matching obviously only works with one string as value.

The bodyClass property

Setting a bodyClass property inside the template definition overwrites the default magnolia generated bodyClass string which is really helpful for image variation rules. So think twice before setting this property.

The automatic generation of the bodyClass happens in the BodyClassResolver and works like this:

  1. if the vertical navigation is enabled return -nav
  2. append -col
  3. if floating is enabled append {-float<numberOfColumns>}}
  4. for every extrasArea append -subcol
  5. if small inside the extras area is set to false append -equal
  6. delete the leading "-"
  7. if the final result equals nav-col-subcol (standard layout with a navi and an extrasArea) return "" (empty string)

Following the above rules there are only a few classes possible:

  • col - Page without navigation and without extras
  • nav-col - Page with navigation and without extras
  • col-subcol - Page without navigation and with extras (small)
  • col-subcol-equal - Page without navigation and with extras
  • col-float3 - Page without navigation and without extras (float)
  • col-float2 - Page without navigation and without extras (float)
  • nav-col-float2 - Page with navigation and without extras (float)
  • col-float2-subcol - Page without navigation and with extras (float)
  • col-subcol-subcol - Page without navigation and with 2 extras columns

The default layout nav-col-subcol, a page with a navigation and with an extras area has no special class.

Area specific image variations

To match for specific areas use #main, #extras1, #extras2, #platform, #promos, #stage, #footer, #base (name of the jcr content node)

Involved Classes

  • info.magnolia.module.templatingkit.style.CssSelectorBuilder
  • info.magnolia.module.templatingkit.style.BodyClassResolver