Attach WCF services to Sitecore context

As you know, any stand-alone .NET resource such as ASPX webform or web service can be associated with a Sitecore context. With this in place, will be able to access all nice stuff from Sitecore.Context such as "ContentDatabase", "Domain", etc.

In order to do that, you can just drop the resource into one of the folders referenced by a site definition in the <sites> section.
For example, if your stand-alone resource is working with the back-end, "modules_shell" would be the best option:

<site name="modules_shell" virtualFolder="/sitecore modules/shell" physicalFolder="/sitecore modules/shell" rootPath="/sitecore/content" startItem="/home" language="en" database="core" domain="sitecore" content="master" enableWorkflow="true" />

As you can see, the "modules_shell" site is referencing the "/sitecore modules/shell" folder, so this would be the location for your resource.

It works great for aspx and asmx resources but fails for a WCF service that you may be using.
The reason for that is the FilterUrlExtensions processor in preprocessRequest pipeline that does not allow SVC extensions through. If you simply adjust the value of the first "allowed extensions"  parameter as it is shown below, your WCF service will be able to access Sitecore context:

<processor type="Sitecore.Pipelines.PreprocessRequest.FilterUrlExtensions, Sitecore.Kernel">

   <param desc="Allowed extensions (comma separated)">aspx, ashx, asmx, svc</param>

   <param desc="Blocked extensions (comma separated)">*</param>

   <param desc="Blocked extensions that stream files (comma separated)">*</param>

   <param desc="Blocked extensions that do not stream files (comma separated)"></param>

</processor>

Note, there are two processors with the same class name in web.config so don't confuse it with the one defined in the httpRequestBegin pipeline.

How to completely disable Lucene index

Why? As Alexey was blogging some time ago, for the dev machines and even production content delivery environments, it may make a lot of sense to disable the out-of-the-box search engine that Sitecore ships with. This may improve performance and reduce number of folders in Sitecore installation as you will be able to simply remove the whole "indexes" folder.

Read more »

Latest updates for version 6 and 5.3

We pushed two updates yesterday for both major releases of CMS product.

The list of issues addressed in the latest update for version 6 (6.0.1) is impressive. A couple of them related to proxies and the one for CryptographicException seems to be addressing the need for step #7 in my guideline for Windows Authentication.

The update for 5.3.2 release shows the continuous support of the installations that were not upgraded yet ;-)

AD some speed

Today a new build of Active Directory module came out with a lot of improvements and tweaks targeting performance. If you have this guy installed, highly recommend to update your installations!

Friday Catch: Page Editor Not Yet Available

You may be getting this message in Page Editor after clicking any of the top bar buttons (Edit, Design, Log off).

In my case it is caused by the System.Web.UI.WebControls.ImageButton control's PostBackUrl property which I am assigning in code behind.

It appears that any control with that property assigned and used such as asp:LinkButton, asp:Button cause this problem on SR-1 installations and presumably earlier too.

To workaround it, I added a check for IsPageEditor in my control:

if (!Sitecore.Context.PageMode.IsPageEditor)

{

imageButton.PostBackUrl ="/mypage.aspx";

}

Works as temp workarond, the tech support will be investigating further.