Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Please note that the old Lucene indexer is no longer supported, please use the ElasticSearch search.

User interface changes

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

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 :

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.

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.

ETags within the REST API end points

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

The automatic switching is now done on the Akamai property level, so there is some parameters that need to be set up by eSaas in order to have it working.

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.

The new Analytics are available as a preview, and will only show actions / connections occurring on the back-office only for this version.

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

  • No labels