4

I have a scenario where I need to modify a certain value of an item when it is created (not saved) off a particular template. In order to do that I tapped into the item:created event, however I noticed that I cannot read any of the field values in this event (even with item.ReadAll()), however on the item:saved event I can. So what should I use and why cant I read any value on the item:created event?

  • You can use the item:added event. This event is fired for every field of that item. – adarsh Jul 13 '17 at 6:51
  • The item:added and item:created events seem similar, but Sitecore only fires item:added when a user creates an item through the UI, but it fires fires item:created when code creates items through APIs. Use item:added if you only need to trap manual item additions. stackoverflow.com/questions/13279060/… – Thomas Bæk Jul 13 '17 at 7:04
6

The item:created event will come too soon as the fields will not be populated yet (as you have noticed).

The item:saved event will do the trick, but created overhead as it is called on every save (so it works, but you really don't want to take that hit).

There is an item:added event that could help. I've used this one before and it works, but apparently only when added through the UI and not when added with the api (don't know your requirements on this).

Another option, next to events, is using one of the pipelines. I would take a look a the AddFromTemplate pipeline as that seems to be a very good match to your requirement. Zachary wrote a nice blog on it: http://zacharykniebel.com/blog/sitecore/2016/march/30/using-sitecores-new-addfromtemplate-item-provider-pipeline in which he states:

The <addFromTemplate> pipeline differs from the <uiAddFromTemplate> pipeline in that the <addFromTemplate> pipeline is run whenever an item is added, regardless of whether it is added programmatically or from the UI.

You should use the <addFromTemplate> pipeline when you want to execute custom code whenever an item is created. Note that this is also the best option if you want to run custom logic whenever an item is created from a specific or nonspecific branch template.

|improve this answer|||||
  • 2
    You beat me to it :) I'm all about using the <addFromTemplate> pipeline. It's faster, and you're guaranteed to have all of the data for the item that you need: populated fields, branch template (sometimes called "master"), etc. – Zachary Kniebel Jul 13 '17 at 14:15
  • I actually considered pipelines initially, but then I saw recommendations asking to use pipelines only if user interaction is necessary? – tmp dev Jul 13 '17 at 22:24
  • I don't see any connection between pipelines and user interaction - no idea where that recommendation would come from.. – Gatogordo Jul 14 '17 at 8:06
1

Hope the below details help you understand item:Created,item:added,item:Saved and item:saving, .

  1. item:added and item:created • These events seem similar, but Sitecore only fires item:added when a user creates an item through the UI. • It fires item:created when code creates items through APIs. • Use item:added if you only need to trap manual item additions.

  2. item:saved and item:saving • Sitecore fires item:saved in either case(item:added and item:created), Using item:saved lets me put all the logic in a single handler, which fires after create, update, rename, move and potentially other events. • item:saving event before committing the change, while it raises the item:saved event afterwards. An advantage of using the item:saving event as opposed to the item:saved event is that you can access the values from the item before the save, and the new values, and can prevent the user from saving their changes.

|improve this answer|||||
0

If it is only on created you need to modify an item, I would not recommend using item:saved. However have a look at item:versionAdded. At this point your item should be populated with field values and you should be able to read and change it.

|improve this answer|||||
  • I agree with you that item:saved should be avoided in this case, but can you add some details explaining why to your post? It will make the answer far more useful for the OP and future readers. – Zachary Kniebel Jul 13 '17 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.