Andreas Wijaya's Blog

In some cases we don't want to redirect the users to a 404 page only because the users typed in the url wrongly. In this case what we want is to show the 404 content but keep or preserve the url. This way they can correct the url without having to type it in from scratch. The way to do this in Sitecore is to execute some code before the OOTB RedirectOnItemNotFound code. Create a config patch: And that's it. HTH, Andreas

Hi, In order to achieve personalisation, sometimes triggering goal programmatically is necessary. The analytics API also provides a way to add tag to visitors. This is useful to differentiate between member types. Then the presentation components can be personalised based on the goal or the visitor tags. There you go. HTH, Andreas

Sitecore Workflow User warning: Today I did thorough testing on Workflow email. If you use the Workflow ContentHistory to get the submitting user like this as found on the web: http://blogs.perficient.com/digitaltransformation/2012/03/26/customizing-sitecore-workflow-emails/ It's a partial solution. It only works the first time approval is requested. Once the item is rejected, the last item in the history will be the approver (and not the submitter!). Using Statistics.UpdatedBy is more accurate since it will always be the user who edits the item. As to get the approver - this is not available as last history item nor the Statistics.UpdatedBy - just use the approver distribution email in the to field. HTH, Andreas

Hi all, When duplicating or copying an item in Sitecore, all the versions are copied to the new item as well. Sometimes this is unwanted behaviour, especially when the first version of the item was not part of the workflow. When you publish the item, the latest published state would be published (i.e. the non-workflow version) A simple trick is to remove the previous versions of the item when duplicating or copying item. This is done by intercepting the uiCopyItems and uiDuplicateItem. Note that for uiDuplicateItem, the Sitecore.Buckets.config aborts the pipeline before the original duplicate pipeline. To avoid this, we make sure our custom pipeline is triggered first before the bucket config. Custom config patch: Sitecore.buckets.config: Then we have a Sitecore extension helper to remove the previous versions: DuplicateItem class: CopyItem class: And that's it. Note that I applied this to Sitecore 7.2 Update 5 HTH, Andreas