A client of mine recently had a situation that we decided was best handled by uploading an XML file into a Sitecore item for their Sitecore 6.6 site. Due to some business rules, we decided that we didn’t want the upload to be stored directly in the media library, but instead in a data template that contained some other specific fields. We took a look at the Sitecore OOTB Unversioned File template and saw that it’s field that you upload a file to is of the Attachment field type. So, we decided we’d create a new data template and use the Attachment field type for the field where the Content Author would upload the XML file. We learned some interesting things about the Attachment field type during this work, and I’ll share our lessons learned in this post.
The first lesson we learned is that an Attachment field type has to be named “Blob” (or “blob”, it’s case insensitive) in order to work completely. If you try naming your attachment field differently, when your Content Authors go to upload a file, it’ll appear as if the file is NOT saved after it’s been uploaded. (I say it’ll “appear” this way, because if you rename your field to Blob after a file has been uploaded, the file magically appears properly.) Doing a little bit of searching, I did come across a known issue way back in Sitecore 5.3 that states “An Attachment field type will work properly only if it is named Blob.” I can’t find anything more recent than that about this issue. (As a coworker said, that means it’s not a bug, it’s a feature!) My recommendation regarding this is to populate the Title property on your Attachment field so that the Content Author sees a more meaningful, contextual name than “Blob”.
The second lesson we learned related to any other fields on our template in addition to our Attachment Field. It turns out that whenever you attach a file to your Attachment Field, all other unsaved data on that Item will be wiped out. Thinking about it, there’s probably a perfectly good technical explanation for this – you can’t upload a file in AJAX with .NET, so uploading the file to your field causes your item to refresh, losing any unsaved data. This could definitely be frustrating to Content Authors who are unaware of such an occurrence though. Nothing like spending your time typing something out only to have it get lost because of a simple action. My recommendation for this issue is to order any Attachment Fields at the top of your template. That way, the Content Author is presented with the Attachment Field first, and will hopefully upload their file before they go onto the next field.
One final lesson about the attachment field – while the code itself is relatively easy, it’s not very intuitive how you would go about retrieving the content of the field through code. For our requirement, we needed to pull out the uploaded XML file so that we could compare its contents in code. It took me a while to determine the proper method to do this through the API. Since I’ve been giving recommendations for the other lessons, I’ll provide a recommendation for this too: read on a little further and copy and paste my example code here and then fit to your needs!
Here’s how to retrieve the file that was uploaded into an Attachment Field through code (assumes “myItem” is an Item with an Attachment Field named “Blob”):
string myUploadedFile = string.Empty;
Sitecore.Data.Fields.FileField myBlobField = myItem.Fields["Blob"]; System.IO.Stream myBlobStream = myBlobField.InnerField.GetBlobStream();
using (System.IO.StreamReader reader = new System.IO.StreamReader(myBlobStream))
{
myUploadedFile = reader.ReadToEnd();
}
Hopefully with the above information you can also be successful working with the Attachment Field type in Sitecore. If I may have one final recommendation though, I would say the following: If your requirements don’t prevent you from storing the uploaded files in the Media Library of Sitecore, I would suggest that instead of using an Attachment Field type directly in a data template, you instead choose to use a field of “File” type. This field does NOT have the same requirements as the Attachment field, while still allowing the uploading of a file to your template (through a GUI that puts the file into the media library as a separate item) and is a preferred method to directly utilizing the Attachment Field.
