Sitecore’s uiUpload vs item:created Pipelines

Monday, December 07, 2015 @ 04:05

By: Corey Adler

Well, how about that? Not that long after solving the issue found in my most recent blog post (which I highly recommend that you read), a change request came across my desk that smelled almost exactly the same as the last problem I’d faced. This time, however, the journey came with some twists and turns, along with some interesting tidbits that I learned about Sitecore. The problem that was happening occurred during uploading images to a folder. Sitecore was allowing multiple files of the same name and file type to be uploaded into the same folder. The clients didn’t like that that was happening and wanted it to be more like what Windows does in such circumstances – append a number to the end of the file name.

Much like the last post, my thoughts immediately went to hooking up an event to a pipeline, have it change the file name, and then let it save to the database. It didn’t take me long to figure out a location to put a potential fix in: The uiUpload pipeline. From there, I assumed, I could very easily process any files being uploaded, make any necessary adjustments, and let it finish. It would then run the code for any file that was uploaded across the site (and not just to Media Library), and everything would be all right, right?

So I went out and did that, and it worked beautifully from Content Editor! Figuring that I would just be cautious, I went into Page Editor and decided to try using the Upload Media modal (shown below). After all, uploading from one place in Sitecore or another has to fall under the same pipeline, right? So I went boldly into Page Editor, attempted the upload in the modal, and…it didn’t change the name. Huh? Why did this happen? Well it turns out that the Upload Media modal doesn’t actually use that pipeline at all. It actually is its own separate command which you can find in the Commands.config file. Inside the code for the command are a number of calls to .aspx files to do the dirty work—rather than calling the code that would use the uiUpload pipeline.

Item Created Pipeline One

So what did that leave me with then? If I couldn’t use the uiUpload pipeline for it, what could I use? The solution that I used instead was reminiscent of using a sledgehammer to nail something to a wall: The item:created pipeline. I’d already used the item:saving pipeline to satisfaction before with my last issue, so why not use another, similar pipeline to solve this issue? The only disadvantage that I could see was the fact that it would be called every single time an item was created (hence the sledgehammer picture), but I couldn’t see any other way around it.

Here’s the handler code that I wrote (note that the method signature, as well as the start of the method, are almost exactly the same as that from the last post’s code):

Item Created Pipeline Two

Some notes to describe what’s going on in the code:

  1. For this method, I used the ItemCreatedEventArgs class, which has the Item that was created as a property – unlike item:creating, which does not
  2. I created some constants for the different file types that could be uploaded. These contained the GUIDs for each of those templates – making sure to get both the versioned and unversioned types
  3. This is a simple check to make sure that the template of the new Item is one of those that we want to adjust – preventing the sledgehammer from hitting the wall for no reason
  4. Then I check to make sure that there is an actual, duplicate file with the same name and same type in the same level of the content tree – my first version of this file forgot to check for the template type, so BE CAREFUL! If no duplicate was found, then it returns
  5. Here’s something very important: Before touching anything on the item itself, you must enter Edit mode, or else an error will be thrown in the code (and not necessarily show up in the Content/Page Editor). Also, be sure to have the call to BeginEdit before the loop
  6. Inside the loop, the first thing that happens is to create a new string variable that contains the potentially new name of the file – including the number appended to the end of it. It then checks the content tree level again, much like in #4 above. If it finds something, it adjusts the count, so that a higher number will be tried next time, and continues the loop. If it doesn’t, it immediately assigns the adjusted name to the created item’s name and returns (making sure to end Edit mode as well)

After that, all that needed to be done was to add the appropriate handler into the config file, much like with the last post.

Item Created Pipeline Three

And then, sure enough, after getting everything set up…

Item Created Pipeline Four

Beautiful! I love when things come together like that. I think I’m going to take some more looks at the different pipelines, and see what other great things can be done using them. Until next time, I wish you good coding.