This post is a quick write up of an issue I noticed when using Google Chrome on a touch screen Windows 8.1 machine when using EPiServer 7.5 and how to solve it.
I was using a Windows 8.1 touch screen laptop with Google Chrome installed to access an EPiServer 7.5 site. I noticed the UI didn't seem to fully work. Specifically the context menus didn't appear when I hovered over blocks with a mouse and also I couldn't drag blocks to rearrange or add a new block. Using a mouse to hover over a block I expected to see this:
I recently encountered an issue where EPiServer Composer appeared to be serving up old versions of pages, even after they have been published. This was identified on EPiServer CMS 6 R2 and Composer 4.
The issue was traced to a particular behaviour where editors copy/pasted a Composer page that contained global Composer blocks. After this operation the newly created page would revert back to an "old" version that contained no Composer blocks. This happened after a period of time and to compound the issue it is only noticable in view mode and not edit mode.
This post is written as a result of attempting to run an existing EPiServer CMS 6 R2 solution on new build Windows 8 machine. If you are trying to use the EPiServer 6 installer to install a new site on Windows 8 take a look at Arild Henrichsen's blog on the EPiServer 6 Powershell bug on Windows 8. However if you are having trouble running an existing EPiServer CMS 6 R2 solution on Windows 8 read on...
I have previously posted about Granular Page Type security in EPiServer using PageTypeSecurityAddOn. This added granular security to page types in EPiServer.
However the client in question also wanted more control over the access rights on langauges too. More specifically they wanted to remove publish rights to a specific langauge in EPiServer. I translated this requirement to mean it should be possible to specify who should have publish rights on a per langauge basis. So I created LanguageSecurityAddOn to address this requirement.
I recently posted about Granular Page Type security in EPiServer using PageTypeSecurityAddOn which I created as part of SecurityPack for EPiServer on CodePlex. After discussions with some collegues I have added some additional features.
I was at a client site and they asked why users could edit a page that they did not have access to create. I asked what they meant and they said they they removed Create access in admin mode for a certain page type but users could still edit pages that were created with that page type. I explained the access was for create permissions only but the client disagreed and thought that if you cannot access a page type then why should you be able to edit it? To be honest, I agreed.
So I decided to create a plug in that resolved the problem. I wanted a plug in that would give me more granular access to page types in EPiServer, to allow me to specify who could edit certain pages types, not just create them. So I created PageTypeSecurityAddOn.
I was at a client site the when a question was asked about how to personalise content using the selected language. The scenario is as follows:
- Site editor(s) publish content on a global branch for example English /en/
- Both /en-GB/ and /en-US/ fall back to /en/ and share content for most of the site (some individual country content is published)
- The site is accessed using fallback languages for example English GB /en-GB/ and English US /en-US/
- The client wanted to personalise content for /en-GB/ and /en-US/ in the /en/ page
I have previously released EPiRobots which is a generic robots.txt handler for your EPiServer CMS 6 R2 site. However I was working on an EPiServer Commerce project when I noticed a bug in EPiRobots so have released v1.0.1 onto the EPiServer Nuget Feed. You can see all the details below.
EPiRobots is an EPiServer plug in that handles delivery and modification of the robots.txt file for your EPiServer CMS 6 R2 site(s). It has no dependency on any page types, requires no .config modifications and should work in any EPiServer CMS 6 R2 deployment scenario.
There has been a Geo-IP database lookup function available since EPiServer CMS 6 R2 was released. Recently I wanted to update to the very latest version of the Geo-IP database to ensure a client's site targeted countries as accurately as possible.
This post describes a particular issue that occurs when copy/pasting pages in EPiServer CMS 6 R2 when using EPiServer Composer and Page Type Builder.
The problem occurs if all of the following are true:
- Your site uses EPiServer CMS 6 R2
- You are using Composer
- Page Type Builder is being used
- You are using Page Type Builder to restrict available page types
- Users try to copy a page or pages that container Composer pages
The result is that the background paste operation fails.
As we all know by now EPiServer R2 Wave provides the new Visitor Group functionality across all EPiServer products. This allows editors to personalise content for individual visitor groups. But how do editors know how many people are matching each group that they’ve set up?
As we all know EPiServer visitor groups are going to be an exciting new feature of EPiServer CMS 6 R2. There are plenty of blogs around on how to build custom visitor groups.
EPiServer CMS 6 R2 comes with the great new personalisation feature of Visitor Groups. One of the criterion's available to personalise on is the “geographic location” criteria. Put simply this allows editors to specify a location and/or country to personalise content.