km / sitecore

IIS doubles image size when using original file extension

We have configured IIS to use original file extensions (.jpg, .gif, etc) - we have configured ISAPI application mappings so that our Google box can search images from the Media Library (so it doesn’t use the .ashx file extension).

Images that are being accessed from the file system directly (for example, www.site.com/images/img.gif) have appeared to have a size double than its original size.  This is a problem for us as pages are required to be kept to a certain size.

The file opened in a browser using the original media extension are being served twice.

Along with mapping the file extensions, a change had to be made to the FilterUrlExtensions section Web.Config:

<processor type="Sitecore.Pipelines.HttpRequest.FilterUrlExtensions,  Sitecore.Kernel">
 <param desc="Allowed extensions (comma  separated)">aspx</param>
 <param desc="Blocked  extensions (comma separated)">*</param>
 <param  desc="Blocked extensions that stream files (comma  separated)">doc,dot,rtf,docx,pdf,txt,xls,xlsx,csv,mpp,msg,xml,jpg,jpeg,png,gif,bmp,tif,.. etc</param> 
 <param desc="Blocked extensions that do not stream files (comma  separated)">*</param>
</processor>

This change above was so that we can actually view the images that are being accessed from the file system directly, this does not affect images that are accessed from the Media Library - these are fine.

However, this is causing the images to double in size - which we don’t want, but we still require the mapping.

We modified the FileUrlExtensions section in Web.Config yet again to the following:

<processor type="Sitecore.Pipelines.HttpRequest.FilterUrlExtensions,  Sitecore.Kernel">
 <param desc="Allowed extensions (comma  separated)">aspx</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>

We replaced the extensions with a *.  In Windows XP - this works fine, the images are being kept at their original size AND we can view the image in the first place.

In Windows Server 2003 however, this unfortunately does not allow us to view the images. But by having the list of file extensions in the <param desc=”Blocked extensions that stream files (comma separated)”></param> section seemed to fix it.

We are hoping someone may have a possible solution for this! It would be very appreciated.

3pm

Just a neat vid for anyone who is interested :)

6pm

Experiences with the Poll Module

• Connection string
  
  We’ve had to alter a few things with the Poll Module which involved us using SQL database instead of an Access database.  This was because we noticed after adding a poll the vote count was always one vote behind.  Upon changing the database to SQL, we had problems connecting to the database.  We were testing the Poll using two websites - one that has a named instance and one without.  The connection string settings were set from the Sitecore start menu > All applications > Poll Module > Settings.
  
  
  
  
  Connection string - with no named instance - this needed a backslash after the Data Source:
  
  Provider=sqloledb;Persist Security Info=true;Data Source=<xx>\;Initial Catalog=<xx>;User ID=<xx>;Password=<xx>;
  
  The connection string above worked however on our client’s environment, the Persist Security Info had to be removed as there were conflicts with permissions.
  
  Connection string - with a named instance - no backslash needed:
  
  Provider=sqloledb;Persist Security Info=true;Data Source=<xx\xx>;Initial Catalog=<xx>;User ID=<xx>;Password=<xx>;
  
  For some reason we couldn’t get this connection string to consistently work.
  
  We decided to alter DatabaseContext.cs and use an SqlConnection instead of Oledb.
  
  New string:
  Persist Security Info=true;Data Source=<xx\xx>;Initial Catalog=<xx>;User ID=<xx>;Password=<xx>;
  
  Whether the Data Source had a named instance or not - the backslash was not needed and the Provider was removed.  This worked fine.

• Styles
  
  We had to alter Voting.cs to render the HTML. RenderVotingContent() used the same ID attribute for all of the radio button options - which caused HTML validation errors.
  
  

   ..
   Modules.Poll.Domain.PollOptionItem[] 
     opts = CurrentPoll.GetOptions(); 
     string optsGuid = ""; 
     string optsTitle = ""; 
     for (int i = 0; i < opts.Length; i++) 
     { 
        optsGuid = opts[i].ID.Guid.ToString(); 
        optsTitle = opts[i].Title; 
        RenderVotingContentOptions(this.ClientID + "_voteList" + (i + 1).ToString(), writer, optsGuid, optsTitle); 
     } 
   .. 

• Overall it involved a lot of changes to suit our requirements.  It was a bit frustrating not having the connection working on our client’s end thus it involved us making quick last minute changes.

10am

Title attribute and Macron characters - update

We have found a solution to our Macron Character problem in the title attribute.

The beginning of the post below refers to an entry (Sitecore - Custom Text Field) on creating a custom text field - particularly a “Macron Text” field.

The problem was in the class created to insert a macron character into our custom Macron Text field.

The Sitecore - Custom Text Field post has a switch statement that simply copies and pastes the macron character into the Macron Text field:

switch (messageText)
 {
   case “macrotext:copy” :
   break;
   case “macrotext:paste”:
   break;
   case “macrotext:clearfield”:
   this.Value = String.Empty;
   break;
   case “macrotext:capitalAMacro”:
   this.Value = this.Value + “Ā”;
   break;
 }

This was an existing class created a while ago by a colleague - I was wondering why the unicode appears in the Macron Text field and not the macron character itself:

Above is an image of what the Macron Text field inserted when selecting a macron character - this is because in the switch statement of the MacroText.cs class, the value was the unicode and NOT the actual macron character.

We have now modified our switch statement in our MacroText.cs class to this:

switch (messageText)
 {
   case "macrotext:copy" :                      
   break;
   case "macrotext:paste":
   break;
   case "macrotext:clearfield":
   this.Value = String.Empty;
   break;
   case "macrotext:capitalAMacro":
   this.Value = this.Value + "Ā";
   break;
   case "macrotext:lowercaseAMacro":
   this.Value = this.Value + "ā";
   break;
   case "macrotext:capitalEMacro":
   this.Value = this.Value + "Ē";
   break;
   case "macrotext:lowercaseEMacro":
   this.Value = this.Value + "ē";
   break;
   case "macrotext:capitalIMacro":
   this.Value = this.Value + "Ī";
   break;
   case "macrotext:lowercaseIMacro":
   this.Value = this.Value + "ī";
   break;
   case "macrotext:capitalOMacro":
   this.Value = this.Value + "Ō";
   break;
   case "macrotext:lowercaseOMacro":
   this.Value = this.Value + "ō";
   break;
   case "macrotext:captialUMacro":
   this.Value = this.Value + "Ū";
   break;
   case "macrotext:lowercaseUMacro":
   this.Value = this.Value + "ū";
   break;
 }

Now, the user can actually see the macron character they are inserting AND better still, our renderings do not need to use the “hack” using <xsl:text>...</xsl:text>.

4pm

Title attribute and Macron characters

We have been having slight problems displaying Macron characters in a “title” attribute.  Particularly for links that have the title attribute for mouse-over text or “tooltips”.

Macron characters such as [ Ā ] are special characters thus it requires a little more attention.  In Sitecore, we have created a custom text field called “Macron Text”.  This is just like a plain text field however this has a drop down where our editors can select a Maori Macron character.  Refer to a colleauges blog entry as to how this was created.

If an editor has inserted a macron character using the drop down:

We can display this on the page using <sc:text field="Page Title select="."/> and this displays the chosen macron character as expected.

However, if we wish to display a macron character as part of the title attribute, this displays the macron character entity:

The image above shows the mouse over of “Te Tāhuhu” as “Te T&257;huhu”.

The code places a “title” attribute in our <span> tag:

To show a link - consider this to be displaying a left navgiation link as shown in the above image:

<span>
 <xsl:attribute name="title">
   <xsl:call-template name="show-link-title" >
     <xsl:with-param name="root" select="."/>
   </xsl:call-template>
 </xsl:attribute>
 <sc:link>
   <xsl:call-template name="show-title">
     <xsl:with-param name="root" select="."/>
   </xsl:call-template>
 </sc:link>
<sc:dot />
</span>

The show-link-title template - this chooses to display the “Page Navigation” field (of field type “Macron Text”, same with Page Title) if this is not empty..:

<xsl:template name="show-link-title">
 <xsl:param name="root"/>

 <xsl:choose>
   <xsl:when test="sc:fld('Page Navigation',$root)!=''">
     <xsl:value-of select="concat(sc:fld('Page Navigation',$root),'. ')" />
   </xsl:when>
   <xsl:when test="sc:fld('Page Title',$root)!=''">
     <xsl:value-of select="concat(sc:fld('page title',$root),'. ')" />
   </xsl:when>
   <xsl:when test="sc:fld('__Display Name',$root)!=''">
     <xsl:value-of select="concat(sc:fld('__Display Name',$root),'. ')" />
   </xsl:when>
   <xsl:otherwise>
     <xsl:value-of select="concat($root/@name,'. ')" />
   </xsl:otherwise>
 </xsl:choose>
</xsl:template>

The problem is that <span title="Te Tāhuhu">..</span> - does not display the macron character.  As this attribute is fetching the value from another template, the browser or rendering (or something?) is interpreting this in a strange way.

A suggested solution was to disable-output-escape in the show-link-title template:

<xsl:template name="show-link-title">
 <xsl:param name="root"/>

 <xsl:choose>
   <xsl:when test="sc:fld('Page Navigation',$root)!=''">
     <xsl:value-of select="concat(sc:fld('Page Navigation',$root),'. ')" disable-output-escaping="yes" />
   </xsl:when>
   <xsl:when test="sc:fld('Page Title',$root)!=''">
     <xsl:value-of select="concat(sc:fld('page title',$root),'. ')" disable-output-escaping="yes" />
   </xsl:when>
   <xsl:when test="sc:fld('__Display Name',$root)!=''">
     <xsl:value-of select="concat(sc:fld('__Display Name',$root),'. ')" disable-output-escaping="yes" />
   </xsl:when>
   <xsl:otherwise>
     <xsl:value-of select="concat($root/@name,'. ')" />
   </xsl:otherwise>
 </xsl:choose>
</xsl:template>

Unfortunately this doesn’t work either.

A couple of colleauges came up with a hack - or “fix”, that we have used temporarily until we can find a more suitable solution.

The fix is to use <xsl:text>...</xsl:text> to write out the span tag and title attributes.

First, we create a variable to hold the value of the title attribute:

<xsl:variable name="titleTxt">
  <xsl:call-template name="show-link-title" >
     <xsl:with-param name="root" select="."/>
  </xsl:call-template>
</xsl:variable>

Then we use <xsl:text>...</xsl:text>:

<xsl:text disable-output-escaping="yes">&lt;span title="</xsl:text>
  <xsl:value-of select="$titleTxt" disable-output-escaping="yes"/>
<xsl:text disable-output-escaping="yes">"&gt;</xsl:text>

Put in our link:

<sc:link>
 <xsl:call-template name="show-title" >
   <xsl:with-param name="root" select="."/>
 </xsl:call-template>
 <sc:dot />
</sc:link>

Close our <span> tag:

<xsl:text disable-output-escaping="yes">&lt;/span&gt;</xsl:text>

This isn’t a desirable fix as this makes the xslt code very messy.. however it displays the macron character in the mouse-over as we wanted.

If anyone can suggest another solution this would be greatly appreciated!

2pm

XSL rendering unwanted HTML tags

The project I am working on at the moment allows content editors to create “widgets” usually appearing on a right-hand column of the website.  These widgets are little boxes with information such as “True Facts” and contains a paragraph of facts relating to the current page the user is on.

Continuing with the “True Facts” example, there are two fields in the content editor: Freeform Title (text) and Freeform Text (rich text).  We only want to display this widget if the content editor has entered both fields.

The following is the HTML:

<div class="widget nav">
 <div class="wrapper">
 <div class="liner">
 <h2>True Facts</h2> <--- Freeform Title
 <p> <--- Freeform Text (as paragraph) Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Mauris enim. Morbi lectus felis, adipiscing at, dictum quis, viverra sit amet, nisl. Praesent turpis purus, suscipit eget, consectetuer sed, bibendum nec, lectus.
 </p>
 </div>
 </div>
</div>

And this is the widget:

In the above HTML the content editor has entered both fields, thus we want the widget to display.

If the fields are blank, we don’t want the widget to display.  The following is the HTML when the content editor has left the fields blank:

<div class="widget nav">
 <div class="wrapper">
 <div class="liner">
 <h2 />
 <p />
 </div>
 </div>
</div>

For this particular widget, the HTML and CSS displays a box around the supposed widget.

<xsl:if> statements are required around ALL the HTML so that if the widget is not to be displayed, then no HTML at all is rendered out.  In some browsers (such as Firefox 2), some CSS styles have images - which is the case in the above widget.

XSLT:

<xsl:if test="sc:fld('Freeform Title',.)!='' and sc:fld('Freeform Text',.)!=''">
   <div class="widget nav">
       <div class="wrapper">
         <div class="liner">
           <h2><sc:text field="Freeform Title"/></h2>
           <p><sc:text field="Freeform Text"/></p>
         </div>
       </div>
   </div>
</xsl:if>

Now, the widget should not render out any HTML if the two fields are empty.  This example is fairly straightforward, so nothing too exciting here - however it is something to consider as maybe a ‘good practice’ to surround HTML with <xsl:if> statements to avoid unnecessary HTML to be rendered out.

10am

XSL Shortening tags

A colleague informed us about using empty tags in XSL.

If you have an empty tag such as:

<div class="clear"></div>

XSL will shorten this to:

<div class="clear" />

Web browsers can get confused by this type of tag and can produce random side effects on the page, such as the overall layout of the page - this tag can mess the page’s layout.

A way around this is to escape the greater-than and less-than signs:

<xsl:text disable-output-escaping="yes">
&lt;div class="clear"&gt;&lt;/div&gt;
</xsl:text>

2pm

Field type Link and Internal Link

If I thought things weren’t going to be more embarassing than the “Recursive” post, I think my beginners blog has started off with amusing (and for me, embarassing) experiences with the latest addition to do with Sitecore’s Link types.

I was assigned a task to create a drop-down of a list of links.  In Sitecore, each item in the drop-down was an item under a “Featured websites” folder under “Common”.  The featured website item had two fields: “Menu Option Name” and “Website URL”.  In the templates, the Website URL was built as a field type “Link”.

The codebehind:

private void populateDropDown()
  {
    Sitecore.Data.Items.Item minWebsites = MinEduDB.GetItem("../common/featured ministry websites");

    foreach (Sitecore.Data.Items.Item site in minWebsites.Children)
    {
       Sitecore.Data.Fields.Field fldMenuName = site.Fields["Menu Option Name"];

         // What I had:
       Sitecore.Data.Fields.InternalLinkField fldURL = (Sitecore.Data.Fields.InternalLinkField)site.Fields["Website URL"];
        // What worked:
      Sitecore.Data.Fields.LinkField fldURL = (Sitecore.Data.Fields.InternalLinkField)site.Fields["Website URL"];

      string ddlItem = fldMenuName.Value;
      string ddlURL = fldURL.TargetItem.Paths.GetFriendlyUrl();

      MinistryLinks.Items.Add(new ListItem(ddlItem, ddlURL));
    }
 }

 protected void btnGo_Click(object sender, EventArgs e)
 {
    Response.Redirect(MinistryLinks.SelectedValue);
 }

For some reason the “InternalLinkField fldURL” wasn’t working.  When the “Go” button was clicked, the page didn’t re-direct to the site as the value of the drop-down item didn’t have a valid URL.

After spending about a whole day with two other developers helping me (Richard and Lee), we could not get it working.  Eventually, Lee had tried using “LinkField fldURL”.  This worked and the drop-down item went to the correct page.

We thought that the field type in Sitecore was an InternalLink, therefore we couldn’t understand why this wasn’t working.  None of us had thought about checking in Sitecore what field type we specified the Website URL to be, which was infact a Link type.  It all made sense after that discovery!!

Another thing I learned only today which I had knew never existed, was when selecting the link in Sitecore for that field, you can insert different link types!!!!!

It just all fell into place after that.  I felt silly once again.  But now I know and there might be someone out there that could possibly go through the same!  Thanks Richard and Lee…. :P

2pm