Upgrading to 11.30
Please note that the old Lucene indexer is no longer supported, please use the ElasticSearch search.
The ElasticSearch support for versions prior to 6.8 has been dropped.
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 :
Please note that we now strongly advise to tag the properties you want to be part of the suggester with the tag “autosuggest”.
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:
This configuration change relies on new available transformers (see Metadata and AI extraction with DAM_Utils) and new preset:
Updated structures
asset
Fields changes:
modified: Added
inlist
status: Added
inlist
name: Added tag
autosuggest
namefr: Added tag
autosuggest
binary:
Added
inlist
Added tag
autosuggest
source: Added
editable
keywords: Added tag
autosuggest
namede: Added tag
autosuggest
description: Added tag
autosuggest
descriptionfr: Added tag
autosuggest
descriptionde: Added tag
autosuggest
mediaid: Field removed. (it is not required to remove this field from your system)
assetgeography
Fields changes:
activated: Default value is now
2
(inactive)
edplitem
Fields changes:
user: Removed
inlist
edpltask
Fields changes:
description: Removed
inview
duedate: Removed
inview
attachedfile: Removed
inview
channels: Removed
inview
group: Removed
inlist
viewable
massimportjob
Fields changes:
id: Added tag
subjob_prop
status: Added tag
subjob_prop
jobowner: Removed
mandatory
subjobs: New property
pimasset
Fields changes:
status: Added tag
rest_api_include
keywords: Removed tags
gallerycard_meta
andgallerycard_meta/without_label
productassettype: Added tags
gallerycard_meta
andpopinlist_search_group
product
Fields changes:
hero: Added tag
gallery_thumbnail
organization: Added field
role
Fields changes:
rubrique: Removed
inlist
resolutions:
Removed
inlist
Removed
viewable
user
Fields changes:
password: Added tag
rest_api_profile_include
firstname: Added tag
elasticsearch/analyzer/keyword
vueapphomewidget
Fields changes:
descriptioncart1: Added field
descriptioncart1fr: Added field
descriptioncart1de: Added field
descriptioncart2: Added field
descriptioncart2fr: Added field
descriptioncart2de: Added field
descriptioncart3: Added field
descriptioncart3fr: Added field
descriptioncart3de: Added field
descriptioncart4: Added field
descriptioncart4fr: Added field
descriptioncart4de: Added field
usecartdescription: Added field
Troubleshooting
If you are experimenting issues with Analytics API calls ending with 500 errors on Portal homepage can be solved using a complete Analytics reload as described here :