Today I hade the dubious pleasure of having to work with an old EPiServer 4 site, and having to deploy it to IIS7 on a Windows 2008 Server.
In order to make everything work in EPiServer 4, you need to make sure that all 404-request are redirected to /Util/NotFound.aspx. On my development machine, which runs Windows 7, I accomplished this by adding the following code to web.config:
Since both Windows 7 and Windows 2008 Server runs IIS7, you would think that this should work on the server as well. But when I ran a particular URL that needed the redirection to NotFound, I only got the following error message:
The page cannot be displayed because an internal server error has occurred.
Nothing else. Nothing in the log files, nothing in the event log. Hmmm.
After fiddling around for a while and trying to figure out what was wrong, I tried going into the Error Pages feature in IIS Manager on the server, and suddenly got the error message saying:
This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.
What this basically means is that I can’t use the <httpErrors>-section in web.config, because the machine settings says that I can’t. Now, the settings for IIS7 can be found in the file applicationHost.config, located in C:\Windows\System32\inetsrv\config. A look in this file on both the server and on my machine showed a subtle difference:
1 2 3 4 5
<!-- Windows 7 --> <sectionname="httpErrors"overrideModeDefault="Allow" />
<!-- Windows 2008 Server --> <sectionname="httpErrors"overrideModeDefault="Deny" />
For some reason, the default configuration on Windows 2008 Server doesn’t let you override the httpErrors-configuration in web.config, while the default configuration on Windows 7 does. I’m not saying that either one is more correct that the other, but if it had been the same on both it would have saved me a couple of hours of work today. Sometimes subtle differences can cause a lot of work…
Sometimes .NET error messages are helpful, sometimes they are not. But worst of all are when they are outright misleading! Like the one I came across today.
I was trying to programmatically register a ASP.NET Ajax ScriptManager in a web control, and as the webcontrol was already overriding OnPreRender, I figured “what the heck, I’ll just put it there”. So, I basically wrote this code:
1 2 3 4 5 6 7 8 9 10 11 12
protectedoverridevoidOnPreRender( EventArgs e ) { RegisterScriptManager(); base.OnPreRender( e ); } privatevoidRegisterScriptManager() { if (ScriptManager.GetCurrent( Page ) == null) { Page.Form.Controls.Add( new ScriptManager() ); } }
Now, as it turns out, OnPreRender is not a particularly good place to try to modify the control collection of the page. When I tried to run the page, I was greeted by this friendly error message:
Ok, so the control collection cannot be modified during DataBind, Init, Load, PreRender or Unload phases. Really? What events does that leave us with? Lets see, override…
Whoops, turns out the only events available are OnDataBinding, OnInit, OnLoad, OnPreRender and OnUnload. Exactly the ones that the error message told me not to use. Well, since the error message explicitly told me not to use them, I suppose I can’t.
The next 30 minutes or so I spent trying to find another (not too complicated) way to put my ScriptManager in the page, I also googled (actually, binged) quite a lot, and found a post that seemed to modify the control collection during the Init phase… That wouldn’t work, would it? I said to myself, what the hell, it can’t hurt to try, and changed my code to this:
1 2 3 4 5
protectedoverridevoidOnInit( EventArgs e ) { RegisterScriptManager(); base.OnInit( e ); }
Ctrl-Shift-B. Alt-Tab. F5. Wait. Wait some more… Lo and behold, it works!
So, it seems you can modify the control collection during the Init phase, even though the error messages explicitly tells you that you cannot! WTF! Thank you very much .NET Error Message Team, whoever you are, for wasting 2 hours of my day (yeah, after I had wasted 30 minutes on this error, I wasted another 1½ hour writing this blog post :-))
Facebook Comments is a very useful widget for Facebook Connect, the integration platform for Facebook, allowing you to place a comments box on your web pages. As it uses the Facebook connect platform, it lets the users sign in with their Facebook accounts as well as publish their comments to their FB feed, making this a powerful marketing tool as well.
Not that it is extremely difficult to integrate the comment box in your EPiServer site, but we thought it would be a good idea to make it even easier. So behold, the “Facebook Comments for EPiServer CMS” module (yeah, I know, I should work on the name) was born!
Instructions
In order to use the comments box, you first need to create a basic Facebook App. Name this anyway you like, for example JohanEPiComments. After you have created the app, set the callback url for your site (Canvas –> Canvas Callback URL). A public url is not needed, but if you are developing on your local machine, you can’t use “localhost”, but rather something like “myepisite.local”.
That’s it, your application is set up. Now, take note of your API key and your secret key. These are needed later.
Copy the binary files from the zip file below to your bin folder, and add the following lines to you web.config (or just put the highlighted line at the appropriate position):
You also have to add a “cross-domain receiver file” to your application root folder (probably a good idea to include it in your project), in order to enable Facebook to run scripts on your page. Currently you can download this file here: http://www.somethingtoputhere.com/xd_receiver.htm.
After this, you have to add some properties to you start page in EPiServer:
The FacebookAPIKey and FacebookSecretKey properties are, of course, where you enter the API key and the Secret key from your application. The FacebookCommentXidPrefix is a prefix for the unique ids for every page comment box (xid). Facebook Comments normally uses the url of the page for this key, but this makes it difficult if your pages are accessible on several domains (i.e. www.dropit.se and dropit.se). Instead you could use the prefix “dropitse”, and make it domain independent.
After settings this properties, all you have to do is to add a web control to the pages that you want to have comments on:
The web control accepts all attributes that are described on http://wiki.developers.facebook.com/index.php/Fb:comments_%28XFBML%29, except “xid”, which is automatically created for the page. All are optional. Note: The commentsblock control automatically adds a script reference to the head-section of the page, but for this to work the head tag needs to be runat=”server”. If, for some reason, you don’t want your head-element to be a server control, you could add the script reference manually, like this:
1 2 3 4 5 6 7 8 9
<!-- head as a server control - no need for the script reference --> <headrunat="server"> ... </head>
<!-- or you can register the script manually --> <head> <scriptsrc="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php"type="text/javascript"></script> </head>
An extra feature in this plug-in is the ability to get the number of comments for a specific page without actually loading the comments box. This is done by calling FacebookUtility.GetCommentCountForPage(), which takes a PageData object as variable. This feature uses the Facebook Developer Toolkit, which is included in the zip file.
Disclaimer and licensing
No guarantees whatsoever are made for the functionality or usability of this code. It might eat your code and format your hard drive, but probably not. That said, if you have any questions or opinions, please post them as comments to this post.
*Update on repost on my new blog – just in case Dropit would do something stupid, like move or even remove the files linked above, I also made them available from my site: Binaries: Dropit.FacebookComments_Bin.zip Source code: Dropit.FacebookComments_Source.zip*
Ever wished that you could extract the data from Google Analytics and process it in some powerful application like say, Microsoft Excel? Well, now you can!
Excellent Analytics is a simple Excel plug-in that let’s you import data from you analytics account straight into your spreadsheet. It has been developed as thesis work here at Dropit by our former intern Fredrik Johansson (great job!), and is available as open source at excellentanalytics.com, or if you want the source code at http://code.google.com/p/excellent-analytics/.
As an early adopter of everything new (meaning if it isn’t beta it is not worth installing), I recently installed Windows 7 RC on my laptop, and yesterday I also installed Windows XP Mode, or XPM. XPM is basically an extension of Virtual PC, and a new Virtual PC beta version, that allows you to run XP applications outside of the virtual machine, just like normal applications.
This is really useful e.g. for testing things in IE6, or older versions of Firefox. The only working way of running IE6 on Vista or Win7 is in a virtual machine, but switching between the virtual machine and your normal environment is a hassle. But now I can just start “Internet Explorer (Virtual Windows XP)” from start menu in Windows 7, and get an XP/IE6 window right beside my other apps.
The only thing that bugs me is that the taskbar icon shows a virtual pc icon instead of the IE6 icon.
A colleague of mine - let’s call him Erik Nilsson, since that is his name - recently came across a potential security problem when creating your own edit och admin plugin to EPiServer. Unfortunately, he’s too shy to write a post about it, so I’ll relay the information. If you create a plugin like this:
1 2 3 4 5 6 7 8 9 10
[EPiServer.PlugIn.GuiPlugIn( Area = EPiServer.PlugIn.PlugInArea.AdminMenu, DisplayName = "Plugin name.", Description = "Plugin desc.", Url = "~/plugin/myplugin.aspx", RequiredAccess = EPiServer.Security.AccessLevel.Administer )] public partial class MyPlugin : EPiServer.UI.SystemPageBase { //... }
You might think that this plugin in only accessable to users with administration right. This however, is only the case if you access it through the admin mode. If you access the page directly, i.e. by using the url http://somesite.com/plugin/myplugin.aspx, you can access it without even having to login. Seems EPiServer only checks the RequiredAccess in the admin or edit mode.
So what you need to to in order to secure your plugin is to set required access for the “plugin” location in web.config:
Bug or working as intended? I don’t know, but it’s important to keep in mind either way.
By the way, I’m trying out a new syntax hightlighter. Like it? It’s this one. The old one is still available as well, but it seems to be more happening with this one.
Logging errors on a web site can be a pain. Sure, when you use EPiServer, you get the log4net error logging framework, but how much fun is it to read the log files it produces? First, every 404 is going to clog the log file making the important errors hard to find and second, the format of the log is not really reader friendly – you need to access the server and open it in a text editor. This usually means that you (or I, or we) ignore the error log until something bad happens.
At the same time, there is much to be gained by keeping track of your exceptions continually, and fixing them before they cause problems. And it turns out there is an excellent tool for this, called Elmah.
Elmah is an error logging tool that is completely pluggable, meaning you can add it without re-compiling och re-deploying, just by dropping a dll in the /bin directory and adding a few lines to the web.config file. After doing this, you get a nice web interface for you exceptions, that look like this:
What you see here is just the list of errors. If you click the details link on one of the errors, you get lots of more information. First of all, you get info about the error itself, the stack trace and so on. Basically the stuff you see on the usual yellow .NET error page. But you also get all the server variables, such as the user agent, the charset, the language, the hostname, the file that was accessed and so on. This makes it much easier to track down the actual problem, and this is of course something you don’t get when you just use log4net and log to a file. Elmah logs to memory by default, meaning that the log disappear when you restart the application. But it can also log to a database or and XML-file if you need persistance. Regardless of the format, the UI is the same.
It took me about 2 minutes getting this up and running, following this nice tutorial. And since this seemed really sweet, I immediately wanted to install it on a real server (no, Apollo is not a real server, it’s just my computer at home). Said and done, I quickly discovered two things:
On a Windows 2008 Server, you don’t put you httpmodules and httphandlers under the system.web element, but under the system.webserver element. What’s more, httphandlers need a name attribute.
If you log exceptions on a public web site instead of you own toy site, 99% of them will be HttpExceptions, namely 404 errors (actually, I knew that already, I mentioned it in the first paragraph).
The first problem was easily fixed. The second one was more interesting, as this was one of the reasons that I wanted to use Elmah in the first place. Well, luckily for me, it turns out that Elmah also comes with a pretty competent filtering framework. So by using this little snippet, I filtered out all 404 errors:
1 2 3 4 5 6 7 8 9
<!-- register the filter module in httpModules or modules, depending on the IIS version --> <addtype="Elmah.ErrorFilterModule, Elmah"name="ErrorFilter" />
<!-- config the filter in the elmah config section --> <errorfilter> <test> <equaltype="Int32"value="404"binding="HttpStatusCode" /> </test> </errorfilter>
So now the exception logging is running happily both on my toy site and on the production web site, whose identity I will not disclose here. Unfortunately, since I got it up and running about an hour ago, not a single exception has occurred! Somebody better do something we didn’t think of soon! :-)
Meanwhile, I will add the built in RSS-feed to my RSS-reader. I did mention that it comes with a built-in RSS feed, did I not?)
I’ve been fiddling around with ASP.NET MVC and SubSonic 3 for a while (as I mentioned in a previous post), and also been learning some cool stuff about T4 Templating. Now Rob Conery has created a very cool Visual Studio template bringing all this together (be sure to watch the video). And it even includes single sign on capabilities with e.g. Google and OpenID! And yeah, lots of ajax with jQuery.
I tried using this yesterday, and apart from his template being a little bit broken it really works! I created a data driven MVC web application with my own custom database in like 30 minutes. And without any magic, unmaintainable code that you can’t fiddle with. It’s just plain MVC, with SubSonic domain objects.
So I started over with the Dropit Labs site (which is actually only a static html page right now), using this. And after 2 more hours work I’m now only a little styling away from replacing the static version with a new state-of-the-art ASP.NET MVC version that will look almost exactly the same! I’m hoping to find the time to use my crazy css skills this weekend, and being able to release it next week.
On Wednesday, one of our oldest employees (as in has been working here for a long time, not really being that old) was appointed an EPiServer Most Valued Professional, or EMVP. A big congratulations to Fredrik Karlsson!
I managed to get a little chat with him about how he feels about this and how he feels about EPiServer.
Johan: So, Fredrik, congratulations on becoming an EMVP.
Fredrik: Thank you.
Tell us a little bit about yourself, how long have you been working with EPiServer?
Well, I’m 30 years old, lives in Stockholm and slowly getting a little bit fatter for each year.
I’ve been working with web development since 1997 and with EPiServer since 1998. In 2000 I started working at Dropit and here I am today.
I see, and what is your current role at Dropit?
For the last year I have been involved in the development of Extension X3… err EPiServer Composer, but since EPiServer bought it I have been working in something called Expert Services here at Dropit. You might say I’m something as a developer handyman, doing everything from error search to specialized customer integrations…
What do you think is the greatest difference in working with EPiServer today compared to when you started?
When I started with EPiServer CMS 2 is was a VBScript/asp based website with frames. You can’t really compare the products. But I can say that EPiServer CMS 3 was nice because you had the ability to change almost anything. Then in EPiServer CMS 4 I think it was a small step backwards because it was a much more system. But now in EPiServer CMS 5 I think it’s a giant leap forward. Especially with a lot more generic MS controls rather then the homebrewed ones from EPiServer. Because lets face it, EPiServer is not that good in building web controls.
What does it mean to be an EMVP?
Apart from the small perks you get from EPiServer I think the biggest difference is that you are somewhat responsible for the reputation of EPiServer. If an EMVP writes something insulting, it will reflect on EPiServer and not just the person. Especially now with EPiServer gaining a larger international market. But to be honest, the thing I look forward the most is probably the clothes.
What do you anticipate most in the next release of EPiServer?
MVC. Please, please, please EPiServer!
Why do you think EPiServer is still relevant today after so many years?
They have been rather successful in implementing new techniques and so on. But I believe the key factor is that it is very good for novice advanced beginners. Its really easy to get started witch give them an ever expanding user base. Especially with the demo templates and likewise.
What to you think is EPiServer’s greatest challenge in order to keep being relevant in the future?
To be true to its core business and not try and do something they are not that good at. But first and foremost to listen to the EPiServer user/developer community, Today this is EPiServer weakest part by far. Sure, they say they listen to us, but it’s lacking so much in information and the possibility to give to the community.
Thank you, Fredrik, for taking the time to answer my stupid questions.
We recently upgraded our project to EPiServer 5 R2, and that made some strange things happen. I had a class that uses the EPiServer.DataFactory to manipulate pages, and in order to make it testable, I had the following constructors:
This worked just fine before we upgraded. But now it turns out, in R2 DataFactory doesn’t implement IPageStore anymore. In fact, the only interface it implements is IPageSource, which is pretty worthless in this context. Of course, DataFactory still have the same methods, so it could *implement IPageStore, it just… doesn’t. And to make things worse, DataFactory is *sealed**, so you can’t really mock it at all, and it only implements PageStoreBase (which only contains event handlers), and the aforementioned IPageSource. So basically, EPiServer just made it impossible to write unit test for anything using the DataFactory. Thanks.
Why, oh why did EP decide to change this? Anyone know?