Andreas Wijaya's Blog

Hi all, As you all know, scheduled publishing will not run automatically unless you enable PublishAgent task in Sitecore config. By default, all items that are in publish queue will get published when this task triggers. This includes all items in the final workflow state and all items that don't have workflows. Sometimes this is not what you want. Maybe you don't enable workflow on media items and you don't want the items to go live when they are not ready. The workaround is to create your own PublishAgent task. Looking at the one provided, we can easily extend the code to insert the RootItem to the PublishOptions (this only works with Full or Smart publish mode however): You will notice that on the Run method I check whether the server time is around the time I set in the parameter (thanks to this post for the code). This will enable us to run the task near the specific time we set (e.g. midnight). In the config patch, just add this to enable the custom agent...

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