For more information visit IE’s Blog

I’ll quickly list these below;

• Display Fusion
  This small little util makes working with multiply monitors a lot easier with some minor tweaks such as expanding the task bar to multiply monitors. You really need to look at this your self.
• Remote Desktop Manager
  This application isn’t just a replacement for RDP but allows you to connect to different protocols using one simple system. I would recommend it for any dev as it can do remote RDP through a VPN which you setup all in RDM so you don’t have to connect to the VPN and loose your internal network.
• IETester
  This is a must, you can use Virtual PC to do all your testing but sometimes you just need to quickly check this is your program.
• Notepad++
  This is a must it just works and you will never go back to the bad notepad
• WinMerge
  When you need to merge something or even compare directories this is your program.
• Teracopy
  This is a replacement for the bad windows copy, move etc. This allows pausing and resuming of copying files and is just quicker then the normal windows copy. A must have.
• UtiluMFC
  This is like IETester but has multiply version of Firefox
• Expresso
  This is for setting up regular expression for .net
• Linqpad
  For assisting with setting up linq statements

HttpRequest Pipeline Processor

This is where the AbortStaticFilesProcessor comes in, it allows the developers to plug this in and allow the static files of the system to be excluded from executing automatically.

So what do we need to do, firstly create a new class called “AbortStaticFilesProcessor” and inheritate from the “Sitecore.Pipelines.HttpRequestProcessor class.

Basically copy the code below;

    /// <summary>
    /// Aborts the static files from the processor, this also has an exclude list
    /// just incase we need to abort a certain file to have the security
    /// </summary>
    public class AbortStaticFilesProcessor : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
    {
        #region Private Static Variables
        /// <summary>
        /// The executed URLS
        /// </summary>
        private static System.Collections.Generic.Dictionary<string, bool> ExecutedURLs = new Dictionary<string, bool>();
        #endregion

        #region Private Variables
        /// <summary>
        /// The list of exclusions for static files
        /// </summary>
        private System.Collections.ArrayList _excludes = new System.Collections.ArrayList();

        /// <summary>
        /// The list of dynamic files to include in excluding pipeline calling
        /// </summary>
        private System.Collections.ArrayList _dynamicExclude = new System.Collections.ArrayList();
        #endregion

        #region Public Properties
        /// <summary>
        /// Adds the exclude item to the list
        /// </summary>
        /// <param name="exclude">The exclude path to add</param>
        public void AddExcludes(string exclude)
        {
            this._excludes.Add(exclude.ToLower());
        }

        /// <summary>
        /// Adds the dynamic exclude item to the list
        /// </summary>
        /// <param name="dynamicExclude">The dynamic exclude to add</param>
        public void AddDynamicExclude(string dynamicExclude)
        {
            this._dynamicExclude.Add(dynamicExclude.ToLower());
        }

        #endregion

        #region Process
        /// <summary>
        /// The initial processor which is used to access the data
        /// </summary>
        /// <param name="args">Sitecore Arguments for the http request</param>
        public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
        {
            // make sure we have our arguments before we have any issues
            Sitecore.Diagnostics.Assert.ArgumentNotNull(args, "args");

            // make sure we have data to actualy process
            if (args.Context != null
                && args.Context.Request != null
                && !string.IsNullOrEmpty(args.Context.Request.PhysicalPath)
                && !args.Context.Request.Path.StartsWith("/sitecore/")
                && !args.Context.Request.Path.StartsWith("/sitecore modules/"))
            {
                // detects if the file is static
                using (new Sitecore.Diagnostics.ProfileSection("Static File Detection."))
                {
                    // setup defaults
                    bool killPipeline = false;
                    string cacheKey = args.Context.Request.Url.PathAndQuery;

                    // has this already been executed
                    if (ExecutedURLs.ContainsKey(cacheKey))
                    {
                        // gets out the key
                        ExecutedURLs.TryGetValue(cacheKey, out killPipeline);
                    }
                    else
                    {
                        // do we need to abort the execution
                        System.IO.FileInfo file = new System.IO.FileInfo(args.Context.Request.PhysicalPath);

                        // does the file exist
                        if (file.Exists)
                        {
                            // we want to kill the pipeline
                            killPipeline = true;

                            // do we have any extensions to check
                            if (this._excludes != null && this._excludes.Count > 0)
                            {
                                // we need to only deliver actual files instead of fake data
                                if (this._excludes.Contains(args.Context.Request.Path.ToLower()))
                                {
                                    killPipeline = false;
                                }
                            }
                        }
                        else
                        {
                            // is the file part of the dynamic exclude
                            if (this._dynamicExclude.Contains(args.Context.Request.Path.ToLower()))
                            {
                                // kill the pipeline
                                killPipeline = true;
                            }
                        }

                        // append the executed url
                        ExecutedURLs.Add(args.Context.Request.Url.PathAndQuery, killPipeline);
                        Sitecore.Diagnostics.Log.Debug(string.Format("AbortStaticFile: URL:'{0}', AbortProcessing:'{1}'", args.Context.Request.Url.PathAndQuery, killPipeline), typeof(AbortStaticFilesProcessor));
                    }

                    // kill the pipeline
                    if (killPipeline)
                    {
                        // kill the pipeline
                        args.AbortPipeline();

                        return;
                    }
                }
            }
        }
        #endregion
    }

This code needs to run as soon as possible so we can abort the pipeline to stop the following pipeline items from executing, we also remember what files have been executed to determine if they required the pipeline to be aborted or not for extra speed and reduced processing. Additionally a DEBUG log is added for any new requests not previously executed so you can always see what’s happening if there are any URLS not being requested correctly.

Config Settings

Next we have to include our HttpRequestBegin processor to the pipeline, but as im a comment freak I’ve also commented this quite heavily as well (soz if you don’t like comments);

        <!--
        Abort Static File Processor
        ************************************************************************
        Description:
          This processor aborts the httpRequestBeing pipeline when static files are executed.
          This performs checks on the file to make sure it's actually found but also it
          undertakes various checks with the exclude list.

          The exclude list allows developers to input the list of excluded files which are static
          files but need to be run through the sitecore pipeline such as the /default.aspx file.
          The "desc" is required to work with 6.4 but isn't needed for 6.4.1 which is a known bug.
        Example:
            <processor ..>
              <excludelist hint="list:AddExcludes">
                <file desc="default sitecore file">/default.aspx</file>
                <file desc="some calling json">/json-handler.ashx</file>
                <file desc="checks stuff">/remote-check.ashx</file>
              </excludelist>
              <dynamicfiles hint="list:AddDynamicExclude">
                <file desc="the defautl script resource">/scriptresource.axd</file>
                <file desc="the defautl web resoruce">/webresource.axd</file>
              </dynamicfiles>
            </processor>
        -->
        <processor patch:before="*[@type='Sitecore.Pipelines.PreprocessRequest.CheckIgnoreFlag, Sitecore.Kernel']"
          type="Test.AbortStaticFilesProcessor, Test">
          <excludelist hint="list:AddExcludes">
            <file desc="default sitecore file">/default.aspx</file>
            <file desc="json handler">/json-handler.ashx</file>
          </excludelist>
          <dynamicfiles hint="list:AddDynamicExclude">
            <file desc="the defautl script resource">/scriptresource.axd</file>
            <file desc="the defautl web resoruce">/webresource.axd</file>
          </dynamicfiles>
        </processor>

You will need to make the changes to the <processor patch:before=”..” type=”Test.AbortStaticFileProcessor, Test“> to put in the correct Assembly and Namespace.

Also you will notice the “patch:before”, if you don’t know what this is you should have a quick search on the net, but you can use this in external config files which are located in the app_config/include folder, this is how most of the new modules work these days and what I see it’s a lot easier to have it here then to try and remember what changes where done in the web.config file. NOTE: This is only for the <sitecore> node only.

What we have are two main lists that have to be used;

ExcludeList

This list is where the files, handlers etc are listed which need to be processed by Sitecore, we take a policy that we exclude everything unless it in this list including the default.aspx which Sitecore needs.

You will see that below the excludelist you have a collection of “file” nodes, these have the “Desc” attribute, this is required only for 6.4 as it’s a known bug but has been resolved in 6.4.1. The file location needs to be a relative path from the root location and requires the “/” at the start.

DynamicFiles

This list is where the dynamically bound resources such as .axd files are placed, you shouldn’t have to make any changes to this but it’s listed here just in case, the same sort of rules apply for this just like the excludelist.

Does this improve speed

Well to put it simply YES, it stops Sitecore from executing these files quite high up in the pipeline and once the request file has been processed by this pipeline processor the system remembers this and will stop and allow this execution without having to determine if it’s a file, exclude, dynamic etc.

Give it a play and see what you think.

Thanks to Sitecore 6.4 now working within Firefox.

What i did to resolve the issue was;

• Open Firefox
• Open Sitecore and login as admin in Desktop user
• Open your Sitecore Control Panel (sitecore bar/control panel)
• Preferences
• Change your application preferences
• Make sure “Fields from the Standard Template” is off and click ok
• No open the “Content Editor”
• Click on the “Home” item (default one supplied by Sitecore)
• Click Presentation tab
• Hit “Reset” in ribbon and continue
• Now Click on another item somewhere even “Content”
• Click “View” from ribbon and enable “Standard Fields”
• Now click on the “home” item and it should now load

What the issue seems to be is a reference to a layout, rendering, sublayout etc.
Hope this helps someone.

PS: This is a very very quick wiki article so don’t mind my rushing

So what do you need to do firstly;

1. Setup your new empty Sitecore site and test that you get the default homepage
2. Mirge your previous web.config file with Sitecores and any other configuration files
3. Copy over your existing DLL files and other flat files such as aspx, ascx etc
4. Make sure you have setup your IIS to work correctly with sitecore, that means any new changes etc
5. Test the site

What you will notice that when you load up you’ll see the Sitecore test home page. But if you call a different url to access another page such as http://site/about.aspx you will get your page, test that most work and we will get back to the homepage soon.

From what i’ve seen there are actually two main things you have to work out and these are listed below;

• Homepage doesn’t load my custom homepage
• Previous URLRewriting rules don’t work

Fixing the Homepage to point to your custom page
This isn’t a bug in sitecore, but sitecore is stopping the system from loading up the correct default.aspx etc. To resolve this you need to create a small little httpRequestBegin processor which is done below;

/// <summary>
/// Default Override Resolver used to make sure default.aspx is actually fired instead of using Sitecores
/// default page.
/// </summary>
public class DefaultOverrideResolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
/// <summary>
/// The proces using to use
/// </summary>
/// <param name=”args”></param>
public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
{
// make sure we have the data we want
Sitecore.Diagnostics.Assert.ArgumentNotNull(args, “args”);

// get the site to make sure we have the correct data
Sitecore.Sites.SiteContext site = Sitecore.Context.Site;
string filePath = args.Url.FilePath;

if (Sitecore.Context.Site.Name.ToLower() == “website” && args.LocalPath == “/default”)
{
Sitecore.Context.Page.FilePath = filePath;
Sitecore.Context.Item = null;
}
}
}

What this processor does is quite simple, it gets the file which is being requests well trying to be requested and then checks to see if it’s the default “website” site and the “default” page. If this is the page and site then don’t get the home item (sets it to null) and reset the Sitecore Filepath as the default page.

But for this to work you need to place it in the correct position so where;

<httpRequestBegin>
<processor type=”Sitecore.Pipelines.HttpRequest.DefaultResolver, Sitecore.Kernel” />
… INSERT PROCESSOR HERE …
<processor type=”Sitecore.Pipelines.HttpRequest.FileResolver, Sitecore.Kernel” /
</httpRequestBegin>

Save the configuration and build etc, then try and run the homepage now, you should see your custom homepage now.

As for the custom urlrewriting, this you’ll have to tackle on your own, the reason for this is that there are lots and lots of rewriting modules/custom modules/global.ascx methods out there and most of the time if your embedding siteecore into your existing site you have created your own custom rules and code to do this in which you’ll have to spend the time changing and working with. Also if that is the case it might be quicker to just use the IISREwrite module for IIS7.

Well with Sitecore it’s not as difficult as you would think

Firstly in our XSLT we need to make sure we disable the security before we actually make our selection of items (this is just a quick display of data).

<sc:disableSecurity>
<xsl:for-each select=”*”>
<div>
<xsl:value-of select=”@name”/>
</div>
</xsl:for-each>
</sc:disableSecurity>

Now we are displaying the items no matter what user we user, that being the anon user or a logged in user, great but what about displaying my little pad locks. For this we need to get a little bit creative and read the security field from the Sitecore item (“__Security” field). But for us to work with it we need to make sure we only get that user as well as the user can’t read the item we’re processing. Below is the code to undertake this;

<sc:disableSecurity>
<xsl:for-each select=”*”>
<div>

<xsl:apply-templates select=”sc:SplitFieldValue(‘__Security’, ‘\’, .)” mode=”secure”/>

<xsl:value-of select=”@name”/>
</div>
</xsl:for-each>
</sc:disableSecurity>

<!–==============================================================–>
<!– secure : determines if the field is secure                   –>
<!–==============================================================–>
<xsl:template match=”*” mode=”secure”>
<xsl:if test=”contains(.,’Anonymous|pd|’) and contains(.,’-item:read’)”>
<xsl:attribute name=”class”>
<xsl:value-of select=”‘titleIconPadlock’”/>
</xsl:attribute>
</xsl:if>
</xsl:template>

So what this gives us is a way to render our navigation with a mixture of secure and non-secure items and indicate to the user what pages they have access to.

Hope this helps someone.

PS: You could also undertake this in an XSLT Extension but this is a simple XSLT implementation.

So what have we got firstly when you deploy you get a site that well has no compression enabled nor is the site caching the site you’ve just deployed. What this does is cause the system to be well slower for a user to browse as well as download.

So what can you do to quickly speed this up with just a few configuration settings in the web.config;

• enable compression
• enable caching
• use a CDN
• use some basic tools to see why your site is dam slow

This blog doesn’t tell you all about azure, caching, compression etc it will assume you know what these are. If you do have trouble just do a google search for the data and see what im talking about.

Tools

For this i use all Firefox plugins;

• Firebug
• YSlow
• Page Speed

CDN

For this you want to make sure to use a CDN for all your Javascript files if possible;

• For jQuery use the google CDN as it’s the most heavily used. Just look at some of the top 100 sites in the world, they use google as there CDN
• For ASP.NET and you run .net 4.0 you can set your ScriptManager to use Microsofts CDN by just enabling it on the ScriptManager control;
  • Set on the ScriptManager the EnableCdn property to “true”, EG: EnableCdn=”true”

Compression

To enable compression you need to set this on the web.config file this is basically what i use;

<urlCompression doStaticCompression=”true” doDynamicCompression=”true” dynamicCompressionBeforeCache=”true” />

What this does is allow static compression of JS and CSS files, Compresses the dynamic files such as aspx, json etc but we also have the property dynamicCompressionBeforeCache set to true. This allows the system to fetch the dynamic page before it’s sent into the cache, this also requires you to make sure that the cache settings have been setup correct

Caching

To cache you have to enable this from the web.config file just like the compression for this i use the following;

<caching>
<profiles>
<add extension=”.aspx” policy=”CacheUntilChange” kernelCachePolicy=”DontCache” duration=”00:00:30″ varyByHeaders=”User-Agent” />
<add extension=”.axd” policy=”CacheUntilChange” kernelCachePolicy=”DontCache” duration=”00:30:00″ varyByQueryString=”t,d”/>
<add extension=’.js’ policy=’DontCache’ kernelCachePolicy=’CacheUntilChange’/>
<add extension=’.css’ policy=’DontCache’ kernelCachePolicy=’CacheUntilChange’/>
</profiles>
</caching>

What this code does is firstly allow the js and css files to be cached in kernal mode until there is a file change. The axd setting is used to cache those dam embedded resource files and to make sure we cache the actual files and not just a single file we need to vary by querysting on the t and d keys. Now we have the aspx file, ths obviously has a small caching duration as the system is dynamic and changes, so every 30 seconds is more than enough. But we have different presentation based on the User-Agent so we want to make sure we have a unique cache for each User-Agent supplied.

Conclusion

With these we have been able to reduce the overall size of the site (including images etc) from around 700K to around 200K (this was also done by setting the deploy type to “Release). So what we have now is a cached and compressed collection of the following files;

• js
• css
• aspx
• axd

Obviously there are even more things you can do to speed up your site but for now these will help to reduce the load on the server and to deliver a user a much small site which will basically load the site quicker thus increasing your responsiveness to a new user. Hope this helps

So what is special about the site;

• Browser friendly, well except IE6 no one likes IE6 anymore
• Works with devices such as iPhone, Android etc (can’t guarantee it will be perfect)
• Uses Cufon to render our main header fonts
• Running on the Microsoft Azure platform
• Some more little features

If you want to know more you can always visit us or follow us on twitter feed.

Enjoy

• http://www.daleisphere.com/iphone-app-development-where-to-start/
• http://forums.whirlpool.net.au/forum-replies-archive.cfm/1173999.html
• http://stackoverflow.com/questions/1939/how-to-articles-for-iphone-development-objective-c
• http://deimos.apple.com/WebObjects/Core.woa/Browse/matcmadison.edu.3989485784.03989485786

There are plenty more such as on the Apple site but these will at least push you in the right direction. Also if you can purchase your self a nice book and have a read, that’s what im doing at the moment.

The interface has the following structure;

namespace Sitecore.Caching

{

public interface ICacheable

{
bool Cacheable { get; set; }
bool Immutable { get; }
event DataLengthChangedDelegate DataLengthChanged;
long GetDataLength();
}
}

The main method we are focusing on is the “long GetDataLength();” aspect as it requires the actual size of the object, this can be hard if the data is dynamic and you are basically just guessing.
So what we need is a way to clearly tell how much everything is and here is my solution (This is only including the DataLength data and will have to be changed to get it work correctly);

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

namespace SitecoreTest
{

/// <summary>
/// The Test Caching
/// </summary>
[Serializable]
public class Test : Sitecore.Caching.ICacheable
{

#region Private Variables
/// <summary>
/// Is the class cachable
/// </summary>
private bool _cacheable = true;

/// <summary>
/// The data length
/// </summary>
private int _dataLength = 0;
#endregion

#region Public Properties
/// <summary>
/// Is the class cachable
/// </summary>
public bool Cacheable
{
get
{
return this._cacheable;
}
set
{
this._cacheable = value;
}
}

/// <summary>
/// Is the class immutable
/// </summary>
public bool Immutable
{
get
{
return true;
}
}
#endregion

#region Event Delegates
/// <summary>
/// The event when the data length changes
/// </summary>
public event Sitecore.Caching.DataLengthChangedDelegate DataLengthChanged;
#endregion

#region GetDataLength
/// <summary>
/// Gets the data length of the class
/// </summary>
/// <returns>Returns the data length of the class</returns>
public long GetDataLength()
{
if (this._dataLength == 0)
{
try
{
System.IO.MemoryStream mem = new System.IO.MemoryStream();
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter binFormatter = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
binFormatter.Serialize(mem, this);
this._dataLength = System.Convert.ToInt32(mem.Length);
}
catch (System.Exception ex)
{
this._dataLength = 700; // default size
Sitecore.Diagnostics.Log.Warn(“Get Size – Test”, ex, typeof(Test));
}
}

return (long)this._dataLength;
}
#endregion
}
}

So what do we get, it’s simple a way to add the class to cache without having to worry about the actual size, enjoy