What should happen with uSync Publisher if the configured languages are out of sync between source and destination?

[LottePitcher]

Hello uSync,

We have 71 languages configured in a staging environment. These languages have been added directly to the staging environment when needed, i.e. not managed by uSync (in the 'default' handlerset languageHandler is off).

What would you expect to happen when pulling content from there (with content in all 71 variants) to an environment that doesn't have all of the languages configured? The 'publisher' handlerset has the languageHandler enabled.

The report at the start of the publishing process shows:

The first item, Teaser questions, does not vary by culture. The other six items, Teaser question X, are using a doc type that does vary by culture.

uSync publish does the pull and then confirms:

Only the first item, that didn't vary by culture, has been created. The other six items have not, although uSync doesn't explicitly confirm this. If I look in the logs there are 6 similar warnings (i.e. one per item):

"publishedContentHandler": Import Failed : "System.ArgumentException: Code da-dk does not correspond to an existing language. Parameter name: isoCode at Umbraco.Core.Persistence.Repositories.Implement.LanguageRepository.GetIdByIsoCode(String isoCode, Boolean throwOnNotFound) in D:\a\1\s\src\Umbraco.Core\Persistence\Repositories\Implement\LanguageRepository.cs:line 268

So really I'm wondering what the intended behaviour for uSync publisher is in this scenario?

Version Info:

• Umbraco Version: 8.12.2
• uSync Version 8.9.7
• uSync.Complete Version 8.10.3

And finally ...

Is there a way to configure uSync.publisher to allow the user to select which variants to push/pull? I checked the docs at https://docs.jumoo.co.uk/uSync/uSync.Complete/publisher/ but didn't spot any such settings.

Thank you!

[KevinJump]

That is a good question

As it stands uSync.Publisher doesn't check languages as dependencies for content, but i suppose it really should. I would say the intended behaviour should be :

1. if the user clicks include dependences (or more probibly Include content config) then we should go off and include languages in the dependecy check, and create them if they are missing as part of the content import.
2. if that value isn't checked, then I would guess the best outcome would be to import the languages we can import but not the ones we can't

i suspect there is a uSync (core) issue in faling an import when a language is missing, when we should just fail for that one language and carry on for all the other (valid) languages that might exist in the file.

we certainly should tell you about it mind. !

[KevinJump]

and yeah variant choosing is currently an all or nothing thing, maybe we could add a list - so it got limited to just a subset.. will take a look

[KevinJump]

just to add you can limit cultures in plain-old-usync - via the config

<Handler Alias="contentHandler" Enabled="true" Actions="All">
            <Add Key="Cultures" Value="fr" />
</Handler>

but i will be totally honest and say i do not know if that is then transferred to uSync.Publisher operations (it might be)

[LottePitcher]

I do appreciate variants has made publishing significantly more complicated!

In our scenario we have includeDependencies off as we wouldn't want doc and data types to get pushed to production in advance of the codebase. I think you could argue that language is something that is as important as doc and data type schema, so makes sense that their creation is dependent on that includeDependencies flag as well. For us I think option 2 would make sense, i.e. the node is created and the languages imported that are configured on the destination site, rather than no node at all as happens currently.

When you say 'include content config' is that <includeConfig>yes</includeConfig>? What does that setting do, I realise we have it as yes but not actually sure what it does.

[KevinJump]

Include Config, includes things that can be set on a node - so Culture and Hostname settings and public access settings

[KevinJump]

~Will be~ is fixed for the next release of uSync 👍

[LottePitcher]

Excellent work Kevin, H5YR!