Image fallback - is it supported?

[aDNers]

Hello,

Short version of the question:

Is it possible to use images as fallback if a selected language doesn't have a locale version of the image (uploaded as image, not binary)?

Long version:

I have copied an image folder to the localhost installation of dotcms using webdav (all ended up on /webdav/live/1). 

If I print out $URLMapContent in order to list whats available I am indeed able to see the image identifier. But trying to get the value of it using $URLMapContent.image doesn't give me anything - unless I open up the actual image and save a version to my new language.

When I am looking at the content in the admin gui - the image shows (although the actual file has another another language id).

I would really like to be able to show the same image in all languages or "fallback" to the image from the default language if a local language version of the image is not available. If this isn't possible I need to copy the image folder into all possible languages (which seems a bit unnecessary.)

My current settings for fallbacks are as follows, but images doesn't seem to be recognised as either a "File" or a "contentlet". 

## if this variable is set true and the contentlet you are looking is not in the language you are on,

## this will show the contentlet in the default language (Fallback to the default language). If is set to false

## this aditional search is avoided

DEFAULT_CONTENT_TO_DEFAULT_LANGUAGE=true

## it is similar to DEFAULT_CONTENT_TO_DEFAULT_LANGUAGE but only applies for Widgets

DEFAULT_WIDGET_TO_DEFAULT_LANGUAGE=true

## it is similar to DEFAULT_CONTENT_TO_DEFAULT_LANGUAGE but only applies for Pages

DEFAULT_PAGE_TO_DEFAULT_LANGUAGE=true

## it is similar to DEFAULT_CONTENT_TO_DEFAULT_LANGUAGE but only applies for Files

DEFAULT_FILE_TO_DEFAULT_LANGUAGE = true

Here are code version of what I tried to explain above:

$URLMapContent prints:

com.dotmarketing.viewtools.content.ContentMap@12a265c3[content=com.dotmarketing.portlets.contentlet.model.Contentlet@36ddf26c[map={

image=78c7344f-cbce-4995-b286-53e9b7977d91,

context=org.apache.velocity.tools.view.context.ChainedContext@2865775c] 

$URLMapContent.image prints: 

$URLMapContent.image

If I re-save the image as the new language the last row ($URLMapContent.image) instead returns the expected:

com.dotmarketing.viewtools.content.FileAssetMap@11d2139f[

metaData={"

component1":"Y component: Quantization table 0, Sampling factors 2 horiz/2 vert","imageWidth":"980 pixels","component2":"Cb component: Quantization table 1, 

Sampling factors 1 horiz/1 vert","component3":"Cr component: Quantization table 1, Sampling factors 1 horiz/1 vert","xResolution":"1 dot",

"tiffBitspersample":"8","tiff:ImageLength":"551","dataPrecision":"8 bits","numberOfComponents":"3","compressionType":"Baseline",

"imageHeight":"551 pixels","yResolution":"1 dot","resolutionUnits":"none","fileSize":"58446","width":"980","tiff:ImageWidth":"980",

"contentType":"image/jpeg","height":"551"},path=,fileDimension=java.awt.Dimension[width=0,height=0],

map={owner=dotcms.org.1, identifier=78c7344f-cbce-4995-b286-53e9b7977d91, modDate=2017-12-01 14:41:03.0, 

testimage-980x551px.jpg=testimage-980x551px.jpg, languageId=3, showOnMenu=false, 

inode=403c80eb-7b4b-4cd8-bcc6-1121fa8b86f3, 

fileAsset=C:\development\dotcms422_dec\dotserver\tomcat-8.0.18\webapps\ROOT\assets\4\0\403c80eb-7b4b-4cd8-bcc6-1121fa8b86f3\fileAsset\testimage-980x551px.jpg, 

folder=ea18f448-0948-43de-84fc-b71394aaa1b3, disabledWYSIWYG=[], sortOrder=0, modUser=dotcms.org.1, host=48190c8c-42c4-46af-8d1a-0cd5db894797, 

lastReview=2017-12-01 14:41:03.0, stInode=33888b6f-7a8e-4069-b1b6-5c1aa9d0a48d},lowIndexPriority=false] 

[Chris Falzone]

We ran into this as well as we have a lot of contents that exist in multiple languages but the referenced files only exist in the default language most of the time.  

This is actually a bug that was introduced in 4x, and there is a fix in the works:  https://github.com/dotCMS/core/issues/12820

It should be falling back to the Default Language if DEFAULT_FILE_TO_DEFAULT_LANGUAGE is set to true (the default)

We've been running in production on 4.1.1 with this code change hotfixed with no issue.  

Hope it helps.

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/11293a48-7d2f-4974-9894-5ce7724bfb8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Michael Thomas]

Note also that the fallback only works if you add the Files/Images as "File" or "Image" type fields in the content type; if you're adding files or images in "Binary" fields there's no way for those to fall back (since they're part of the content).  From what you've said I don't think this is what you're doing, but it's something to be aware of when creating your content types.

[Chris Falzone]

Correct, I think by design.  Binary Fields are only for the current version of the content, you have have to have a copy of the image or file in language version.  

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To post to this group, send email to dot...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/370f85da-6d29-43f5-875c-14900cb73d2f%40googlegroups.com.

[aDNers]

Chris, John:
Thanks for the quick response. This forum is amazing ☺️
Will check the fix once back at the office on monday, but its really good news that this was a known (and solved) issue. I think it will solve our problem, and (yes - we are using the image field and not binary upload for the requested field.)

Thanks again!

[aDNers]

Hi,

Just to confirm, I tried the latest nightly build (commit 18755298b8) and the issue has indeed been solved, so I will keep on developing on this until a 4.3 is ready for production.

Br

Anders

[aDNers]

Hello, 

We (again) gets this behaviour with the production release of 4.3.1 - however in a nightly build of version 4.3.0 everything works as expected. 

Any ideas on when the fix referenced earlier by Chris Falzone could be part of an official release? ..or perhaps if there is a quick fix? 

We really need this to work before going live with our setup. Right now we are not building from source but using the released installations, maybe we need to start using the source versions?

BR

Anders