A seasoned Sitecore developer would have come across “Sitecore Serialization” and certainly it’s a feature that always comes to rescue when large items are to be moved across environments or databases. In this blog post I will be sharing a hack related to Sitecore Serialization as it might help anyone else on the community. Lot of information related to Sitecore Serialization is available via beautiful blog posts. If you are looking to start from scratch to understand for Sitecore Serialization go through the links shared later in this blog post.
Hack… Hack… Hack… Sitecore Serialization
I discovered this hack which I didn’t find documented anywhere hence it gives me an opportunity to write about it.
We ran into an issue where we wanted to REVERT (Yes, it’s a REVERT and not RESTORE) Items from Web Database to Master Database. This statement might off track you with questions like,
Q: Why need to revert items form WEB to MASTER on the same environment using serialization when there is already a tool to transfer items “Move an item to another database” in Control Panel?
A: The challenge we had was items in MASTER database didn’t had language versions which were somehow deleted and the same items were published to WEB database which blew up some of the International Site Pages. Lucky enough, the items were serialized couple of days back before the publish happened. As said the serialization happened from the WEB Database which did contained the information of language versions too.
Q: Why not to restore database backup?
A: It would have been a more tedious task of restoring weekly full backup and on top of it daily partial backup. Also, the regression testing would have been a hack of an effort for testing full site.
REVERTing tree on the same environment will still not bring back the items into MASTER database as they were generated from WEB database. Also, we wanted to be sure that reverting items should be tested first on lower environments and then performed on production authoring server.
Taking the serialized backup in local and running the REVERT Tree command didn’t help. With some troubleshooting the hack was discovered and here’s what needs to be done,
- Make sure the serialized file is contained with a physical folder name that should match to a database on which one want the items to be reverted. For e.g.
- If the items are to be reverted on a master db the serialized file should be placed at a path \Data\serialization\master.
- If the items are to be reverted on a pub db the serialized file should be placed at a path \Data\serialization\pub
This only change will yet not revert the items
- The .item files too contains a reference of the database from which the files were generated. Try opening the files in a text editor and you can find “database:” reference.
So, we updated the name of the database to match it against the database name on which we wanted to revert the items.
Logged into sitecore-> Selected the item-> Switched to Developer Tab and ran the REVERT Tree command and the HACK worked which brought the language versions back.
The number of .item files were less than 50 hence we were lucky again to make the database name change quickly without making us write any script.
- Sitecore Serialization Guide
- Serialization and deserialization in Sitecore – KewlCodes
- Serialization and Deserialization in Sitecore