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

This release introduces a completely new authoring interface, the Content Editor, with lots of white space and undisturbed flow of content. Use the content editor to write news articles, blog posts and press releases – anything that is a mix of structured form fields and free-flow composition. You can publish content directly from the editor which helps get new information out without delay.

Also in this release, developers will enjoy the new JavaScript template models and more ways to reuse configuration in light modules.

Changes for authors

New editor for easy content creation

Content Editor is a new editing interface that lets authors create content easily and publish it instantly. The new editor provides ample white space and an undisturbed flow of content. It is ideally suited for long-form content where you mix structured form fields and free-flowing composition such as news articles, blog posts, product pages and press releases.

The new Stories app provides a ready-to-use implementation of the content editor and is included in the Magnolia enterprise bundles. Customize the Stories app to suit your needs, or use it as a blueprint to create your own content editor app. The Magnolia travel demo provides sample content and pages to demonstrate the capabilities of the content editor.

Benefits:

  • Easy content creation. You don't need to be a CMS expert to compose and publish content. Now you can let any type of author create rich and reusable content. Authors don't need to become experts in the tool first. Authors can focus on what they love to do: write great stories and get them out immediately. You control what content blocks are available – authors have the freedom to arrange them into a compelling story. 
  • Publish before competitors. Consumers can get information from various sources today at incredible speeds. It is critical to get a breaking story out first. The first story that reaches the audience is the one that will be read. Being first in social feeds also means better acceleration and ultimately more traffic coming your way. The Stories app can bypass workflows to let authors publish content in seconds. Get the first draft out as soon as a story breaks. Keep publishing more detail and add depth as the story develops.
  • Reusability and flexibility at the same time. Content management systems often ask you to choose between editing content in rigid forms and very flexible pages. Forms give you reusability while page layout gives authors flexibility to control the experience. Magnolia's Stories app is right in the middle of those poles. Authors can input the right amount of metadata and structured content to make the content reusable, while at the same time have enough freedom to craft a rich end-user experience.

CONTEDIT-111

Reclaiming workflow tasks

If a user has the publisher role, they can now reclaim a publication task that was assigned to another user. This avoids one person becoming a bottleneck in the publication workflow.

For example, if a publisher assigns a task to himself and then goes on vacation, leaving the task incomplete, another user can claim the task for himself. The absentee publisher is informed of the change in the Pulse

MGNLUI-4232

Changes for developers

JavaScript template models

Magnolia speaks the language of front-end developers. Now you can supply a JavaScript template model in a light module. Develop and deploy faster without the need for Java, Maven or WAR deployment.

  • Front-end developers have access to rich Magnolia functionality that was previously only available in Java.
  • JS models are performant and fun to work with. Changes are picked up instantly, just like any other file in a light module.
  • You can simplify template scripts by moving complicated logic to template models.

See: How to work with JavaScript models

JSMODELS-1

Reusing configuration with YAML inherit and include

Your ability to reuse configuration has improved, boosting productivity for front-end development with Magnolia.

You can now reuse configuration easily with YAML !inherit and !include directives. Both inherited and included definitions can be modified and overridden. You can !include from YAML-based files and !inherit from registered definitions (such as YAML or JCR definitions).

Benefits:

  • Easier to create new definitions.
  • Reduces duplication of configuration which improves maintenance.
  • Makes it clearer how your new definition is related to existing ones.

Use cases:

  • Want to create a new dialog that is almost the same as the MTK Text & Image component? Inherit it and specify what you want to change.
  • Want to create a new app that is almost the same as the Pages app? Inherit the Pages app.

!inherit

A new !inherit directive allows a YAML file to inherit any other registered definition from any source: Blossom, Java code, JCR or YAML. The result is a new definition that you can modify further. In this way, the new YAML !inherit directive is very similar to the JCR extends property.

Reference the inherited definition by its identifier.

Example: Define a new renderer json . Inherit everything from the freemarker renderer but specify a different contentType .

/your-module/renderers/json.yaml
!inherit:freemarker
contentType: application/json
See: YAML inherit

!include

The existing !include directive has been improved. Now you can override the included values. For example, a YAML file that defines an link field can be included in two different dialogs: one dialog definition modifies the required property to make the field required and another dialog that keeps the field optional.

Reference the included definition using its resource path. You can include a complete definition at the top of your new definition or a fragment at a sub-level.

Example: Define a new form. Include a tab and actions from other definitions. Modify a property.

/module-a/dialogs/components/lazy-component.yaml
form:
  label: lazy-component
  tabs:
    # an include within a list, here adding a complete tab
    - !include:/module-a/include/categorization-tab.yaml
      label: Yo! 1-tab-only!
      fields:
        # modify properties of the field blackOrWhite which comes from the include
        - name: blackOrWhite
          label: Choose color
# an include within a map, here adding the actions for the root (map) item "actions"
actions: !include:/module-a/include/common-actions.yaml
  # add another action to those which already exist from the include
  doit:
    label: Same as cancel
    class: info.magnolia.ui.admincentral.dialog.action.CancelDialogActionDefinition

  • Line 6: Modify the label of the included tab.
  • Lines 9 and 10: Modify the label of the blackOrWhite field from the include.
  • Lines 14 to 16: Add another action to the imported actions.

With Magnolia 5.5.6 the syntax has changed slightly. The old syntax still works. When using the new version, you can modify and override the included part of the definition, see syntax versions.

See: YAML include

MAGNOLIA-6664MAGNOLIA-7060

Inspecting an object's structure and content 

To get a better understanding of any object, you can use the new  cmsfn.dump  function in a template script to output an object's structure and content. By default the function looks down to the 3rd level of an object and produces the output in plain text, optionally in a simple HTML format.

Example:

${cmsfn.dump(content, 3, true)}
MAGNOLIA-7077

Improved virtual URI mappings

As a frontend developer, you can configure virtual URI mappings in a YAML definition file inside a light module folder.

Example:

/your-module/virtualUriMappings/enterprise-edition.yaml
class: info.magnolia.virtualuri.mapping.DefaultVirtualUriMapping
fromUri: /ee
toUri: forward:/enterprise-edition
The API has been improved. Some mapping classes are deprecated now. As replacement you can use 5 new mapping classes. The API is now in its own module info.magnolia.core:magnolia-virtual-uri in the main reactor.

MAGNOLIA-7016

As we made the new mappings safer to use, host-based URI mappings currently require their toUri property to be also configured (outside of the domain mappings); otherwise, they are ignored. Such fallback may not always be desired. We will amend this to make the fallback target URI optional again. See MAGNOLIA-7158 - Getting issue details... STATUS


Use placeholders to describe expected field values

Use the placeholder property to give the user a hint about what they should enter into text and link fields. For example, you can show the expected format for a phone number or give a hint about the importance of entering metadata for SEO purposes. A placeholder text can prevent input errors before they happen.

The placeholder property is available in text field and link field definitions. The property allows you to define a text (i18n compliant) to be displayed in a field before a user enters something. The earlier purpose-built PlaceholderTextFieldDefinition class is now deprecated.

/module-foo/dialogs/components/imgProperties.yaml
form:
  tabs:
    - name: tabMain
      fields:
        - name: imgCaption
          class: info.magnolia.ui.form.field.definition.TextFieldDefinition

        - name: imgLink
          class: info.magnolia.ui.form.field.definition.LinkFieldDefinition
          targetWorkspace: dam
          appName: assets

actions:
  commit:
    class: info.magnolia.ui.admincentral.dialog.action.SaveDialogActionDefinition
  cancel:
    class: info.magnolia.ui.admincentral.dialog.action.CancelDialogActionDefinition
/module-foo/i18n/module-foo-messages_en.properties
# Image Properties
module-foo.components.imgProperties.label=Image
module-foo.components.imgProperties.tabMain.label=Properties
module-foo.components.imgProperties.tabMain.imgCaption.label=Caption
module-foo.components.imgProperties.tabMain.imgCaption.placeholder=Enter the caption text for the image here ...
module-foo.components.imgProperties.tabMain.imgLink.label=Link
module-foo.components.imgProperties.tabMain.imgLink.placeholder=Provide a valid link to the image here ...

MGNLUI-4240CONTEDIT-131

Relocation and expansion of LDAP module's configuration

Released almost simultaneously with Magnolia 5.5.6, version 1.9 of the LDAP Connector module is now configured under the appropriate node in /server/security/userManagers. The configuration also allows a more convenient customization of its properties.

MGNLLDAP-86MGNLLDAP-110

Security and library updates

Others

5.5.6 changelog with all the changes.

 How to update from earlier versions

Updating to 5.5.x from any pre-5.5 version

  • (warning) Please be aware that depending on the number of versions in the version workspace, the update to 5.5.x from any version below 5.5 may take from 20 to 30 minutes since all of the versions have to migrate to a new structure.
  • Since the default JCR persistency layer in our bundles has changed to H2 Database Engine with the 5.5 release, please make sure that you keep the magnolia.repositories.jackrabbit.config property in the magnolia.properties file set to the database you used before updating. For example, for Derby set the property as follows:
    magnolia.repositories.jackrabbit.config=WEB-INF/config/repo-conf/jackrabbit-bundle-derby-search.xml

Generally, follow the standard update procedure.

Changes for 5.4.x users

The following changes apply only to the users running Magnolia 5.4 (major release) and maintenance releases 5.4.1 to 5.4.3.

magnolia.properties file

CE and EE users

Add the following lines in your magnolia.properties file. They configure a directory for loading file system resources and the file types Magnolia should observe in the classpath and reload on-change:

magnolia.resources.dir=${magnolia.home}
magnolia.resources.classpath.observation.pattern=.*\\.(ftl|yaml)$

If you had EE Pro 5.4.x or previous and are installing EE Pro 5.5.6

Due to component personalization bringing in new features to the page editor, you must replace the widgetset in the magnolia.properties file. Either replace or add (depending on the update path):

magnolia.ui.vaadin.widgetset=info.magnolia.widgetset.MagnoliaProWidgetSet

Derby vs. H2

If you used a previous version of Magnolia with an Apache Derby database, make sure you keep your magnolia.repositories.jackrabbit.config setting in your magnolia.properties file.

Magnolia bundles now ship with the following default setting:

magnolia.repositories.jackrabbit.config=WEB-INF/config/repo-conf/jackrabbit-bundle-h2-search.xml
This setting may not be compatible with your setup.

Important changes for Magnolia 5.2 and 5.3 users

If you had STK installed

If you continue to work with STK, use the new magnolia-enterprise-pro-stk-bundle as a basis for your project. It includes Enterprise Pro, STK and the old demo project. You get all STK functionality out of the box. Exclude the demo-project if it's in your way.

Jackrabbit configuration

In order to enable getting an HTML excerpt in a query result, you should update the configuration files of your Jackrabbit instances. Add the two <param/> directives within your <SearchIndex> block.

<SearchIndex>
  <!-- more params here -->

  <!-- needed to highlight the searched term -->
  <param name="supportHighlighting" value="true"/>
  <!-- custom provider for getting an HTML excerpt in a query result with rep:excerpt() -->
  <param name="excerptProviderClass" value="info.magnolia.jackrabbit.lucene.SearchHTMLExcerpt"/>
</SearchIndex>
log4j.xml addition

Add the log configuration for org.reflections

...
 <category name="org.apache.jackrabbit">
    <priority value="WARN" />
  </category>
 <!-- Reflections library spoils logs with hundreds of harmless warnings; tries to look into native libs but none of its DefaultUrlTypes can handle them. -->
  <category name="org.reflections">
    <priority value="ERROR" />
  </category>
  <category name="com">
    <priority value="WARN" />
  </category>
...

How to update from Magnolia 5.2 and earlier

To update your project, follow the standard update procedure, then make the following changes:

  1. Update your content apps with the content app upgrade task. It automatically takes care of the following:
    • Using the content connector.

    • Updating configuration of availability rules and default rule classes

    • Updating selected action definitions with node-type based availability

  2. If you used the DAM: 
    • Replace DamManager with AssetProviderRegistry.
    • See DAM and the STK and DAM templating on how to use assets in your templates.
    • The DAM changes have no impact on the STK. There is no need to modify Freemarker scripts because the new DAM API is abstracted from STK.
  3. If you have a custom jBPM workflow:
    • In the info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#completeWorkItem method, checking for present parameters is obsolete and refers to publication related workitems. The method is no longer used for completing a workitem in the new human task context. It is still valid in the context of completing service tasks, however.
    • Stop using the info.magnolia.module.workflow.jbpm.JbpmWorkflowManager#getWorkItem method. It was used to complete a work item for human tasks. Furthermore, the wrapper we initialize only holds the mgnlData map.

    • The previously hardcoded mgnlData parameter is now configurable in /modules/workflow/commands/workflow/activate/activate/parameterMapName.

  4. If you have custom widgets or Vaadin add-ons:
    • Magnolia's default widgetset was relocated to info.magnolia.widgetset.MagnoliaWidgetSet.
    • Update your webapps's magnolia.properties file.
    • Otherwise Magnolia will automatically fall back to the new widgetset but will issue warnings during upgrade, and whenever a user logs in to Magnolia.

How to update from Magnolia 4.5 and earlier

Are you running on Magnolia 4.5 or earlier? It’s time to move to 5. Contact us for migration support and look at the migration process.

 Known issues

Posting a comment does not work

Due to the removal of deprecated code, the Commenting module does not work. We will release a new version of it soon:  MGNLFORUM-296 - Getting issue details... STATUS .

The Show action in the Configuration app doesn't open the correct location

When selecting properties in a definition that are actually extended from another node in the config workspace, opening the definition in the Configuration app will not work correctly, as the underlying node/property doesn't exist. For example,

/.magnolia/admincentral#app:definitions-app:;app~site@subApps/browser/actions/addFolder/icon:treeview
points to config:/modules/site-app/apps/site/subApps/browser/actions/addFolder/icon
but all the actions are inherited from /modules/ui-admincentral/apps/configuration/subApps/browser via extends.

Allocate more JVM memory

Magnolia 5.5.6 ee-bundle may require you to allocate more memory the Java Virtual Machine (JVM). If you see a java.lang.OutOfMemoryError in the startup log or the system stops responding during installation, increase the Java heap size. The default maximum heap size is 512M. Try a higher amount such as 1024M. We are working on uncovering the root cause for the increased memory need.

See: Java out of memory

 Updated modules
  • Activation 5.5.5
  • Cache 5.5.6
  • Community Edition 5.5.6
  • Content Editor 1.0.6
  • DAM 2.2.6
  • Definitions app 1.0.2
  • Demo Projects 1.1.5
  • Enterprise Edition 5.5.6
  • Forum 3.6.2
  • Javascript Models 1.0
  • LDAP support 1.9
  • LDAP support 1.9.1
  • Magnolia 5.5.6
  • Pages 5.5.6
  • Personalization 1.4.6
  • Resources 2.5.4
  • Templating Essentials 1.1.4
  • UI 5.5.6
  • Workflow 5.6.5
  • XA Activation (exchange-transactional) 2.4

Acknowledgments

The Magnolia team would also like to thank everyone who reported issues, contributed patches, or simply commented on issues for this release. Your continued interest helps us make Magnolia better. Special thanks go to: Marcel Boer, Marcus Büttner, Andrea Castelli, Chris Jennings, Jens Kolb and Ronald Ten Berge.

  • No labels

13 Comments

  1. Congratulations! Looks like an awesome release once more.

  2. Great improvements! Like the virtual URI mappings as yaml definition.

    Why does the new !include:/path/to/file.yaml directive does not allow yml files anymore? The old (now deprecated) !include /path/to/file.yml directive did always allow .yml and .yaml. We are using includes to files with the extension .yml so that the include files are not registered in the dialog/template registries (because parsing the file fails as it only include a snippet of a full dialog). With this new way, we need to place the .yml files outside the /dialogs, /templates folders (IN e.g. /module/include/ and rename them to .yaml) so it's not picked up by the registry.

  3. Very nice improvements!!

    I agree with Jordie Diepeveen, that there should be some way to distinguish partials from real definitions (e.g. like the mentioned file .yml extension). There are many use cases, where partials make sense, but probably shouldn't be in the registry.

    1. Hi Jordie and Matthias, thanks for the comments - Jordie, as far as I know this was not an intentional change - but I will check with the developer. Possibly we can change the new include directive syntax to work with .yml files - on the other hand it would be nice to come up with a convention or feature that is more explicit then the file extension. 
      Both of you - yes we have also discussed internally the need for a way to distinguish between files that create definitions and files that just contain snippets. So lets figure out a good approach, possibly based on something in the filename - like '.yml', or folder, and we'll ensure that our changes work with it.

      I just created a "suggestion box" ticket for the topic. Please comment on the ticket with your additional thoughts and concerns on the topic: SUGGEST-101 - Getting issue details... STATUS  

  4. Jordie DiepeveenMatthias Müller - glad to see you like the improvements. 

    When it comes to !include. For "incomplete snippets" we recommend to use a directory which is not scanned for definitions, something like /my-module/includes/*. The "old" docs were a bit misleading concerning this.
    (We should have recommended this already in the past - but that was my fault, so i'm sorry about this. (shrug))
    The above proposed directory makes sure that there will be no parsing "errors" (since the file will not be parsed) - so no problems showed in the definition app.

    Concerning the .yml extension, yeah, we have to check with the developer.


  5. Hi Magnolia

    I can not build magnolia bundle with the version 5.5.6 because I have problem with dependencies magnolia-module-multisite-1.2.1 , intern use the dependency

    <dependency>

           <groupId>info.magnolia</groupId>

            <artifactId>magnolia-project</artifactId>

            <version>5.4.13</version>

            <scope>import</scope>

            <type>pom</type>

          </dependency>

    This dependency doesnt exist in the repository.

    [ERROR] Failed to execute goal on project generali-intragenius-webapp: Could not resolve dependencies for project ch.generali.intragenius:generali-intragenius-webapp:war:1.0-SNAPSHOT: Failed to collect dependencies at info.magnolia.eebundle:magnolia-enterprise-pro-demo-webapp

    lia.eebundle:magnolia-enterprise-pro-webapp:pom:5.5.6 -> info.magnolia.multisite:magnolia-module-multisite:jar:1.2.6: Failed to read artifact descriptor for info.magnolia.multisite:magnolia-module-multisite:jar:1.2.6: Failure to find info.magnolia:magnolia-project:pom:5.4.13


    1. Please do not comment as user Shared account for Magnolia Training users. This makes it +/- impossible to properly communicate with you. Thanks for your understanding.

  6. Congratulations! Looks like an awesome release once more.

  7. Hi. I'm trying to use Magnolia 5.5.6 with new virtual URI module. I found that MultiSiteRegexpVirtualUriMapping class (from multisite module) extending info.magnolia.virtualuri.mapping.RegexpVirtualUriMapping does not exist in latest multisite module version 1.2.6 - it's only on master. 

    "The path "src/main/java/info/magnolia/multisite/mapping/MultiSiteRegexpVirtualUriMapping.java" does not exist at revision "magnolia-module-multisite-1.2.6" "


    Didn't you foget to release something ? (smile)

    1. Hi Mariusz,

      The updated URI mapping classes for multisite are coming with multisite 1.3, later this year.
      In the meantime, old mapping classes (as of multisite 1.2.6) are still fully supported.

      Actually, we checked the URI mapping release notes from 5.5.6, as well as the documentation page Virtual URI mapping#Mappingclasses, and there it seems up-to-date. May I ask where you found a reference to this upcoming class?

      Cheers,
      Mika

      1. HI Mikael.
        Class: info.magnolia.multisite.MultiSiteRegexpVirtualURIMapping will be deprecaded since 1.3

        Virtual URI Mapping module page (Virtual URI mapping#Properties) says:

        site
        required (for the MultiSiteRegexpVirtualUriMapping class)
        Specifies the site that should be used for the mapping.

        Please note camel case Uri in class name - the same is with new mapping classes from VirtualURI module.
        This class can be found in master branch of multisite module.

        What I mean, is that using MultiSite mapping from old version, I'm still using old virtual mappings from "core" module, not new ones, as
        info.magnolia.multisite.MultiSiteRegexpVirtualURIMapping extends old (and already deprecaded) info.magnolia.cms.beans.config.RegexpVirtualURIMapping


        I just think it's a bit incossistent, especially because new classes have Uri camel case in class name and filed names while old classes had URI - uppercase.

        1. Re: camelCase, good deduction. (wink)

          Maybe we should keep mentioning the old class there too (along with usage of the `fromURI` and `toURI` properties). Let's see if we can make the page more explicit about new vs. "old" mappings.

          using MultiSite mapping from old version, I'm still using old virtual mappings from "core" module, not new ones

          That is fine. Multisite mappings are not deprecated yet. As for the core mappings, they have just been deprecated, so they will be supported for another couple major versions of Magnolia. This also gives us the possibility to update our modules providing URI mappings gradually.

          We will inform when new multisite mappings are available. Thanks for bearing with us (on the edge!), that's appreciated.

  8. amazing, Congratulation!