It?s been a while since I had a chance to do any coding… turns out leading a development division tends to not have much to do with development? who knew?!
But I?ve finally got a moment to sit down and refresh the EPiServer PowerShell console and make it compatible with both CMS versions 5 & 6. You could technically use it before on CMS 6 but the looks of it was broken. (previous version available here)
What triggered it was a talk with Michael Sadler earlier this week. Michael is a technical consultant by day (and a musician by night) in our solutions team in London. We talked how he was doing a content audit for a client in one of the other CMS?es we?re supporting. Which really sounded like a daunting task? The content got exported as XML and then he had to write a bunch of C# code to parse it and create statistics for e.g. how many people edit the content, who created the majority of the content etc? well I couldn?t resist but to brag?
looks through all the pages, and counts how many articles by each author there are in the CMS. Naturally you can also do it on a sub-branch of content as well.
I?m sorry Michael you had to go through this without PowerShell?
Deployment
The plugin will detect the version of EPiServer it?s running under and will skin itself appropriately to match the CMS style.
As far as I can tell, your PowerShell scripts will be interchangeable between the versions, as far as they themselves don?t touch any API that?s undergone a breaking change.
Eric Evans of Domain Driven Design will be giving a talk at PUT just before Eclipse DemoCamp, June 24th @ 18:00. Cognifide are sponsoring the event and it would be a great chance for you guys to dust of those design skills. Domain Driven Design is going to be course that we hope to run out of the Cognifide Office late this year with the a little help from our friends at Skills Matter.
Register for the Domain Driven Design that is platform-neutral and in fact, Eric gives .NET and Java versions of the courses.
Have you ever (or have your customers) created and edited a page in one language only to realize that their selected locale was wrong? Have you ever wished you could delete a master language branch of a page after creating its localized counterpart but you could only delete the newly created slave language instead? Have a customer ever requested that they could copy a whole branch and you convert it to another language so that they could then translate in-place?
Well I have? and I?m sure I will. And so did Fredrikj on the our #epicode IRC channel ;).
Basically I had the tool that would convert from one language to another, but Fredrikj requested something that would switch master language of a page from one to another. Since I?ve already had some of the work done, I?ve updated the stored procedure I?ve written some time ago and slapped a nice GUI up on it. Here?s the result:
What the tool allows you to do is perform either language conversion or master branch switching on a selected page and all of its children (if you choose so).
The stored procedure have been updated to work on CMS5 R2 (will no longer work on R1 ? but if you need that functionality, comment here or give me a shout and I?ll create a compatible version for you).
A word of caution though ? I take no guarantee whatsoever about its operation. Especially, if you wreck your client?s database with it. I did what I could to prevent some of the obvious problems (like switching to a non existing master or converting to an existing one) but I will not be responsible if it won?t work for you. make a database backup and experiment there before you do any changes on the real data. That said ? it works for me, so I think it should also work for you.
You can download the archive containing the tool here. unzip it to your EPiServer web application folder keeping the folder structure or the plugin reference will be wrong. Include the *.aspx and the *.cs files in your project and apply the SQL file to your database (The manipulation is performed by a stored procedure located in the file).
Also if you?re performing the change in a load balanced environment, you may need to restart the other servers once you do the changes. I reset the DataFactory cache, but I am not sure it propagates through to other servers.
March 17th, 2009 by Adam Najmanowicz | 27 Comments
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):
March 12th, 2009 by Adam Najmanowicz | 45 Comments
With the culture of knowledge sharing and open source spreading, everyone races to show they have something valuable that you may want. And while you may not ask for money for your content you may still want to get something in return, say a contact, an email address that?s verified (or not), to keep in touch with the consumer of your content.
Yet a full fledged registration doesn?t seem like a proper thing to do ? cluttering your EPiServer user repository with (let?s face it ? for a large part fake or temporary email addresses that user create only to get your content).
While there may be a lot of ways to handle that (streaming it through a page Response.WriteFile might seem as one of the more obvious ones), I would like to show you a cleaner, simpler and more elegant way that I?ve come up with.
We really don?t want people to deep link to our files without them knowing the files are from our site, that?s just rude ? so hiding them behind an obscure URL wouldn?t work (thus we cannot use the regular file providers). We?ve already establish that we don?t want to log them in, so setting file rights are useless. But I want all the benefits including client-side caching.
Basically the solution boils down to creating a thin layer over the File provider of our choice, in my case the versioning file provider. The only method we need to override in it is GetFile. I want to allow downloading for logged in users and I want to allow downloading for all users that have a ?magic-cookie? set. If either of the conditions are met, the file just downloads using the underlying provider?s routines including all the logic EPiServer has put for caching and rights. But if neither of the requirements are met, the user is directed to a page of our choice.
January 8th, 2009 by Adam Najmanowicz | 16 Comments
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
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
January 8th, 2009 by Adam Najmanowicz | 16 Comments
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
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.
January 8th, 2009 by Adam Najmanowicz | 4 Comments
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.
Loading...
(6 votes, average: 4.67 out of 5)
