CropRenditionHandler should consider the biggest web enabled rendition


Currently the CropRenditionHandler only considers web enabled renditions, which match following pattern:

This rendition is created automatically by the dam asset workflow, when an image is uploaded to DAM, and is used by the SmartImage widget for cropping. The workflow step can be edited to create a wen enabled rendition with bigger dimensions, which is a valid use case for example for stage components, using media formats like 1920x600, etc.

The CropRenditionHandler should be enhanced to use the biggest available web enabled rendition, to keep the backwards compatibility, in case there are some legacy renditions.


Igor Sechyn
January 26, 2015, 9:54 AM

is it correct that the DEFAULT_WEB_RENDITION_PATTERN still checks only for 1280x1280 renditions?

no, this was wrong, got lost after refactoring of the first solution. fixed in the latest commit.

done in 07cad07.

Stefan Seifert
January 23, 2015, 9:06 PM

ok - remarks:

  1. is it correct that the DEFAULT_WEB_RENDITION_PATTERN still checks only for 1280x1280 renditions?

  2. please add comments to the CropRenditionHandler.postProcessCandidates why it is needed

  3. please update changelog as well

Igor Sechyn
January 22, 2015, 9:17 AM

ok, i have tried another solution:

  • introduced another protected method for post processing of the list of candidates

  • per default the method just returns the original list. in crop rendition handler, the list is iterated backwards until the biggest matching web enbaled rendition is found. if one matching rendition is found the corresponding virtual crop rendition metadata is added to the candidates list.

this solution did not require to adjust any test cases, except for the total number of candidates. i am not sure though if it is ok. please have a look at it.

rev f5f8ff

Stefan Seifert
January 21, 2015, 9:18 PM

difficult to tell for all edge cases, but basically there should be no problem if an automatic-generated web-enabled rendition is used by an exact match in my opinion.

Igor Sechyn
January 19, 2015, 10:06 AM

this turned out to be a bit trickier. the solution is pretty simple. i only had to adjust code in two classes:

  • the compareTo method of the RenditionMetadat class to sort the list of candidates, where the virtual crop renditions are at the top sorted by the biggest web enabled rendition to be the first in the list

  • DEFAULT_WEB_RENDITION_PATTERN had to be adjusted to take all renditions starting with cq5dam.web., since this name is reserved for renditions generated by the workflow

the last change led to the failure of a couple of tests, the reason being the names of the renditions in the test sample content. all renditions were named cq5dam.web.*. After renaming the renditions (by removing the .web prefix) and adjusting the assertions accordingly everything was ok.

this still can be a valid case though. the workflow can contain several steps to create different web enabled renditions. if they all contain cq5dam.web. prefix in their names and the media handler was supplied with invalid crop dimensions, all of these renditions will be added as virtual crop rendition metadata and considered for the resolving as an exact match, which can be the case.

do you think we should consider this use case or maybe make other assumptions regarding the pattern for the virtual crop rendition metadata?





Igor Sechyn




Fix versions