SVT fields reset during Post Installation

[reedyd]

What determines the Post Installation instructions for SPD? I'm seeing a lot of "Resetting field" messages like this at the end of __Upgrade Install.log:

Executing Post Installation instructions: 'HedgehogDevelopment.SitecoreProject.PackageInstallPostProcessor.DoPostDeployActions,HedgehogDevelopment.SitecoreProject.PackageInstallPostProcessor.dll'
10/2/2019-8:10:00 AM: Starting PostDeployActions. Using assembly version 6.0.0.4
...
Resetting field myFieldName in /sitecore/templates/User Defined/myCustomTemplate/__Standard Values

We recently converted several template fields from Versioned to Shared. Our first release to QA crashed the site badly -- every Shared field lost its value. Then we learned about a bug fix and upgraded from TDS 5.7.0.11 to TDS 6.0.0.4. Most Shared fields now retain their data, but we still have found gaps. The "Resetting field" log entries correspond to the data loss.

In the TDS project in VS, all my templates sync perfectly. So, I'm led to believe that the .item source files have integrity. And yet this bug makes me wonder.

Any help would be greatly appreciated:)

[cturano]

Those post steps are determined by the contents of the package. If you install the package using the package installation wizard, you will see the same messages. It isn't a function of the package deployer.

TDS creates the post steps to make the package installation match installing the solution using the service. The Sitecore package API handles Standard Values differently than other items, so we wrote post-steps to make the install more predictiable. Please contact us at support@hhog.com with more details about the issue and we can address it. Please let us know what data is in the actual standard value item and what the expected outcome should be.

Thanks!

[reedyd]

I have a solution, thanks to a colleague who led me to this article:

https://sitecore.stackexchange.com/questions/7899/what-is-the-difference-between-default-value-of-a-template-and-its-standard-val

The post by TxRegex corrected my understanding of the interplay of a field's Default Value and the respective SVT. I had been relying entirely on SVT to define my defaults. My solution was to set the Default Value of the field. That field was created after the SVT was created -- which may explain why the value in the SVT was overwritten with the null Default Value from the field itself.

[cturano]

Can you tell us if TDS was doing something wrong? If this was a TDS bug, I want to get it fixed.

Thanks!

[reedyd]

I don't see evidence of a bug. Thank you.

[cturano]

Awesome! Thanks for letting us know it's working. Please let us know if you need anything else.