IIS 7.5 Logging with Sitecore 6.x in Integrated Pipeline Mode

by aboo bolaky 4. December 2010 21:48

When you run Sitecore 6.x in Integrated Pipeline Mode, You will notice that ALL IIS log entries contain the log entry for the resquest to the layout (aspx) page (instead of the actual sitecore item .e.g /ContactUs.aspx).

This problem is partly related to another issue outlined on Stack Overflow  [http://stackoverflow.com/questions/353541/iis7-rewritepath-and-iis-log-files]

If you run Sitecore in Classic Mode, the problem disappears. However, if you still wish to use Integrated Pipeline Mode, you will have to intercept the request  before the Sitecore HttpModule (Sitecore.Nexus.dll) gets involved.

Solution

Create a class that extends System.Web.IHttpModule  and  set the path back to the original value after the request has been processed but before the IIS logging module writes the log entry.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;

namespace Test
{
    public class RewritePath : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.BeginRequest += OnBeginRequest;
            context.LogRequest += OnEndRequest;
        }

        static void OnBeginRequest(object sender, EventArgs e)
        {
            var app = (HttpApplication)sender;
            app.Context.Items["OriginalPath"] = app.Context.Request.Path;
        }

        static void OnEndRequest(object sender, EventArgs e)
        {
            var app = (HttpApplication)sender;
            var originalPath = app.Context.Items["OriginalPath"] as string;
            if (originalPath != null)
            {
                app.Context.RewritePath(originalPath);
            }
        }

        public void Dispose()
        {

        }

    }
}

Locate the Modules Section (under system.webServer ..remember we’re running in Integrated Pipeline Mode) and plug the module in BEFORE the Sitecore Nexus HttpModule

 

Here's what's captured when everything is compiled and deployed

 

Thanks Sitecore Support.

Tags: ,

.Net | Applications | Sitecore | Tips & Tricks

Building extension-less Urls in Sitecore

by aboo bolaky 4. October 2009 08:55

Our goal here is to build a Sitecore solution having links without the .aspx extension.(although accessing a page with a .aspx extension should STILL work)

To start ,you need

  • A LOT OF PATIENCE
  • Helicon ISAPI Rewrite Lite (the free one). Since I'm usingWindows 7 RC1 x64bit, I'll need to download the x64 bit flavour of Helicon Lite
  • A test Sitecore Application .. I will be using the Sitecore Starter Kit [Sitecore Starter Kit 6.0.0 rev.090203] as an my starting point.  (installed on IIS 7).

Before I start on implementing the solution, a little bit of background info would, I guess, be quite useful.

AddAspxExtension in LinkManager

A potential solution is to change the value of AddAspxExtension from true (by default) to false. If you do change it to false, you will have to create a wildcard script map to the ASP.NET runtime. This causes IIS to intercept every request made against the web server. This includes requests for images, asp.net pages and HTML pages. Therefore, enabling a wildcard script map to ASP.NET does have performance implications. If you wish to find another way to use pages without .aspx extensions in Sitecore, please read further....

Sitecore Aliases

Aliases, in a nutshell, allow you to shorten the url of an item. For example, if your item is currently accessible via http://hostname/MyParentItem/MyChildItem.aspx, you can specify an alias of myChildItem, which will be a placeholder for the actual item as it is in the Sitecore tree. Hence, the url of the alias is http://hostname/MyChildItem.aspx. For SEO purposes, this allows us to surface items from deep down in the hierarchy right up to the site root.

Note:

  • Aliases do not work if you remove the .aspx extension
  • No matter how far your items are in the sitecore tree, an alias allows you to refer to it from the site root.

Step 1: Install and Configure Helicon ISAPI Rewrite Lite

Start by installing Helicon ISAPI Rewrite. This process is fairly straightforward. Since we are using the lite version,  our Regex entries will be placed in the global http.conf (located in the Lite version installation folder). The entries in my httpd.conf are as follow:-

RewriteEngine on
RewriteBase /
RewriteRule ^(sitecore.*)$ $1 [L]
RewriteRule ^([^\.\?]+)/?(\?.*)?$ /$1.aspx$2 [L]

 

Url Rewriting Rationale

Before a request is forwarded to Sitecore, the ISAPI module intercepts it.

Line 1: You NEED that ! This turns on the Helicon ISAPI Module

Line 2: Errr...This is self-explanatory..

Line 3: We don't need to chop off the .aspx when we are in Sitecore CMS. For this reason, we're basically telling the module to not do anything when a request has "sitecore" in it.

Line 4: This is the most important bit. This appends .aspx (and querystrings,if any) to requests and consequently forwards the resulting request to Sitecore. Two scenarios arise as a result of this.

 3.1 : Sitecore maps the request to an item in the database. The page gets displayed in the end.

 3.2 : Sitecore cannot find the item based on the url. You will either end up with the  Sitecore's "Item Not Found" page.

NB:

Before we go any further, I need to confess that I did modify the Starter Kit a little prior to this operation. Basically, when you load the starter kit, you are greeted with a dummy home Site, that has a nice layout and there is a link to the Actual Starter Site. I was tired of this as my home page, So, I changed the value of "startItem" [in the Sites Definition of website (in web.config)] from "/home" to "/Sample". In that way, when i hit the website, I will eventually land on the real starter site!. Also, by doing so, all my urls within the website will no longer contain "/sitecore/content/.." since the Start Item has changed.

Quick Test on Urls

Request : http://sitecorestarterkit/References.aspx  [OK]

Request : http://sitecorestarterkit/References  [OK]

Request : http://sitecorestarterkit/Services/Architectual-Services.aspx [OK]

Request : http://sitecorestarterkit/Services/Architectual-Services [OK]

Request : http://sitecorestarterkit/Sitecore/  [OK..CMS access]

It looks like we have a half-baked solution. Aliases will now work without the .aspx extension as well. The other bits that need to be considered are

1 : How to make sitecore controls (.e.g. sc:link etc..) aware that they should drop the ".aspx" extensions

2 : How does it all tie up together with .NET (user controls etc..)

Step 2: XSL Extensions (revised)

To follow up on custom solution, you will need to tell Sitecore to remove the ".aspx" when it renders urls (either via sc:link [xsl extensions] or c# code). For XSL Extensions, we need to disable the default implementation that Sitecore provides us with and roll out our own. Fortunately, it's very easy to do so. [Credits : Chris Wojciech ]

 

2.1 : Turn off the default XslHelper

<xslExtensions>
<!-- Changed from "On" to "Off" -->
<extension mode="off" type="Sitecore.Xml.Xsl.XslHelper, Sitecore.Kernel" 
	namespace="http://www.sitecore.net/sc" singleInstance="true" />
	......
</xslExtensions>

  

  

2.2 : Create your own XslHelper

 namespace Starterkit.Utils
 {
	 public class XslHelper : Sitecore.Xml.Xsl.XslHelper
	{
		public override string path(System.Xml.XPath.XPathNodeIterator iterator)
		{
			string path = base.path(iterator);
			string newPath = Regex.Replace(path, ".aspx", String.Empty, RegexOptions.IgnoreCase | RegexOptions.Compiled);
			return newPath;
		}
		public override string link(string fieldName, System.Xml.XPath.XPathNodeIterator iterator, string parameters)
		{
			string path = base.link(fieldName, iterator, parameters);
			string newPath = Regex.Replace(path, ".aspx", String.Empty, RegexOptions.IgnoreCase | RegexOptions.Compiled);
			return newPath;
		}
		public override string StartLink(System.Xml.XPath.XPathNodeIterator iterator, string parameters)
		{
			string path = base.StartLink(iterator, parameters);
			string newPath = Regex.Replace(path, ".aspx", String.Empty, RegexOptions.IgnoreCase | RegexOptions.Compiled);
			return newPath;
		}
 
	}
}

 

For each of those three methods, we're only replacing the .aspx with an empty string. To enable <sc:link/> to use our custom Xsl Helper, we need to add another entry to the <xslextensions> section

 

<xslExtensions>
	<!-- Changed from "On" to "Off" -->   
	<extension mode="off" type="Sitecore.Xml.Xsl.XslHelper, Sitecore.Kernel" 
	namespace="http://www.sitecore.net/sc" singleInstance="true" />  
	<extension mode="on" type="Starterkit.Utils.XslHelper, Starterkit.Utils"
	 namespace="http://www.sitecore.net/sc" singleInstance="true" />
	 ....... 
 </xslExtensions>
 

 

NEARLY THERE!!!. All the links (that are rendering using sc:link) have now lost the .aspx extensions on the front end.

Step 3 : Sitecore and .NET interaction (with Url Rewriting)

If you have a Sitecore solution built using XSLT renderings only (highly unlikely though..), you're kinda safe here. However, if you have usercontrols (that host controls that can cause a postback) as well (for argument's sake, a contact us form), you end up with one issue.

Let's create a Contact Us form and add it to the presentation of the Contact Us item in Sitecore

 

User Control Designer

 <%@ Control Language="c#" AutoEventWireup="true"
 TargetSchema="http://schemas.microsoft.com/intellisense/ie5" 
 Inherits="Layouts.Contactus.ContactusSublayout"
 Codebehind="~/layouts/Starter Kit/Sublayouts/ContactUs.ascx.cs" %>
 
 <asp:Label Text="First Name : "  AssociatedControlID="txtFirstName" runat="server" />
 <asp:TextBox ID="txtFirstName" runat="server" />
 <asp:Label Text="First Name : "  AssociatedControlID="txtFirstName" runat="server" /> 
 <asp:TextBox ID="TextBox1" runat="server" />
 <asp:Button ID="btnSend" Text="Send" runat="server" />
  
   

 

Page Source

 <form name="mainform" method="post"
 action="/Contact.aspx" id="mainform">
 


To solve this, you will need to create a Control Adapter for the Forms in your application. Control Adapters allow you to inject custom code within the rendering of a control.

 

Form Control Adapter

namespace Starterkit.Utils
{
	public class FormActionRewriter : System.Web.UI.Adapters.ControlAdapter
	{
		protected override void Render(System.Web.UI.HtmlTextWriter writer)
		{
			base.Render(new RewriteFormHtmlTextWriter(writer));
		}
  	}
	class RewriteFormHtmlTextWriter : HtmlTextWriter
	{
		public RewriteFormHtmlTextWriter(HtmlTextWriter writer)
			: base(writer)
		{
			this.InnerWriter = writer.InnerWriter;
		}
 		public RewriteFormHtmlTextWriter(System.IO.TextWriter writer)
			: base(writer)
		{
			base.InnerWriter = writer;
		}
		public override void WriteAttribute(string name, string value, bool fEncode)
		{
 			if ((name == "action"))
			{
				HttpContext Context = null;
				Context = HttpContext.Current;
 
				if (Context.Items["ActionAlreadyWritten"] == null)
				{
					if ((!Context.Request.RawUrl.Contains("sitecore")))
					{   //remove .aspx extension if we're on the front end
						value = Regex.Replace(Context.Request.RawUrl, ".aspx", String.Empty, RegexOptions.IgnoreCase | RegexOptions.Compiled);
						Context.Items["ActionAlreadyWritten"] = true;
					}
				}
 			}
			base.WriteAttribute(name, value, fEncode);
		}
	}
}

Add Form Control Adapter in Solution

Open the form.browser (located in ~/App_Browsers) and add the new entry

<browsers> 
	<browser refID="Default">
		<controlAdapters>    
			<adapter controlType="System.Web.UI.HtmlControls.HtmlForm" 
			adapterType="Sitecore.Web.FormAdapter, Sitecore.Kernel" />  
			<!--Added--> 
			<adapter controlType="System.Web.UI.HtmlControls.HtmlForm"
			adapterType="Starterkit.Utils.FormActionRewriter, Starterkit.Utils" />    
		</controlAdapters> 
	</browser>
</browsers>

THIS IS IT!!!

<form name="mainform" method="post"
 action="/Contact" id="mainform">

 

RESULT !!! .... Back to Sitecore :)

Tags: ,

.Net | Applications | Sitecore

Cross Browser testing using SuperPreview for Internet Explorer

by Aboo Bolaky 24. September 2009 07:52

Let's face it. Although I'm no designer, I do feel sorry for my fellow colleagues when I hear them complain about the rendering on some specific browser(s).

It gets harder when testing against IE6 for example. They normally use IE6 VMs to perform testing.  There are three major drawbacks of this approach:

1: WHERE IS THE IE6 VM? Is it on the local machine? Is it on the network? Is it on a Virtual Server that no one has admin rights to? Does the IE6 VM have a meaningful name .. Imagine having 10 VMs locally and having to boot each one to see if IE6 is present !!

2: Loss of password for Logging into VM. (just because the last person who logged in just decided to change the "usual" password to his/her cat's name and not telling anyone about it..and he/she is most propbably off sick when we need to do testing)

3: VM gets copied across network onto physical machine. Transfering 6-10 GB to your computer and hosting the VM locally. Another designer comes along and does the same thing. We now have 2 VMs on 2 different machines that serve the same purpose. Let's not entertain the idea of having both VMs running simultaneously !! A whole range of IP Address/Name resolution conflicts arise. :)

Microsoft Expression Web SuperPreview for Windows Internet Explorer

This tool allows us to view a page in different IE versions. This eliminates the use of glorious VMs for testing. Well done Microsoft !

You can download Microsoft Expression Web SuperPreview for Windows Internet Explorer here

Description

"Expression Web SuperPreview for Internet Explorer is a stand-alone visual debugging tool that makes it faster and easier to migrate your sites from Internet Explorer 6 to Internet Explorer 7 or 8. With Expression Web SuperPreview for Internet Explorer, you can ensure that your Web sites work correctly in Internet Explorer 8 while also maintaining compatibility with earlier versions of Internet Explorer.

Expression Web SuperPreview for Internet Explorer shows your web pages rendered in Internet Explorer 6 and either Internet Explorer 7 or Internet Explorer 8, depending on which version you have installed on your machine. You can view the pages side by side or as an onion-skin overlay and use rulers, guides and zoom/pan tools to precisely identify differences in layout. You can even compare your page comp to how the targeted browsers render the page.

Expression Web SuperPreview for Internet Explorer not only shows a high-fidelity rendering of how pages will look on different browsers, but it also identifies the element's tag, size and position, applied styles, and location in the DOM (Document Object Model) tree so you can quickly fix the error. "

Expression Web SuperPreview for Internet Explorer is a standalone, free application with no expiration and no technical support from Microsoft. 

Note:

If you wish to have the ability to debug pages both in IE and Firefox flavours in a single application, go for Microsoft Expression Web. You can download a 60-day trial copy here

 

Tags: ,

.Net | Applications | Freebies

SEO Friendly Urls in Sitecore -Remove spaces in Url (3)

by aboo bolaky 11. August 2009 06:33

It's the third time I'm writing on this particular topic (The EncodeNameReplacements element in the web.config). Articles 1 and 2  have had their importance in building SEO-friendly links in Sitecore.

Double Encoding in Urls

Whilst doing some routine administrative tasks in sitecore, I noticed that some links were no longer working. I was pretty sure that those links were working before I did a publish. :( Back to the drawing board.

As outlined in Articles 1 and 2, I was using

<replace mode="on" find=" " replaceWith="-" />

in my web.config. It was working fine when sitecore items were having names like "Camera one" (->url: camera-one.aspx), "Camera one two three" (->url: camera-one-two-three.aspx) etc...

However, if an item name has a character that has already been defined in my EncodeNamesReplacements section, Sitecore throws you back on the Item Not Found page. In my situation, I had renamed the Sitecore Item :"John Doe" to "John-Doe" (lame administrative task...I KNOW) . The effect of this is that when the user clicks on the John-Doe.aspx, he/she is redirected to the default "Item Not Found" sitecore page. A careful look at the url has revealed that Sitecore was trying to request an item with a name of John--Doe and consequently failed.

Solution

or hack (for some people)

If you are using a specific character to get rid of spaces in url, you need to make sure that a cms user will not be able to create an item name having that character in. Easy way to factor this in is to include your character in the InvalidItemNameChars element in the web.config. In my implementation, I've changed that setting to :

<setting name="InvalidItemNameChars"
	value="\/:?&quot;&lt;&gt;|[]-/>

 

and that did the trick :)

Tags: ,

.Net | Applications | Sitecore

Implementing Sitecore Extranet login on a website

by aboo bolaky 30. July 2009 08:02

Here's the situation. You are about to implement a password protected area on your website. Let's assume that the general site structure looks like this

Pages below General and Products are accessible to everyone, whereas pages under Members should only be visible to authenticated/logged in members. I will first briefly outline the steps required to get this problem implemented using ASP.NET. Later on, I'll move onto it's equivalent Sitecore Solution.

Using ASP.NET

  • Implement Forms Authentication and set login url in the web.config.
  • Implement Login control and decide where to retrieve and store login credentials (in web.config or database)
  • In the web.config, add a Location Path pointing to the Members folder (Deny anonymous , allow authenticated users )
  • This is all about it really...(as far as I remember..) ...

In Sitecore, it's a different ball game.

In addition to adding the loginURL to the form authentication section (important if you use the loginview control to show the login page), you will need to  add the  "loginPage" attribute to the site which is defined by your extranet domain (normally, it's called "website" )

	
<sites>
 .....
	<site name="website" virtualFolder="/" physicalFolder="/" 
		loginPage="/General/Login.aspx"
  ....
</sites>

 

The LoginPage attribute is not something new here..It has always been there..(e.g. the shell website has already a loginPage set), but i did not know what was its purpose . Thanks to Chris Wojciech, I've discovered how to use this existing functionality in the web application.

The addition of Location path in the asp.net-only model is analogous to denying read access to the Members folder (+descendants) in Sitecore.

 

Once you perform a site publish, you can see the effects straight away.

If you've already signed in, you will be able to view /Members/View My Account.aspx.

If you're an anonymous user and access  /Members/View My Account.aspx, you will be presented with a default page that Sitecore serves in case access is denied due to security privileges.

http://mywebapp/sitecore/service/noaccess.aspx?item=%2fmembers%2fview+my+account&user=extranet%5cAnonymous&site=website

 

Quick Fix :

The page served in this case is called noaccess.aspx. The good thing is that this can be altered by changing the value of the "NoAccessUrl" attribute in the web.config.

If we set  "NoAccessUrl" to "/General/Login.aspx", we end up in this situation

http://mywebapp/general/login.aspx?item=%2fmembers%2fview+my+account&user=extranet%5cAnonymous&site=website

 

Recommended Solution

The nag in the above quick fix is that sitecore internally adds 3 QueryStrings to the url ( item, user and site). If we compare this to the normal ASP.NET solution, we would have ended up with only 1 querystring, which is the ReturnUrl.  Our goal is to follow the asp.net solution as close as possible. This is where Chris comes in..

Rolling out your own Security Resolver

Chris extended the HttpRequestProcessor class in order to intercept the request ,check if the user requesting the sitecore item has appropriate rights. If that is not the case, the user is redirected to the login page, with the appropriate ReturnUrl QueryString. Please go check the code out on his blog at http://blog.wojciech.org/?p=64 

The processor should then be plugged in the web.config, before the definition of the ExecuteRequest processor.

 

<processor type="Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel"/>
<processor type="Sitecore.Pipelines.HttpRequest.LayoutResolver, Sitecore.Kernel"/>
<processor type="MyWebApp.Pipelines.MyOwnSecurityResolver, MyWebApp"/>
<processor type="Sitecore.Pipelines.HttpRequest.ExecuteRequest, Sitecore.Kernel"/>

 

If you now try to access a protected page as an anonymous user, you'll end up on the login page (but this time, the ReturnUrl parameter has replaced the 3 built-in sitecore url parameters)

http://mywebapp/general/login.aspx?returnUrl=/members/view%20my%20account.aspx

Result :)

Tags: ,

.Net | Applications | Sitecore

LoginView control not working when logging out from Sitecore extranet domain

by aboo bolaky 29. July 2009 06:19

Let's not re-invent the wheel and make use of the ASP.NET 2.0 LoginView control to generate Login/Logout actions for the Sitecore extranet domain.

We have our LoginView control (very simplistic example given here) in a sublayout.

<asp:LoginView ID="loginView" runat="server">
	<AnonymousTemplate>
	  Welcome Guest <asp:LoginStatus runat="server" LoginText="Login" />
	</AnonymousTemplate>
        
	<LoggedInTemplate>
	  Welcome <%= Sitecore.Context.User.Name %>.
	  <asp:LoginStatus runat="server" LogoutText="Logout"
	   LogoutPageUrl="/" LoginText="Login" LogoutAction="Redirect" />
	</LoggedInTemplate>
</asp:LoginView>

LoginView Control Caveat

The LoginView control "magically" knows the login page url. This is specified by the LoginUrl attribute in the FormsAuthentication section of the web.config. This is not to be confused the LoginPage attribute (from the sites section). I had to modify my web.config to

 <authentication mode="Forms">
   <forms name=".ASPXAUTH" cookieless="UseCookies" 
		loginUrl="~/General/Login.aspx" />
 </authentication>

Erractic Behaviour when logging out

I did not experience any problems when logging in .i.e. the control did what is was supposed to do (display sitecore username and Logout Link). HOWEVER, when I pressed the Logout link, I always got redirected the Sitecore Layout page instead. I did spot similar behaviour with ListViews in Sitecore (also documented by Paul George and Mark Cassidy, where its events were not being fired at all. I've made the following change to my web.config and that solved the problem :)

<typesThatShouldNotBeExpanded>
   <type>System.Web.UI.WebControls.Repeater>/type>
   <type>System.Web.UI.WebControls.DataList>/type>
   <type>System.Web.UI.WebControls.LoginView>/type>
</typesThatShouldNotBeExpanded>

 

A similar problem that relates to the  typesThatShouldNotBeExpanded tag has also been documented on SDN

Tags: ,

.Net | Applications | Sitecore

Automatic Publishing in Sitecore

by aboo bolaky 26. July 2009 07:02

Sitecore DOES support Automatic Publishing. However, there are not many instances where you would want Sitecore to automatically perform a publish.

The values to change reside in the web.config, right where you have definitions for the scheduling and agents

<agent type="Sitecore.Tasks.PublishAgent" method="Run" interval="00:00:00">
	<param desc="source database">master</param>
	<param desc="target database">web</param>
	<param desc="mode (full or incremental)">incremental</param>
	<param desc="languages">en, da</param>
</agent>

 

I guess that a value of "00:00:00" for the interval attribute does disable automatic publishing. If you set the value to (say..10 minutes) "00:10:00", you will notice that after 10 minutes or so, changed items from the master database will be copied over to the web database.

Automatic publishing is useful where you have integrated external datasources in sitecore (using Data Providers) and where there needs to be a predefined process that synchs the external data to the web database. For the automatic publishing to work in this particular situation, you must have had created a new database entry (with a reference to your data provider) in the web.config.

Sitecore Data Providers....hmmmmm...that's upcoming.... :)

Tags: ,

.Net | Applications | Sitecore

Programmatically skip publishing of item(s) in Sitecore

by aboo bolaky 23. July 2009 05:43

Scenario

Assume that you have a set of items (say..Product items) (sitting anywhere within the /sitecore/content..) based on a specific template. The requirement here is that

"A Product cannot be published if one of its fields (ProductID) isn't populated."

Background

To achieve this, we need to hook into the publish:itemProcessing event in the web.config. This event gets triggered every time an item is published. The general steps involved in this situation are:

  • Create a class with a method that adheres to the EventHandler delegate signature. Whenever you initiate a publish operation in sitecore (be it smart publish, incremental or full publish), the method will be called (depending on how many items that need to be published)
  • Modify the web.config to subscribe to ItemPublishing event

ItemPublisher Class

namespace Test.Events 
{
	public class ItemPublisher
	{
	   public void CheckProcessing(object sender, EventArgs args)
		{
		  ItemProcessingEventArgs theArgs = args as ItemProcessingEventArgs;
						
		  Item currentItem = theArgs.Context.PublishHelper.GetSourceItem(theArgs.Context.ItemId);

		  if ((currentItem != null) && (currentItem.Paths.IsContentItem))
		  {
			  //Template ID of item on which selective publishing is to be applied
			 if (currentItem.TemplateID == new ID("{9C9A2F3D-652A-4490-AB57-E9F1B4D5BF05}"))
			  {
				 Job currentJob = theArgs.Context.Job;
				 JobStatus currentJobStatus = currentJob.Status;

				 if (String.IsNullOrEmpty((currentItem.Fields["Product ID"].Value)))
				  {
					currentJobStatus.Messages.Add(String.Format("Item :{0} has not been published since it has no Product ID", currentItem.Name));
					theArgs.Cancel = true;
					return;
				   }
			  }
		   }
		}
	}
}


Line 7:
Cast the standard EventArgs class to ItemProcessingEvent. This is important since it gives you the possibility of retrieving details of the items being published.

Line 9: Retrieve the item being published.

Line 11: The check for "currentItem.Paths.IsContentItem" is important since we only want to check for content items. Since publishable items sitecore vary from templates,standard values, renderings... we do not want to check for the condition in ALL items.

Line 14: If the template of the current item matches the id of the Product template, then we're back in business.

Line 16 - 21: Find the reference to the current Job (and JobStatus)  being executed in the publish pipeline. If the item's field is empty, add a message to the JobStatus.

Line 22: Abort the publish operation of the current item. I don't think we require the return statement after that. Publishing will then resume for the next item in the publishing queue.

Web.Config Change

Locate the publish:itemProcessing event in the web.config. Hook up the new handler to the event.

<event name="publish:itemProcessing" 
help="Receives an argument of type ItemProcessingEventArgs (namespace: Sitecore.Publishing.Pipelines.PublishItem)" >
   <handler type="Test.Events.ItemPublisher,TestApplication" method="CheckProcessing" />
</event>

Let's put it to the test

That's all to it really. If you now  initiate a publish operation and one of the Products has an emtpy Product ID, you will end up with this (if you click on "Click here to see additional information" on the last screen of the publish wizard.)

Items Skipped = 1 (.i.e Camera item has been skipped during the publish process since it has no ProductID). If you switch to the web database, there will not be any "Camera" item. 

Result... :)

Tags: ,

.Net | Applications | Sitecore

The Sitecore Way

by Aboo Bolaky 9. July 2009 07:09

4 months since my last post. This should give you an idea of my hectic life as a software developer.  Build..Test.. Deploy.....Build..Test.. Deploy.. This seems to be the only thing that I have been doing lately and hasn't left me with any time to do anything else.

Things have got to change and NOW is the time :-)

Back in Febuary, I came accros a file (via some random Google Search about Sitecore) that outlined some good one-liners about building websites using Sitecore. At that time, I added the link to my favourites and didn't pay much attention to it. Now that I've accessed the link again (by mistake..), I realise that so many of those "guidelines" are correct. Unfortunately, I did not capture the author of the text file at that time. Here's the online version

The Sitecore Way

1) Think about the CMS users not just the Web site. The Sitecore Way.

2) Use XSLT to minimize code compilation for maintenance. The Sitecore Way.

3) Get better performance with ASP.NET user-controls.  The Sitecore Way.

4) Use an ASP.NET master for your layouts. The Sitecore Way.

5) Return Item ID for XSLT extension results. The Sitecore Way.

6) Avoid setting language in a request after the Sitecore pipeline. The Sitecore Way.

7) Use icons for your masters and templates. The Sitecore way.

8) Protect /sitecore as much as you can. The Sitecore way.

9) Cookieless is possible, but be careful. The Sitecore way.

10) It's very important to Organize the content structure correctly. The Sitecore Way.

11) Finalize design as much as you can before implementation. The Sitecore way.

12) Ask for design behavior specs not just content info. The Sitecore way.

13) Use file system for large files instead of media library. The Sitecore way.

14) Use source-control for new/changed files inside Sitecore. The Sitecore Way.

15) Please avoid inline C# code in XSLT. The Sitecore way.

16) Test renderings using the debugger ALWAYS. The Sitecore way.

17) Multi-site, multi-language, identify what the client needs. The Sitecore Way.

18) Globalization is easy with Sitecore...use it. The Sitecore way.

19) Create custom XAML apps for better experience. The Sitecore way.

20) Use Sitecore's security mechanism for other applications. The Sitecore way.

21) Be careful of data cache synchronization between two sites. The Sitecore way.

22) Remove default favico.ico or your client might yell at you. The Sitecore way.

23) To stage or not to stage. We say to stage. The Sitecore way.

24) Use Lucene.net if you can for site search...it's FREE. THe Sitecore way.

25) Disaster recovery plan: zipped Web site and DB backups.  The Sitecore way.

26) Minimize rendering URL parameters to keep an SEO-friendly site. The Sitecore way.

27) Dont' forget the robots.txt...just good Web practice. The Sitecore way.

28) Analyze secuirty by feature and content access. The Sitecore way.

29) Download the Enhanced Email Action, why not? The Sitecore way.

30) Content analysis should be a top priority. The Sitecore way.

31) Use nested templates but be careful. The Sitecore way.

32) Make life easy by using a sticky session load-balancer. The Sitecore way.

33) More than a CMS, it's an integration platform. The Sitecore way.

34) Get more value by integrating it with internal systems. The Sitecore way.

35) Deliver templates and masters early to  avoid content freeze. The Sitecore way.

36) Physical storage of data does not look like Sitecore XML. THe Sitecore way.

37) Ever used Sitecore Query to query the Sitecore XML?  It's cool. The Sitecore way.

38) Use the search in the Sitecore bar for a quick content search. The Sitecore way.

39) No gray desktop background or you might loose your cursor : ). THe Sitecore way.

40) Drag content items on the desktop to create a shortcut. The Sitecore Way.

Credits: Unknown Author

 

How many of these have you achieved????

 

Tags: ,

.Net | Applications | Sitecore | Tips & Tricks

Listview losing viewstate on postback in Sitecore V6

by Aboo Bolaky 21. February 2009 08:23

This post will most probably apply to the GridView and LoginView controls as well.

The Problem

Lets assume that you've successfully bound a listview to your datasource and configured all the properties on the listview to display the Select/Edit/Delete links. You then have the task to write the logic in the appropriate events of the usercontrol/sublayout. While I was implementing the Edit functionality, I implemented the OnItemCommand event of the Listview to display an Edit Panel with the data populated from the selected row. I was a bit suprised to see that the end result wasn't what I was expecting:

The Edit Panel shows up but the Listview has left the party.!!

The Frustration 

It dawned on me that, at some point, I must have messed up somewhere in the code.So, I began putting "EnableViewState=true" to every control.. (this shows how desperate I was!!). I also reverted to "AutoEventFireUp=false" (Originally, I was manually hooking up the events..).I tried databinding on every possible method I could lay my hands on!!. I lost confidence on the fact that this was a really easy task and yet, it was taking me hours to get to the bottom of the problem. I completely lost my mind....I began googling on the issue ["postback..losing viewstate"], I started to watch a few videos that demonstrate the functionality of the ListView..I even got the point where I created another item in Sitecore, assigned the same sublayout to the item's presentation and accessed the item using the url.. I ended up in the same situation.... I surrendered...I left the battlefield...wounded..!!![White flag..Sealed].

The Solution

I finally blamed it on Sitecore!! Who knows, maybe it was a known issue in one of their releases or maybe I just needed to upgrade to the latest stable release(090120). Out of desperation, I tried searching on the Forums and found that I wasn't the only one experiencing this issue.I came across this forum post. Thanks to Mark Cassidy, I eventually finished my task (It had taken me almost a day...and that had messed up (big time) on my initial estimate!!!)

The solution, as Mark outlined, is to add the type of the control (in my case, System.Web.UI.WebControls.ListView) to the typesThatShouldNotBeExpanded element in the web.config. Presumably, for the sake of consistency, you might also append the System.Web.UI.WebControls.Gridview to the list (in case your website makes use of one!!). From what I've read so far, no one knows about the purpose of the typesThatShouldNotBeExpanded element .!! {Sigh...Sitecore!! What did you do that to me????}

In hindsight, only laughs...Good Days...Good Times...

I hope this helps someone!!!

Back to Sitecore  ......

Tags:

.Net | Applications | Sitecore | Tips & Tricks

Tag cloud

Flash Player 9 required.

About Me

I wish I could write something here..
//TODO: ElaborateMe