We are using Umbraco 8, with uSync v8.6.4, with DocType Grid Editor v1.2.3
We made a number of content pages with the DocType Grid Editor, and put some macros in place initially for content. Now, locally we've replaced some of those macros with some other new doc types to change content.
We use uSync to export locally, and push those files up to the Azure App Service (using Visual Studio publish, and we've also tried FTP).
In the uSync XML files created, we can see the updated changes locally. Once published, we also see those changes in the XML files up on the staging site that uSync should use. So the uSync import in staging SHOULD be able to see the "new stuff".
We run the uSync import in staging, and it has no errors, but the pages using that DocType Grid editor do not get updated. They're still calling for old macros that no longer exist, and so error out.
It's almost like uSync doesn't actually update the database, but acts like it did. Is there something we're missing to get uSync to update things?
I will have a go at recreating exactly, creating macros and replacing them with doctypegrid editors. is there anything facny in the macros ? DTGE elements?
also just to confirm the version of Umbraco you are running? (e.g 8.6.3?)
We actually just kept digging into it and found that somewhere along the way, there had been multiple languages set for the doc type, but then deleted. For some reason, when we updated the content, it would update in the non-culture specific version while the en-us version would hold the old content. Then when we would try to import it, it would import the en-us version, so it wouldn't have the new changes. By removing the en-us section from the config files, we were able to get the new content up.
We've tried a few things to capture and surface what happens when a site goes from single to multiple languages, looks like we also need to look a bit more into the multiple -> single route too.
uSync with DocType Grid Editor
We are using Umbraco 8, with uSync v8.6.4, with DocType Grid Editor v1.2.3
We made a number of content pages with the DocType Grid Editor, and put some macros in place initially for content. Now, locally we've replaced some of those macros with some other new doc types to change content.
We use uSync to export locally, and push those files up to the Azure App Service (using Visual Studio publish, and we've also tried FTP).
In the uSync XML files created, we can see the updated changes locally. Once published, we also see those changes in the XML files up on the staging site that uSync should use. So the uSync import in staging SHOULD be able to see the "new stuff".
We run the uSync import in staging, and it has no errors, but the pages using that DocType Grid editor do not get updated. They're still calling for old macros that no longer exist, and so error out.
It's almost like uSync doesn't actually update the database, but acts like it did. Is there something we're missing to get uSync to update things?
Hi Emily,
I've just double checked, and the doctype elements should come across with the sync :( it's likely something is going wrong somewhere in the process.
so things to check.
I would also look in the logs on the site to see if there are any issues being flagged up by usync during the import - (settings -> log files) .
you can also turn on debug logging for uSync, by adding the following to the serilog.config file
I will have a go at recreating exactly, creating macros and replacing them with doctypegrid editors. is there anything facny in the macros ? DTGE elements?
also just to confirm the version of Umbraco you are running? (e.g 8.6.3?)
Hi Kevin,
Thanks for the quick response!
We actually just kept digging into it and found that somewhere along the way, there had been multiple languages set for the doc type, but then deleted. For some reason, when we updated the content, it would update in the non-culture specific version while the en-us version would hold the old content. Then when we would try to import it, it would import the en-us version, so it wouldn't have the new changes. By removing the en-us section from the config files, we were able to get the new content up.
Cool, glad you found the problem.
We've tried a few things to capture and surface what happens when a site goes from single to multiple languages, looks like we also need to look a bit more into the multiple -> single route too.
is working on a reply...