User interface changes

The filters will now remove terms with 0 occurrences (except tree filters)

This behaviour has to be activated per filter :

{
  "field": "keywords",
  "filterCursorUsingAggregate": true,
  ...

This will add some load on the server and ELS.

It is now possible to navigate from the portal preview windows :

If the asset has transparency, it will be displayed on a checkered background :

(currently broken on DCW)

The suggest bar is a bit longer, and the select colour is lighter :

The portal will now display the version number :

If you prefer not to display the version number, you may use the

src/wedia-plugin-template/res/_portal/menu/hide-server-version.json

config entry point.

The facets will now be honoured on the asset view, and profile view in the portal.

Security Rules changes

First, and foremost, new Security Domains and Actions can now be included into plugins by adding a file names “security.xml” in config directory : this is a sample of such file:

<?xml version="1.0" encoding="UTF-8" ?>
<security>
    <domain name="boards" description="Devine" system="true" enabled="false">
        <action name="makePublicBoard" description="Allow user to make a public board">
            <param name="surfer" type="wsnoheto.securite.parameter.SurferParameter"></param>
            <rule name="default" description="No restriction" enabled="true" blocking="false">true</rule>
        </action>
    </domain>
</security>

The syntax of this file is the same as the global schema.xml generated by security/admin UI.

The following rules apply on merge :

• Missing domain are added ( as disabled ) with their actions and rules.

• Missing actions are added with their rules.

• New rules are not added to existing actions.

• New macros are added.

• The runtime config is set but the global file is not saved on disk until you save it manually or do a backup.

• Be careful to add some default rule to new action of an existing domain if you don’t want weird behaviour on production because actions can’t be disabled alone.

Two new domains have been added : 

MediaCloud/mediaAction : this domain and action is added by the WXM_DAMDY plugin. They allow for filtering authorised action when manipulating Videos : creating new chapters, setting video poster, subcaptionning…

boards/makePublicBoard : this domain and action allows for authorizing the connected user to create or not public boards.

Portal Setup changes

Setting up eTags on REST Resources

When the Portal ask for REST resources, such has a list of keywords, or folders, in order to populate filters, it is very likely this list has not changed since the last call.

This will lead to better Portal performances, as we will leverage the browser cache for long lists of categories, keywords, or other metadata lists.

In order to gain network traffic, the 11.30 introduces “ETags” in the REST API answers. The ETag HTTP response header is an identifier for a specific version of a resource. It lets caches be more efficient and save bandwidth, as a web server does not need to resend a full response if the content has not changed.

To benefit from this speed enhancement, you must configure when ETags should be calculated on your REST resource lists. Multiple strategies are available, and some are suitable for clustered Tomcat architecture, and some are not.

Please read the full documentation for understanding how to set everything up.

DXM

Automatic file format switching :

If you do not provide an explicit file format in the variation, Wedia will return the most adapted format, depending on the browser (most likely it will be webp) :

For example :

This will return a JPEG :

https://club-wed.wedia-group.com/api/wedia/dam/transform/8muczkpi73bhwtc6zw3qnt7s7h/my-seo-file-name.jpg

This will likely return a Webp, or a PNG :

https://club-wed.wedia-group.com/api/wedia/dam/transform/8muczkpi73bhwtc6zw3qnt7s7h/my-seo-file-name

Selecting the best trade-off between performance and quality :

When you are cropping on the content picker, you must start with a specific variation that will serve as the basis for your crop result :

The issue is : if we are working with the best quality, the crop result may take 20, 30 seconds to be generated, depending on the image original size. If we are working with a “large” preview, some very detailed crops may not be possible, because the “large” is not large enough.

So it’s up to you to understand your client needs, and set up the best option for the “starting point” variation : this is available in the WXM_VARIATION_API plugin setup, in that option :

New analytics

We are creating a new version of the back-office analytics screens. The old version will continue to work for a long time, but this new version will be in some point in the future the default version for the clients.

To activate the new Analytics, you must activate the plugin “WXM_ANALYTICS_V2“ and create a new back office menu that will point to : wcm.jspz?form_action=stats

PACKAGED_DAM_Utils default configuration

The plugin default configuration has changed in order to automatically publish items created from portal in corresponding funds:

    {
      "objectSelector": "#damobject",
      "preventGuard": {
        "classAlias": "negate",
        input: {
          "preset": "canPublish"
        }
      },
      "workflowTrigger": [
        "publish"
      ]
    },

This configuration change relies on new available transformers (see Metadata and AI extraction with DAM_Utils) and new preset:

{
  "key": "canPublish",
  "classAlias": "every",
  "input": [
    {
      "preset": "preventExecutionFromMassImport"
    },
    {
      "classAlias": "isAllowed",
      "init": {
        "action": "changestatus",
        "params": {
          "newstatus": "6"
        }
      }
    }
  ]
}