I am new to Umbraco an Usync, so maybe I am missing something and this is expected behavior.
But I have a problem of moving data from Dev-env to Test-env using Usync.
Short description:
Page/node is created in Test-env but not published and content is missing.
Log-files give WARN
Second Import Failed: Variation \"<null>,<null>\" is not supported by the property type
Manually adding the content and publishing it works OK.
Can I somehow get more info about what property type isn't working?
What does "variation null, null" actually mean?
Longer description:
Site is set-up with two languages (sv and en).
In dev-env I add a node/page with content and publish it in lang 'sv' and 'en'.
Then I use USync to export the files. These are created OK with the correct content in the files.
(under folders Content and Domains, "OK" as far as I can tell that is. The Domain-folder has many files with seemingly same content in them)
The USync files are moved to Test-env. I do a "Full Import".
I can see the new Node in the info of importing.
Then I look at "Report Content/Media". And the data is there when I look at the "Details" but only for the main language (sv).
Chosing Content in Umbraco I can see that the page/node has been created but it is not published (Draft) and none of the content data is filled. For none of the languages.
If I look at the History it says "Save, Content saved for languages: English (United States), Swedish (Sweden)". But no publish.
I can add the content manually and publish the page manually, so I guess all types should be there? (only standard types/property editors are used)
For info this is my (simplified) node-setup:
- Home (en + sv)
-- Blog Posts (en + sv)
--- Category 1 (en + sv)
---- Post 1 (en + sv)
Example of full error from /Logs:
{"@t":"2019-12-05T08:40:29.6648394Z","@mt":"Second Import Failed: Variation \"<null>,<null>\" is not supported by the property type.","@l":"Warning","SourceContext":"Umbraco.Core.Models.IContent","ProcessId":7476,"ProcessName":"w3wp","ThreadId":29,"AppDomainId":4,"AppDomainAppId":"LMW3SVCXXROOT","MachineName":"MA-1","Log4NetLevel":"WARN ","HttpRequestNumber":4,"HttpRequestId":"9904d111-886d-49a0-87b5-a2cef508d1cf"}
Thanks for your time if you made it all the way down here! =)
thanks for the quick answer and your reading stamina! :-) 👓💪
Yes, I mentioned the part about the Domain-folder because it didn't feel right. I couldn't put words on it but it seems wobbly is the actual term then.
Yes, the target site has got the languages installed correctly (tm).
(seems OK to me that is, new at Umbraco)
Right now there are a total of 14 files in the Domain-folder. One of those is ".config", the rest have "funny" names. (see pic below) Eg. "av2j5yph.config" or "en0hflpnkz.config", but one also has a not-quite as funny name of "en.config".
Extra edit info:
I tried deleting the uSync-folder and doing a new export. This only generated 2 files under Domain (.config and en.config). Full import on Target made no difference though.
I tried adding a new page, exporting and it now creates "funny named files" under Domains again.
Sorry for the wait, we wanted to make sure everything was OK with Umbraco v8.4 before we pushed out any updates.
but We've fixed the issue with the multiple files getting created in the domains folder in the latest release. this should help to reduce the confusion in the sync. (you may want to clear out the folders and do a new export to make it nice and clean).
i am not 100% sure if this will completely solve your issues, as i couldn't then recreate what you are seeing, but hopefully its a nudge in the right direction.
I've tried it and it seems to fix the problem with the wobbly domain-stuff!
Unfortunately it didn't fix the problem with content not being updated. I'm guessing something (else) in our set-up is wobbly also... Solving the content-copying right now by using a SQL-script, it is mostly during dev we will need this feature.
But big thank you for reaching out and fixing! And thanks for USync, an awesome tool! 👍🙌
I've had another go, and I can reproduce something similar to your error when I deliberately get the doctypes out of sync.
If I first have a property value on my content that allows varying by culture and have that synced across two sites.
then I remove the allows varying by culture from the property, this will remove the cultures, but crucially it won't update all the content files where this value is set.
if you then move them across and attempt sync. you get an error on a property set.
(in my case I am getting)*
Second Import Failed: Variation "en-us,<null>" is not supported by the property type.
this is because uSync is attempting to set a language on a property that no longer supports languages.
The workaround/solution is that you have to re-export content if you change a property from allow varying by culture to not.
I am looking at what changes/warnings we can put in place in uSync for this, I am thinking we remove the culture and attempt to set the value as is when there are no longer cultures available. this will at least set a value, but a full content export will still be a recommended step with this one.
so sorry about this late reply, I actually missed your comment! :( I came back because I got a mail to mark it as solved.
I tried it a bit, and I think you are correct. I tried to create a couple of new pages that don't allow "vary by culture" and these are synced correctly.
I also did try to re-export all content but this doesn't fix the problem for me unfortunately. The same problem is still there (content not set and page is not published). But everything else works (as in created types etc).
Thanks for your time! I'll mark this as solved since I believe we basically know why this probably happens (wow, so secure in my wordings ;-) ).
If we get to a point where we have a mismatch between the doctype and the content, we try to set the value based on what is the default culture, so that should at least get some value set as part of an import.
but I am going to double-check other things work because a re-export/import should fix it.
USync copies added node but not the content (multi language site)
I am new to Umbraco an Usync, so maybe I am missing something and this is expected behavior.
But I have a problem of moving data from Dev-env to Test-env using Usync.
Short description:
Page/node is created in Test-env but not published and content is missing.
Log-files give WARN
Manually adding the content and publishing it works OK.
Can I somehow get more info about what property type isn't working?
What does "variation null, null" actually mean?
Longer description:
Site is set-up with two languages (sv and en).
In dev-env I add a node/page with content and publish it in lang 'sv' and 'en'. Then I use USync to export the files. These are created OK with the correct content in the files.
(under folders Content and Domains, "OK" as far as I can tell that is. The Domain-folder has many files with seemingly same content in them)
The USync files are moved to Test-env. I do a "Full Import". I can see the new Node in the info of importing.
Then I look at "Report Content/Media". And the data is there when I look at the "Details" but only for the main language (sv).
Chosing Content in Umbraco I can see that the page/node has been created but it is not published (Draft) and none of the content data is filled. For none of the languages.
If I look at the History it says "Save, Content saved for languages: English (United States), Swedish (Sweden)". But no publish.
I can add the content manually and publish the page manually, so I guess all types should be there? (only standard types/property editors are used)
For info this is my (simplified) node-setup:
Example of full error from /Logs:
Thanks for your time if you made it all the way down here! =)
Hi Roland,
don't worry I made it to the bottom!
I suspect the issue is with the domains/languages bit because it looks from what you say
that sounds a bit strange, like its gone wobbly* there.
can you just confirm a few things for me?
has the target site got the languages installed (in settings/languages)? - uSync should do this first but it's probably worth checking it has.
also when you say the domain folder has many of the same files, can you say how many, and maybe chuck an example of the content in here.
If you send that over I will have a go at reproducing it, to see if I can get the same behaviour.
*wobbly is, of course, the correct technical term here.
Hey Kevin,
thanks for the quick answer and your reading stamina! :-) 👓💪
Yes, I mentioned the part about the Domain-folder because it didn't feel right. I couldn't put words on it but it seems wobbly is the actual term then.
Zipped Domain-folder (https://wetransfer.com/downloads/cab21aad01157441675a57e47e5f961020191205104253/28f428575c8085ae748813d9df9eab1520191205104253/a42aa8)
File content in one of these files (_av2j5yph.config):
Extra edit info: I tried deleting the uSync-folder and doing a new export. This only generated 2 files under Domain (.config and en.config). Full import on Target made no difference though.
I tried adding a new page, exporting and it now creates "funny named files" under Domains again.
Hi Roland,
Sorry for the wait, we wanted to make sure everything was OK with Umbraco v8.4 before we pushed out any updates.
but We've fixed the issue with the multiple files getting created in the domains folder in the latest release. this should help to reduce the confusion in the sync. (you may want to clear out the folders and do a new export to make it nice and clean).
i am not 100% sure if this will completely solve your issues, as i couldn't then recreate what you are seeing, but hopefully its a nudge in the right direction.
Kevin
Hello Kevin,
no problems, thanks for your efforts!
I've tried it and it seems to fix the problem with the wobbly domain-stuff!
Unfortunately it didn't fix the problem with content not being updated. I'm guessing something (else) in our set-up is wobbly also... Solving the content-copying right now by using a SQL-script, it is mostly during dev we will need this feature.
But big thank you for reaching out and fixing! And thanks for USync, an awesome tool! 👍🙌
Best regards, Roland
Hi Roland,
I've had another go, and I can reproduce something similar to your error when I deliberately get the doctypes out of sync.
If I first have a property value on my content that allows varying by culture and have that synced across two sites.
then I remove the allows varying by culture from the property, this will remove the cultures, but crucially it won't update all the content files where this value is set.
if you then move them across and attempt sync. you get an error on a property set.
(in my case I am getting)*
this is because uSync is attempting to set a language on a property that no longer supports languages.
The workaround/solution is that you have to re-export content if you change a property from
allow varying by cultureto not.I am looking at what changes/warnings we can put in place in uSync for this, I am thinking we remove the culture and attempt to set the value as is when there are no longer cultures available. this will at least set a value, but a full content export will still be a recommended step with this one.
*This isn't quite your error I get "en-us,
Hi Kevin,
so sorry about this late reply, I actually missed your comment! :( I came back because I got a mail to mark it as solved.
I tried it a bit, and I think you are correct. I tried to create a couple of new pages that don't allow "vary by culture" and these are synced correctly.
I also did try to re-export all content but this doesn't fix the problem for me unfortunately. The same problem is still there (content not set and page is not published). But everything else works (as in created types etc).
Thanks for your time! I'll mark this as solved since I believe we basically know why this probably happens (wow, so secure in my wordings ;-) ).
Best regards, Roland
Hi Ronald,
yes, I did do a little bit extra on this, in the next uSync release - there will be a bit which tries to recover from this issue.
https://github.com/KevinJump/uSync8/blob/v8/8.2/uSync8.ContentEdition/Serializers/ContentSerializerBase.cs#L231-L251
If we get to a point where we have a mismatch between the doctype and the content, we try to set the value based on what is the default culture, so that should at least get some value set as part of an import.
but I am going to double-check other things work because a re-export/import should fix it.
That is appreciated, thank you Kevin!
Just to make sure I understand, since I am still very much a noob:
Is this what you call a "re-export"? Or am I missing some step?
is working on a reply...