Immediately after you implement the VirtualPathProvider proxy from my previous post you will notice a one fairly serious lack in it. Namely all the files within that provider will be hiding behind the registration form. That is not cool for a couple of reasons?

• You may want to keep all of the files in one store ? being forced to put them into a designated folder is not desired.
• You may want to make some file freely available for some time and lock it after a while, or the other way around (e.g. to allow the robots to crawl it initially). having to move them is just silly and defeats the purpose.

So how do you discriminate the files that you want locked from those that you want to be publically available, and potentially from those that you want only the logged in users to be able to get?

Specifying the EPiServer File Metadata sweetness

One of the potential solutions would be to define a special rights group and check for that group for the people that have your ?registered? magic-cookie. That however introduces a bogus group, and I would rather like to avoid that. However if you look into the FileSummary.config file that?s located in your web application folder you will find a slightly mysterious content. A bit of hacking reveals that you can actually add your own metadata to the file. For example adding the access rights based on what I?ve established above would look as follows (the content you can already find in the file that comes with the public templates that-we-all-oh-so-love is skipped):

Read the rest of this article »

Once you?ll update the framework to the extended one, you will immediately notice that? nothing has changed. Hmm? did something go wrong?

Well, not really. By default the framework will be run in the ?legacy mode?. Thanks to an old article by our own Marek Blotny, I?ve learned how to build Plugin settings which are just perfect for the purpose!

So to configure and enable the new features you need to open your admin UI and in the ?Config? click on the ?Plugin Manager? item and select our framework plugin as shown in the picture

The available options are:

Read the rest of this article »

Once you?ll update the framework to the extended one, you will immediately notice that? nothing has changed. Hmm? did something go wrong?

Well, not really. By default the framework will be run in the ?legacy mode?. Thanks to an old article by our own Marek Blotny, I?ve learned how to build Plugin settings which are just perfect for the purpose!

So to configure and enable the new features you need to open your admin UI and in the ?Config? click on the ?Plugin Manager? item and select our framework plugin as shown in the picture

The available options are:

Read the rest of this article »

Once you’ll update the framework to the extended one, you will immediately notice that… nothing has changed. Hmm… did something go wrong?

Well, not really. By default the framework will be run in the “legacy mode”. Thanks to an old article by our own Marek Blotny, I’ve learned how to build Plugin settings which are just perfect for the purpose!

So to configure and enable the new features you need to open your admin UI and in the “Config” click on the “Plugin Manager” item and select our framework plugin as shown in the picture

The available options are:

Read the rest of this article »

Back in the day when we started designing our last project we?ve been presented with a following problem ? a big number of templates with slightly different sidebars.

Hmm?

Is sidebar a part of content? No, rather not. We don?t want the editors to have to setup the sidebar for every article they write (and the site has a few dozens of articles created on it every day).

Is sidebar more of a template thing? Well? more like it, but still? we have articles all over the site with different sidebar elements when the articles are in different parts of the site (ok so we could add rules what controls display in which part of the site). But wait! There?s more! The sidebar will be different for every language (region). Now we?re talking a dozen of templates or a rules engine just to make the sidebar different. Customising the template with properties isn?t ideal either as it makes EPiServer UI very cluttered. Additionally we want to change sidebars across many templates so the whole branch/section of the site will be able to share the same sidebar.

To a degree this is an academic discussion as we?ve been through it with the previous version of the site and we already knew that integrating this stuff into templates just won?t work and we will be in a world of pain just changing the templates over and over adding little tweaks and changes while the customer ads promotions and performs ad campaigns. Well, we can do it, of course, but it?s not a work a programmer will enjoy, and we all want to do new and more exciting things, don?t we?

We have an internally developed  module to make something like that, that is fully home-grown by another internal team (we now have 3 ?squads? capable or making incredible things with EPiServer and we tend to share a lot of technologies and try to rotate people around to adopt the good habits and experiences) and I was (and still am) VERY impressed by it. The technology uses EPiServer pages for defining every module (which are located somewhere outside the site root branch. and then you can mix and match them either declaratively in the code) or by handpicking them in the UI. It?s really cool, though, during the discussions it turned out that we might have to add big chunks of functionality and might end up with separate branches of module-pages for different languages/regions, but? frankly? about that time an article by Ted Nyberg reminded me about a technology I have read about quite a while ago in an article by Stein-Viggo Grenersen and ooohhhhhh? I got seduced. I really wanted to try if for a long time and Ted?s article made it a snap to try and get convinced, and more important? convince Stu ;) that it?s the right way to explore.

So I started to dig.

Read the rest of this article »

Back in the day when we started designing our last project we’ve been presented with a following problem – a big number of templates with slightly different sidebars.

Hmm…

Is sidebar a part of content? No, rather not. We don’t want the editors to have to setup the sidebar for every article they write (and the site has a few dozens of articles created on it every day).

Is sidebar more of a template thing? Well… more like it, but still… we have articles all over the site with different sidebar elements when the articles are in different parts of the site (ok so we could add rules what controls display in which part of the site). But wait! There’s more! The sidebar will be different for every language (region). Now we’re talking a dozen of templates or a rules engine just to make the sidebar different. Customising the template with properties isn’t ideal either as it makes EPiServer UI very cluttered. Additionally we want to change sidebars across many templates so the whole branch/section of the site will be able to share the same sidebar.

To a degree this is an academic discussion as we’ve been through it with the previous version of the site and we already knew that integrating this stuff into templates just won’t work and we will be in a world of pain just changing the templates over and over adding little tweaks and changes while the customer ads promotions and performs ad campaigns. Well, we can do it, of course, but it’s not a work a programmer will enjoy, and we all want to do new and more exciting things, don’t we?

We have an internally developed  module to make something like that, that is fully home-grown by another internal team (we now have 3 “squads” capable or making incredible things with EPiServer and we tend to share a lot of technologies and try to rotate people around to adopt the good habits and experiences) and I was (and still am) VERY impressed by it. The technology uses EPiServer pages for defining every module (which are located somewhere outside the site root branch. and then you can mix and match them either declaratively in the code) or by handpicking them in the UI. It’s really cool, though, during the discussions it turned out that we might have to add big chunks of functionality and might end up with separate branches of module-pages for different languages/regions, but… frankly… about that time an article by Ted Nyberg reminded me about a technology I have read about quite a while ago in an article by Stein-Viggo Grenersen and ooohhhhhh… I got seduced. I really wanted to try if for a long time and Ted’s article made it a snap to try and get convinced, and more important… convince Stu ;) that it’s the right way to explore.

So I started to dig.

Read the rest of this article »

Back in the day when we started designing our last project we?ve been presented with a following problem ? a big number of templates with slightly different sidebars.

Hmm?

Is sidebar a part of content? No, rather not. We don?t want the editors to have to setup the sidebar for every article they write (and the site has a few dozens of articles created on it every day).

Is sidebar more of a template thing? Well? more like it, but still? we have articles all over the site with different sidebar elements when the articles are in different parts of the site (ok so we could add rules what controls display in which part of the site). But wait! There?s more! The sidebar will be different for every language (region). Now we?re talking a dozen of templates or a rules engine just to make the sidebar different. Customising the template with properties isn?t ideal either as it makes EPiServer UI very cluttered. Additionally we want to change sidebars across many templates so the whole branch/section of the site will be able to share the same sidebar.

To a degree this is an academic discussion as we?ve been through it with the previous version of the site and we already knew that integrating this stuff into templates just won?t work and we will be in a world of pain just changing the templates over and over adding little tweaks and changes while the customer ads promotions and performs ad campaigns. Well, we can do it, of course, but it?s not a work a programmer will enjoy, and we all want to do new and more exciting things, don?t we?

We have an internally developed  module to make something like that, that is fully home-grown by another internal team (we now have 3 ?squads? capable or making incredible things with EPiServer and we tend to share a lot of technologies and try to rotate people around to adopt the good habits and experiences) and I was (and still am) VERY impressed by it. The technology uses EPiServer pages for defining every module (which are located somewhere outside the site root branch. and then you can mix and match them either declaratively in the code) or by handpicking them in the UI. It?s really cool, though, during the discussions it turned out that we might have to add big chunks of functionality and might end up with separate branches of module-pages for different languages/regions, but? frankly? about that time an article by Ted Nyberg reminded me about a technology I have read about quite a while ago in an article by Stein-Viggo Grenersen and ooohhhhhh? I got seduced. I really wanted to try if for a long time and Ted?s article made it a snap to try and get convinced, and more important? convince Stu ;) that it?s the right way to explore.

So I started to dig.

Read the rest of this article »

The configuration of the module is a descendant of any EPiServer Virtual Path Provider configuration. This aspect is fairly well described on EPiServer pages.

A sample configuration for the TextImageVirtualPathProvider can look as follows

<configuration>
  <episerver>
    <virtualPath
      <providers>
        <add showInFileManager="false"
             virtualName="Text Images"
             virtualPath="~/TextImages/"
             bypassAccessCheck="false"
             name="TextImages"
             type="Cognifide.ImageVirtualPathProvider.TextImageVirtualPathProvider,Cognifide.ImageVirtualPathProvider"
             physicalPath="C:\temp\TextImages"
             allowedReferers="(localhost)"
             allowNullReferrer="false"
             replacementStrings="$colon$,:,$gt$,>,$dot$,.,$quot$,&quot;,$amp$,&amp;,$star$,*,$eol$,&#10;,"/>
      </providers>
    </virtualPath>
  </episerver>
</configuration>

where:

• physicalPath is where the cached version of images will be stored
• shownInFileManager is “false” as there is nothing to present for the user in the file manager.
• allowedReferrers is the regular expression containing the filter for sites that are allowed to access the path provider and get images. This has been added so that your server does not turn into the internet’s text-image open service :)
• allowNullReferrer should be set to false in production environment but allows for testing by directly creating URL’s without using a page to fill in the referrer.
• replacementStrings – this one actually turned out to be very useful since some characters are invalid and not even reaching the VPP if EPiServer or ASP detects them. so to allow for characters like colon or < or even a dot (which would make it hard to form regular expression if it was explicitly available) or * you need to create an escape token for them. The string is a coma separated list of token,value,token,value,…
• virtualPath is something you need to change if you want your VPP to serve images under a different root level folder. (e.g. if you have a page with that name already)

Additionally for IIS6 (most common scenario) you need to add <location> node to configuration for the VPP to work.

<configuration>
  <location path=“TextImages“>
    <system.web>
      <!– Setup the StaticFileHandler for the wildcard mapping to work in IIS6–>
      <httpHandlers>
        <add path=“*“ verb=“GET,HEAD“ type=“System.Web.StaticFileHandler“ validate=“true“ />
      </httpHandlers>
    </system.web>
    <staticFile expirationTime=“-1.0:0:0“ />
  </location>
</configuration>

Unless you want to change the location of the virtual path provider can be found under, there is nothing you need to change here.

The code is accessible on EPiCode, but you can also download a compiled binary here. All you need to do then is to unzip the archive to the “bin” folder within your site and set the web.config values to your preference.

The configuration of the module is a descendant of any EPiServer Virtual Path Provider configuration. This aspect is fairly well described on EPiServer pages.

A sample configuration for the TextImageVirtualPathProvider can look as follows

<configuration>
  <episerver>
    <virtualPath
      <providers>
        <add showInFileManager="false"
             virtualName="Text Images"
             virtualPath="~/TextImages/"
             bypassAccessCheck="false"
             name="TextImages"
             type="Cognifide.ImageVirtualPathProvider.TextImageVirtualPathProvider,Cognifide.ImageVirtualPathProvider"
             physicalPath="C:\temp\TextImages"
             allowedReferers="(localhost)"
             allowNullReferrer="false"
             replacementStrings="$colon$,:,$gt$,>,$dot$,.,$quot$,&quot;,$amp$,&amp;,$star$,*,$eol$,&#10;,"/>
      </providers>
    </virtualPath>
  </episerver>
</configuration>

where:

• physicalPath is where the cached version of images will be stored
• shownInFileManager is ?false? as there is nothing to present for the user in the file manager.
• allowedReferrers is the regular expression containing the filter for sites that are allowed to access the path provider and get images. This has been added so that your server does not turn into the internet?s text-image open service :)
• allowNullReferrer should be set to false in production environment but allows for testing by directly creating URL?s without using a page to fill in the referrer.
• replacementStrings ? this one actually turned out to be very useful since some characters are invalid and not even reaching the VPP if EPiServer or ASP detects them. so to allow for characters like colon or < or even a dot (which would make it hard to form regular expression if it was explicitly available) or * you need to create an escape token for them. The string is a coma separated list of token,value,token,value,?
• virtualPath is something you need to change if you want your VPP to serve images under a different root level folder. (e.g. if you have a page with that name already)

Additionally for IIS6 (most common scenario) you need to add <location> node to configuration for the VPP to work.

<configuration>
  <location path=“TextImages“>
    <system.web>
      <!– Setup the StaticFileHandler for the wildcard mapping to work in IIS6–>
      <httpHandlers>
        <add path=“*“ verb=“GET,HEAD“ type=“System.Web.StaticFileHandler“ validate=“true“ />
      </httpHandlers>
    </system.web>
    <staticFile expirationTime=“-1.0:0:0“ />
  </location>
</configuration>

Unless you want to change the location of the virtual path provider can be found under, there is nothing you need to change here.

The code is accessible on EPiCode, but you can also download a compiled binary here. All you need to do then is to unzip the archive to the ?bin? folder within your site and set the web.config values to your preference.

The configuration of the module is a descendant of any EPiServer Virtual Path Provider configuration. This aspect is fairly well described on EPiServer pages.

A sample configuration for the TextImageVirtualPathProvider can look as follows

<configuration>
  <episerver>
    <virtualPath
      <providers>
        <add showInFileManager="false"
             virtualName="Text Images"
             virtualPath="~/TextImages/"
             bypassAccessCheck="false"
             name="TextImages"
             type="Cognifide.ImageVirtualPathProvider.TextImageVirtualPathProvider,Cognifide.ImageVirtualPathProvider"
             physicalPath="C:\temp\TextImages"
             allowedReferers="(localhost)"
             allowNullReferrer="false"
             replacementStrings="$colon$,:,$gt$,>,$dot$,.,$quot$,&quot;,$amp$,&amp;,$star$,*,$eol$,&#10;,"/>
      </providers>
    </virtualPath>
  </episerver>
</configuration>

where:

• physicalPath is where the cached version of images will be stored
• shownInFileManager is ?false? as there is nothing to present for the user in the file manager.
• allowedReferrers is the regular expression containing the filter for sites that are allowed to access the path provider and get images. This has been added so that your server does not turn into the internet?s text-image open service :)
• allowNullReferrer should be set to false in production environment but allows for testing by directly creating URL?s without using a page to fill in the referrer.
• replacementStrings ? this one actually turned out to be very useful since some characters are invalid and not even reaching the VPP if EPiServer or ASP detects them. so to allow for characters like colon or < or even a dot (which would make it hard to form regular expression if it was explicitly available) or * you need to create an escape token for them. The string is a coma separated list of token,value,token,value,?
• virtualPath is something you need to change if you want your VPP to serve images under a different root level folder. (e.g. if you have a page with that name already)

Additionally for IIS6 (most common scenario) you need to add <location> node to configuration for the VPP to work.

<configuration>
  <location path=“TextImages“>
    <system.web>
      <!– Setup the StaticFileHandler for the wildcard mapping to work in IIS6–>
      <httpHandlers>
        <add path=“*“ verb=“GET,HEAD“ type=“System.Web.StaticFileHandler“ validate=“true“ />
      </httpHandlers>
    </system.web>
    <staticFile expirationTime=“-1.0:0:0“ />
  </location>
</configuration>

Unless you want to change the location of the virtual path provider can be found under, there is nothing you need to change here.

The code is accessible on EPiCode, but you can also download a compiled binary here. All you need to do then is to unzip the archive to the ?bin? folder within your site and set the web.config values to your preference.