Ben's Quarters

BlogEngine.NET Theme Contest

Wed, 19 Oct 2011 05:17:00 -0800

If you haven't heard yet about the BE.NET theme contest, it started a couple of weeks ago, and continues on for about 1 more month -- until November 15th.

The 1st BlogEngine.NET Theme Contest!
http://www.dotnetblogengine.net/post/The-1st-BlogEngineNET-Theme-Contest!.aspx

If you know your way a bit around HTML/CSS and BE.NET themes, submit a theme, and you'll be contributing to the growing collection of BE.NET themes, and a chance to win one of the prizes.

So far there hasn't been too many submissions, so winning a prize is easier odds than a lot of other contests out there.

Introducing Multiple Blogs in Single Instance for BlogEngine.NET

Sun, 19 Jun 2011 13:00:00 -0800

The much requested and highly anticipated "multiple blogs" feature has made it into BlogEngine.NET 2.5. BE.NET 2.5 will be released at the end of June. This post goes over how it works and some information on making themes, widgets, extensions and your code be multiple-blog compatible.

Blogs Management Page

Each installation of BE.NET will have a "primary" blog instance. By default this will be the normal blog you are accustomed to. The primary blog has a new "Blogs" admin page. That page looks like:

Here the blog instances (the primary blog instance and child blogs) can be managed. A blog instance can be made Inactive. An inactive blog instance will appear as if it does not exist. Other properties that can be configured for each blog instance can be seen in the following "Add New Blog" dialog window:

Let's look at the properties for each blog instance.

Name

Any name you'd like to give the blog instance. The name does not appear anywhere outside this Blogs management page.

Storage Container Name

This is the name of the folder where the blog data will live. Basically a copy of the files and folders for each blog instance will be made -- i.e. each blog instance will have its own separate folder of data. This makes the blog instances portable and keeps the data separated. Databases can also be used with multiple blogs. Even when using a database, there is still some data (blog post images/files, and a few other small files) that is stored in the file system. So a separate folder will be created for each blog instance even when using the DbBlogProvider.

As in the past, the primary blog instance data is stored in App_Data. There's now a new Blogs folder under App_Data. Within App_Data\Blogs, a new folder matching the "Storage Container Name" will be created when a new blog instance is created. The data that is initially put into this child blog storage folder is explained next.

Existing Blog to Create New Blog from

This is partially related to the above Storage Container Name. When a new blog instance is created, the "Existing Blog to Create New Blog From" dropdown list will contain all of the existing blog instances. The files & folders from the existing blog instance you choose here will be copied into the storage folder for the new blog instance as "initial data". BE.NET 2.5 also includes a "Template" blog instance (which is inactive), and can be used as the existing blog instance to create new blog instances from. The Template blog instance has the same data and settings as the primary blog. You can optionally change the Template blog data, or even create multiple template blog instances to choose from when creating new blog instances.

If using a database, in addition to the storage container folder being copied for the new blog instance, the DB data from the existing blog instance will be copied in the DB for the new blog instance. So for both XML and DB, the new blog instance created will start off using the exact data, files, etc that the blog instance you copied from has.

Note, there is no Template blog included with the database. You can still create your own template blog for the DB by creating a new blog instance of your Primary blog, naming it "Template" (or any name) and customizing it to your liking.

Host Name & Virtual Path

These two properties along with the "Accept Any Text before Host Name" checkbox are what is used for BE.NET to determine which blog instance a request to the application is being made for. Virtual Path refers to the path following the root. Host name is the domain name (plus any subdomain). You can mix and match Hostname and Virtual Path to create many URL combinations. For example, the following URLs can be used:

http://www.example.com
http://www.example.com/blog1
http://blog1.example.com
http://blog2.domain.com
http://blog.domain.com/blog2
... etc ...

The 2nd and 5th examples above would be given a Virtual Path of ~/blog1 and ~/blog2 respectively. Prefixing the virtual path with ~/ is required, and the ~/ will automatically be inserted for you in the Virtual Path field. In the 3rd example above, the Host Name would be "blog1.example.com", in the 4th example the host name would be "blog2.domain.com" and in the 5th example, the host name would be "blog.domain.com".

If you are only using a single hostname for your blog, you can omit the hostname. Entering it is really only required if you will be using multiple hostnames.

With the Virtual Paths above of blog1 and blog2 (examples 2 and 5), you do not need to create physical directories named blog1 and blog2. These are virtual directories that BE.NET will look for in the URL to treat that request to the web server as being on behalf of those blog instances. At the same time, you will want to make sure that physical directories matching the virtual paths (blog1, blog2, etc) do not already exist.

The "Accept Any Text before Host Name" checkbox is another option to allow any text (subdomains) to appear before the Host Name you enter. If you leave this box unchecked, then the Host Name you enter will need to match exactly what is in the browser address bar.

Multiple-Blog Capable Themes, Widgets and Extensions

If you will be running a single instance blog, all of the themes, extensions and widgets that run under BE.NET 2.0 will still work perfectly fine for BE.NET 2.5.

If you will be running multiple blog instances, existing themes, extensions and widgets may need some adjustments to work with this new multiple blogs feature. The following types of issues need to be addressed.

Caching - HttpRuntime.Cache

If an existing theme, widget or extension is storing data in the HttpRuntime.Cache, a likely needed change is to store that data separately for each blog instance. With multiple blog instances, the same set of (physical) themes, extensions and widgets are being used across all the blog instances. So if you have code in a widget that looks like:

HttpRuntime.Cache["recent-posts"] = recentPostList;

This same data you are storing will be shared across all blog instances that are using this widget. This is probably not what was intended. You can either change that code so it uses a dynamic cache key based on the "current blog instance", or as a convenient shortcut, you can use a new Caching provider built into BE.NET 2.5. That line of code above using the new caching provider would look like:

Blog.CurrentInstance.Cache["recent-posts"] = recentPostList;

The cache provider will use your "recent-posts" cache key, prefixing it with the ID of the current blog instance (a GUID). You can retrieve the current blog instance and/or the ID of the current blog instance via:

Blog currentInstance = Blog.CurrentInstance;
Guid currentInstanceId = Blog.CurrentInstance.Id;

Caching - Static

If your theme, widget or extension is storing data in static fields or properties, the cache provider described above cannot be used, however one approach is to convert your static data into a generic dictionary, with Guid as the key and your data type as the value. The Guid key will represent the current blog instance ID. You need to manage this dictionary by adding in each blog instance in the dictionary, ideally as the data needs to be stored the first time. That code might look like:

private static Dictionary<Guid, string> _recentPostsMarkup =
    new Dictionary<Guid, string>();

private static string RecentPostsMarkup
{
	get
	{
		if (!_recentPostsMarkup.ContainsKey(Blog.CurrentInstance.Id))
		{
			_recentPostsMarkup[Blog.CurrentInstance.Id] = GetRecentPostsMarkup();
		}

		return _recentPostsMarkup[Blog.CurrentInstance.Id];
	}
}

URL Paths

This is important and a problem you may notice, especially if you are using Virtual Paths for your blog instances. Let's look at a simple line of code in BE.NET 2.0 that worked fine there:

Response.Redirect("~/Account/login.aspx");

Simple enough. However, if you're using Virtual Paths and you have a blog instance with a Virtual Path of "blog1", the homepage for that blog instance will be something like:

http://www.example.com/blog1

If you have code that uses that redirect shown above, you will end up at:

http://www.example.com/Account/login.aspx

When you probably wanted to end up at:

http://www.example.com/blog1/Account/login.aspx

So instead of redirecting to the login page for "blog1", you've incorrectly redirected the person to the login page for the primary blog instance. That redirect should now look like the following to work well with multiple-blogs:

Response.Redirect(Utils.RelativeWebRoot + "Account/login.aspx");

In the past, Utils.RelativeWebRoot would resolve to the root of the blog. Starting with BE.NET 2.5, Utils.RelativeWebRoot will resolve to the homepage/root of the current blog instance. So when you are in "blog1", Utils.RelativeWebRoot will resolve to:

/blog1/

Similarly, Utils.AbsoluteWebRoot also takes the relative path of the current blog instance into consideration.

If you need the "real" web root of the application, you could use ~/ or you can use a new Utils.ApplicationRelativeWebRoot property.

While on the topic, a couple of other similar new properties are Blog.CurrentInstance.StorageLocation which will return a storage location beginning with ~/ to the physical location of the storage container for the current blog instance. So Blog.CurrentInstance.StorageLocation may return a value looking like:

~/App_Data/Blogs/blog1/

BlogConfig.StorageLocation will return the same type of path, but to the direct App_Data folder (which equates to the storage location of the primary blog instance), so BlogConfig.StorageLocation will generally return:

~/App_Data/

Extensions

With extensions, the primary blog instance has the "master" switch over whether extensions are enabled. If the primary blog instance disables an extension, that extension is no longer available to any of the child blogs. If the primary blog instance enables an extension, by default this extension will be enabled for all the child blogs. A child blog can disable an extension.

As long as the primary blog instance has an extension enabled, that extension will be loaded into memory and if it wires up any of the normal event handlers (Post.Serving, Commnet.Serving, etc), that extension is going to fire even if the event is occurring in a child blog that has explicilty disabled the extension. In this scenario, the extension is handling an event for the child blog, but it should not do anything since the child blog disabled the extension. In other words, we want the extension to "pretend" it was never called, or at least not take any action. This is where a change is required in extensions so they check to see if the blog instance the extension is firing for has the extension enabled or disabled. If it is disabled, then the extension should not run any of it's normal code. The extensions included with BE.NET 2.5 have a new line of code added to them for this. Taking the ResolveLinks extensions as an example, it has this new line of code (technically 2 lines of code) added to the beginning of PostCommentServing:

private static void PostCommentServing(object sender, ServingEventArgs e)
{
	if (!ExtensionManager.ExtensionEnabled("ResolveLinks"))
		return;

	if (string.IsNullOrEmpty(e.Body))
		return;

	e.Body = LinkRegex.Replace(e.Body, new MatchEvaluator(Evaluator));
}

The new lines of code above are lines 3 and 4. It makes a call into the Extension Manager, passing to it the name of the extension (in this case, ResolveLinks). ExtensionEnabled() will return false if the extension is disabled for the current blog instance.

In Summary

As mentioned earlier, if you will be running a single instance of BE.NET, these changes described above will not need to be made -- although they can be made. Overall, I think we maintained a lot of backwards compatibility as the changes you will need to make to have a multiple-blog capable BE.NET application are very minimal. The themes, widgets and extensions included with BE.NET 2.5 already have these changes made to them. Enjoy the new multiple blog capability and if you run into any issues or have any suggestions, the best place to pass along your thoughts is in the CodePlex discussion group.

BlogEngine.NET 2.0 RC - Available now!

Wed, 24 Nov 2010 00:36:00 -0800

On Tuesday, a release candidate for BlogEngine.NET 2.0 was published. Many nice features were added, with lots of great contributions from the community. Switching to Mercurial for source code management made it very easy for people to create their own forks and for us to merge their code in.

Here's the official RC announcement that contains some additional details, including a short 5 minute video demo'ing the redesigned control panel.

If you're already using BlogEngine, I think you'll really like the improvements. These upgrade instructions will come in handy. If you're not using BlogEngine, what are you waiting for?! Stop copying your friends, throw away WordPress and get BlogEngine! :)

I expect we will get some good feedback on issues people run into while using the RC. During my own testing, it's actually working very good even now. Depending on how well the RC goes, the final RTW version may be out in December.

If you download it and find any issues, the best place to report those are in the Issue Tracker.

Give it a try and have fun with it!

Download BlogEngine.NET 2.0 Release Candidate

BlogEngine 1.6 – Released!

Mon, 01 Feb 2010 19:50:00 -0800

Today BlogEngine.NET 1.6 is available to everyone as announced here.

The two big features are a new Comment Management area to view, edit and delete comments across all posts. This also includes a new automated comment moderation system. Just like how you can build custom Extensions, custom filters can be built and plugged into the event system when a new comment is posted. BE.NET 1.6 ships with two custom filters – a filter for Akismet filter and one for StopForumSpam.com. It’s quite slick.

The other notable feature is Multiple Widget Zones. This has actually been in the code base for several months now. I blogged about Multiple Widget Zones back in April.

If you’re upgrading from BE.NET 1.5, there are a couple of changes to be aware of, including one change you must make related to the ExtensionManager sub-folder in the App_Code folder. Simple upgrade instructions are available here in the documentation.

A more complete list of features and changes in BE.NET 1.6 can be found here. It’s definitely a worthwhile upgrade I recommend going to.

CSS & JavaScript Injection Bookmarklets

Sat, 30 Jan 2010 23:34:00 -0800

I like using bookmarklets to inject scripts into a page I’m on. One of the popular ones for this is the jQueryify bookmarklet to inject jQuery into a page.

After getting the jQuerify bookmarklet, I created a separate bookmarklet to inject my own JavaScript file into a document. This is handy when I’m debugging a website I either don’t have the files for, or just want to test changes out within the confines of my own browser without touching any of the live files. To do this, I simply Edit the bookmark in my browser, and change the URL embedded in the bookmarklet to point to the URL of the JavaScript file I want to inject into the page. The URL to the script can even be a script on your own computer accessible via http://localhost, if you’re too lazy to upload the script to a public website :)

Recently, I needed to inject a CSS stylesheet into the page I’m on. The bookmarklet for this is very similar to the JavaScript injection bookmarklet. The bookmarklet I created for this is at the bottom of this post.

Dynamic URL Bookmarklets

Even though it’s not a big hassle to Edit the CSS/JS injection bookmarks to change the URL to the JS or CSS file embedded within the bookmarklet, I realized a very convenient bookmarklet would be one that would prompt me for the URL to the CSS/JS file, and then inject that URL. By doing this, I don’t need to edit the bookmark, and can easily inject any CSS or JS file. It’s also easy to inject multiple URLs by running the bookmark more than once, and entering a different URL each time.

Bookmarklets – For your Browser

For convenience’s sake, I have these 4 bookmarklets down below. Feel free to use them. Two of the bookmarklets are for JS injections and two are for CSS injections. Within each pair, one bookmarklet has the URL already embedded within it, and the other one will prompt you for the URL.

Just drag these links into your Bookmarks toolbar or menu area. For reference, the bookmarklet code is under each link.

> Inject JS file <
javascript:(function(){var%20s=document.createElement('script');s.setAttribute('src','http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js');document.getElementsByTagName('body')[0].appendChild(s);alert('Script%20injected!');})();

> Inject JS file (get prompted) <
javascript:(function(){var%20sUrl=prompt('Enter%20URL%20to%20JavaScript%20file');if(sUrl){var%20s=document.createElement('script');s.setAttribute('src',sUrl);document.getElementsByTagName('body')[0].appendChild(s);alert('Script%20injected!');}})();

> Inject CSS file <
javascript:(function(){var%20s=document.createElement('link');s.setAttribute('href','http://l.yimg.com/a/lib/arc/core_1.0.5.css');s.setAttribute('rel','stylesheet');s.setAttribute('type','text/css');document.getElementsByTagName('head')[0].appendChild(s);alert('Stylesheet%20injected!');})();

> Inject CSS file (get prompted) <
javascript:(function(){var%20sUrl=prompt('Enter%20URL%20to%20Stylesheet');if(sUrl){var%20s=document.createElement('link');s.setAttribute('href',sUrl);s.setAttribute('rel','stylesheet');s.setAttribute('type','text/css');document.getElementsByTagName('head')[0].appendChild(s);alert('Stylesheet%20injected!');}})();

Giving Comment Spammers Less Incentive to Spam You

Tue, 08 Dec 2009 22:01:52 -0800

The latest check-in of BE.NET (1.5.1.36) has a small, but important change. The three themes included with BE.NET now include rel=”nofollow” on the links of commenter’s websites.

This is a theme specific change. So if you’re using a custom theme, and even if you upgrade to the latest build of BE.NET, there’s a good chance you might not have the NOFOLLOW instruction on these links. It can simply be added in the CommentView.ascx file in your theme’s blog folder.

As I’m using a custom theme myself, I just added NOFOLLOW to this blog too. Wikipedia has a good writeup on NOFOLLOW, in case you aren’t familiar with its purpose. I’m a little surprised it’s taken this long to get NOFOLLOW into the themes that are included with BE.NET. Better late than never!

I get a lot of comment spam on this blog. As I’m moderating comments, it ends up never showing up since I don’t approve any of it (TIP to spammers, stop wasting your time!).

Comment spammers are a lot more likely to leave comments on blogs that do not include NOFOLLOW. Yes, I’m sure a lot of the spammers actually look at these types of details when scoping out blogs to attack.

Incidentally, the ResolveLinks extension that comes with BE.NET already includes the NOFOLLOW instructions. This is the extension that will convert URLs in comments into hyperlinks. If the extension finds a URL like www.google.com in the comment content, it will convert that into:

<a href="http://www.google.com" rel="nofollow">www.google.com</a>

This conversion is done as the comment is being served.

I’m anxious to see what type of impact adding NOFOLLOW will have on my level of comment spam.
Fingers crossed ...

App_offline.htm – Page Not Found

Sat, 05 Sep 2009 18:11:00 -0800

For a few years, .NET has had the built-in capability to easily take your entire application offline when you need to make an update or perform some maintenance on your site.

By simply putting a file named app_offline.htm in the root directory of your site, ASP.NET will serve the app_offline.htm file, instead of the requested page.

I recently employed this feature for probably the first time. I put the app_offline.htm file on the site, and pulled up my site in Firefox. The contents of app_offline.htm displayed as expected.

However, if I were to pull my site in Chrome or IE, I would get a Page Not Found error that appeared as though my entire site did not exist.

App_offline.htm result in IE8:

App_offline.htm result in Chrome:

As mentioned above, in Firefox, the contents of App_offline.htm would display as expected.

The problem is that when ASP.NET serves the App_offline.htm file, the HTTP Response code it passes out is 404. Chrome will display the page shown above for 404 errors. In IE, you can actually avoid that generic error page shown above if you turn off HTTP Friendly errors.

But I obviously cannot expect IE visitors to my site to have HTTP Friendly errors turned off.

The way ASP.NET has implemented app_offline.htm by passing out a 404 HTTP status code is not well designed, in my opinion. A much better implementation would be for ASP.NET to return a normal 200 HTTP status code.

To accomplish this, for this site, I created a simple HTTP Module that processed the beginning of each request. It checks an “offline” appSetting in web.config to see if the application should be offline. If the offline setting is turned on, the module will do a server transfer to my own app offline HTML file.

One thing I found on an IIS7 server is requests for items such as JPG, GIF, CSS files, etc. will also go through this HTTP module. This is normally a great benefit of IIS7’s integrated mode pipeline. However, if the application offline HTML file includes an IMG tag for an image on the same site, or a link to a CSS file on the same site, the HTTP module is also going to do a server transfer for these other files (JPG, CSS, etc). This will result in the image not displaying on the application offline page, or the CSS file not loading in the browser, etc.

A simple filter in the HTTP module to only do a server transfer for actual pages is all that is required. The fairly simple HTTP Module I ended up creating is below.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Configuration;
using System.IO;

public class AppOffline : IHttpModule
{
    public void Dispose()
    {
    }

    public void Init(HttpApplication context)
    {
        context.BeginRequest += new EventHandler(context_BeginRequest);
    }

    void context_BeginRequest(object sender, EventArgs e)
    {
        HttpContext context = ((HttpApplication)sender).Context;

        if (ConfigurationManager.AppSettings["offline"] == "true")
        {
            string extension = Path.GetExtension(context.Request.Path);

            // Don't server transfer for extensions like .JPG, .CSS, etc.
            string targetedExtensions = ".aspx.ashx.asmx";
            if (targetedExtensions.IndexOf(extension, StringComparison.OrdinalIgnoreCase) == -1)
                return;
            
            context.Server.Transfer("~/application_offline.html");
        }
    }
}

It’s a pretty simple, but effective HTTP module. When the server transfer is done to my own application offline HTML file, the HTTP status code returned to the client is 200. No more Page Not Found problems with browsers like IE and Chrome.

Performance: Compiled vs. Interpreted Regular Expressions

Thu, 06 Aug 2009 22:33:00 -0800

When a regular expression in .NET will be used multiple times, it’s common to create that Regex with the Compiled flag, e.g. RegexOptions.Compiled. Compiled regexp’s take a bit more time to create initially, but will run faster than a regexp created without the Compiled flag. At least that’s what the documentation states!

Without the Compiled flag, your regexp will be interpreted. There’s even "precompiled” regular expressions. You need to compile these regular expressions into an assembly before runtime. This might be a good option if you have constant regexps that don’t change. If your regexps are subject to change, pre-compiled is not a good option. These three types of regexp’s (interpreted, compiled and pre-compiled) are explained with a few more technical details in this somewhat dated MS blog article.

Theory is great, but real benchmarks are more meaningful. I’ve assembled some code that benchmarks the difference in speed it takes to create and run 5,000 regular expressions. There’s actually a big difference in the time taken to run a compiled regular expression the first time, versus subsequent times. So the results shown here will include the first run time as well as the subsequent run times.

Here’s some code to get us started:

    private static List<Regex> _expressions;
    private static object _SyncRoot = new object();

    private static List<Regex> GetExpressions()
    {
        if (_expressions != null)
            return _expressions;

        lock (_SyncRoot)
        {
            if (_expressions == null)
            {
                DateTime startTime = DateTime.Now;

                List<Regex> tempExpressions = new List<Regex>();
                string regExPattern =
                    @"^[a-zA-Z0-9]+[a-zA-Z0-9._%-]*@{0}$";

                for (int i = 0; i < 5000; i++)
                {
                    tempExpressions.Add(new Regex(
                        string.Format(regExPattern,
                        Regex.Escape("domain" + i.ToString() + "." +
                        (i % 3 == 0 ? ".com" : ".net"))),
                        RegexOptions.IgnoreCase | RegexOptions.Compiled));
                }

                _expressions = new List<Regex>(tempExpressions);
                DateTime endTime = DateTime.Now;
                double msTaken = endTime.Subtract(startTime).TotalMilliseconds;
            }
        }

        return _expressions;
    }

We’re storing 5,000 regular expressions in a static list. Notice the RegexOptions.Compiled flag is being used. The regexp’s are just looking for email addresses with specific domain names – domain1.net, domain2.net, domain3.com, etc. Not very useful, but I just wanted the regexp’s to vary. You can see we’re also recording the number of milliseconds taken to create the regular expressions. Now here’s the code that calls GetExpressions() and actually invokes the IsMatch function on each regexp.

    private static void CheckForMatches(string text)
    {
        List<Regex> expressions = GetExpressions();
        DateTime startTime = DateTime.Now;

        foreach (Regex e in expressions)
        {
            bool isMatch = e.IsMatch(text);
        }

        DateTime endTime = DateTime.Now;
        double msTaken = endTime.Subtract(startTime).TotalMilliseconds;
    }

And we call CheckForMatches like so:

    CheckForMatches("some random text with email address, address@domain200.com");

How much time does it take to create and run these 5,000 compiled expressions? Here’s what I get:

Compiled Regular Expressions
CREATION TIME: 1662 ms
FIRST RUN TIME: 25137 ms
SUBSEQUENT RUN TIMES: 41 ms

Subsequent runs of all 5,000 expressions is very fast. However, look how much time it takes the first time these 5,000 expressions are run in CheckForMatches() – 25 seconds!!!

Let’s make ONE change. Remove the RegexOptions.Compiled flag. By doing this, our regular expressions will be interpreted. Here’s what we get:

Interpreted Regular Expressions
CREATION TIME: 493 ms
FIRST RUN TIME: 22 ms
SUBSEQUENT RUN TIMES: 20 ms

Interpreted regexp’s beat compiled in every category! Running these tests several times produces similar results. The BIG difference here is obviously the First Run Time. 25 seconds versus .022 seconds.

I’ve seen some benchmarks showing static regexp’s performing a little slower than instance regexp’s. I ran the same tests without the static modifier on the fields and methods above. Same results – using the Compiled flag takes around 25 seconds for the regular expressions to run the first time. Without the Compiled flag, they run in hundredths of a second.

Clearly, interpreted regexps are the winner. Granted, if you’re only dealing with a small number of regular expressions, and you use the compiled flag, the first run time isn’t going to be anywhere near what I’ve shown here with 5,000 regexps. However, even with just a few regular expressions, in .NET, you’ll see me sticking with interpreted regular expressions!

Show the MAX length Requirement Too!

Sun, 12 Jul 2009 02:08:00 -0800

When creating an account online and you need to enter your desired username and password, it's common for there to be a note regarding the minimum number of characters required for a username/password. But the maximum character limit is often omitted in this note. Particularly for passwords, when allowed, I try to make 36 character passwords. My passwords are just random characters of letters, numbers and special characters. Every time I spend 30 seconds creating one of these passwords, I always tell myself I need to get one of those random password generators -- but end up never getting one!

Back to my point -- all sites should be making use of the "maxlength" attribute on a text input element. Not just for usernames/passwords, but for every piece of data that is accepted through a text input. At the very very least, indicating the maximum length in a note next to the input field would be appreciated.

On numerous sites I've registered at (including large sites), there is no note, and there is no maxlength on the input field. I spend my 30 seconds typing in a 36 character password to find out when I click the Submit button that the password is too long. In a couple of cases, the site doesn't even tell you the password is too long. They just report "Invalid Password". I'll try shortening it in chunks until they take it.

This may just be a small user experience point, but adding a maxlength attribute takes no time at all and provides immediate knowledge you've reached the max character limit.

Logging & Improved Error Reporting in BlogEngine

Sat, 13 Jun 2009 18:26:00 -0800

There’s two new features in the latest build of BE, 1.5.1.11. These features, Logging and Improved Error Reporting, are separate but related features. I think both features will turn out to be very helpful – especially when trying to diagnose a problem. I’ll explain both features and how they can be used independently of each other, as well as with each other.

Logging

There’s a new event handler in BE that any extension or other component can subscribe to: Utils.OnLog. It can be subscribed to in an extension, like:

Utils.OnLog += new EventHandler<EventArgs>(OnLog);

In this case, there’s an OnLog event handler that will fire every time any piece of code in BE.NET logs a message. I created a simple Logger extension that is now included in BE 1.5.1.11 that subscribes to log notifications, and writes the log message to a logger.txt file in the App_Data folder. Anyone can write a similar extension that will save log messages to a database. The code for the this new Logger extension can be viewed below.

Logger Extension 1.0 (view code)

#region using

using System;
using BlogEngine.Core;
using BlogEngine.Core.Web.Controls;
using System.IO;
using System.Text;

#endregion

/// <summary>
/// Subscribes to Log events and records the events in a file.
/// </summary>
[Extension("Subscribes to Log events and records the events in a file.", "1.0", "BlogEngine.NET")]
public class Logger
{
    static Logger()
    {
        Utils.OnLog += new EventHandler<EventArgs>(OnLog);
    }

    /// <summary>
    /// The event handler that is triggered every time there is a log notification.
    /// </summary>
    private static void OnLog(object sender, EventArgs e)
    {
        if (sender == null || !(sender is string))
            return;

        string logMsg = (string)sender;

        if (string.IsNullOrEmpty(logMsg))
            return;

        string file = GetFileName();

        StringBuilder sb = new StringBuilder();

        lock (_SyncRoot)
        {
            try
            {
                using (FileStream fs = new FileStream(file, FileMode.Append))
                {
                    using (StreamWriter sw = new StreamWriter(fs))
                    {
                        sw.WriteLine(@"*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*");
                        sw.WriteLine("Date: " + DateTime.Now.ToString());
                        sw.WriteLine("Contents Below");
                        sw.WriteLine(logMsg);

                        sw.Close();
                        fs.Close();
                    }
                }
            }
            catch
            {
                // Absorb the error.
            }
        }
    }

    private static string _FileName;
    private static object _SyncRoot = new object();

    private static string GetFileName()
    { 
        if (_FileName != null)
            return _FileName;

        _FileName = System.Web.Hosting.HostingEnvironment.MapPath(Path.Combine(BlogSettings.Instance.StorageLocation, "logger.txt"));
        return _FileName;
    }
}

Any code within BE.NET, a widget, extension, etc. can now log any message like:

Utils.Log("some message to log");

If more than one event handler is subscribed to the OnLog notifications, each event handler will of course fire. It’s worth noting that Utils.Log() accepts a parameter of type object. The Logger extension is designed to receive messages of a string type (it actually casts the object type parameter to a string type). If Logger receives a non-string type, it doesn’t log the message – because the Logger extension is designed to receive simple string-based messages. If an extension or other piece of code wants to pass a non-string type message to a logger, a different extension could be created that is equipped to handle log messages that are of a type different than string.

If you don’t want logging to take place, either because you don’t want to worry about having a log file that keeps growing, or because you prefer not to store data in the App_Data folder (as the Logger extension does), you can simply disable the Logger extension on the Extensions tab in the control panel. As of right now, even if you leave the Logger extension enabled, there’s going to be virtually no messages logged as there isn’t any code that currently calls Utils.Log().

This new logging feature is going to help keep track of events going on. Although logging can be used for many purposes, one of the reasons I wanted to have this in BE.NET was to be able to record unhandled errors.

Error Handling & Reporting

There’s now an event handler in the Global.asax file that catches all unhandled exceptions. Up till now, if a 500 server error occurred, you would be redirected to error404.aspx, as defined by the <customErrors> tag in the web.config file. While this is a nice catch-all method to handling errors, people just getting started with BE.NET are often confused why they are seeing a “Page cannot be found” message when they are trying to do something like save changes and an unhandled error occurs -- which they don’t know has occurred when all they see is a “Page cannot be found” message. To be fair, most people just getting started with BE.NET are not getting errors. But some do, and adjusting folder permissions or other settings fixes the errors they are seeing. In order to fix the problem, one must first know an error is actually occurring, and they need to know what the actual error is!

The new Application_Error event handler in Global.asax does up to three things for non-404 errors:

It generates a summary, including details, of the unhandled error that just occurred.
If error logging is turned on (a new option, explained below), it makes a call to Utils.Log(), passing the error summary to any event handlers registered to receive log notifications.
It does a Server.Transfer() to a new error.aspx page in the root of the BE.NET web folder.

For #1, the summary generated includes a stack trace, inner exceptions, and the URL the page occurred on (both Request.Url and Request.RawUrl).

The summary that is generated is stored in the Items collection of HttpContext.Current. Why? When Application_Error in Global.asax does a Server.Transfer to the new error.aspx page, the error.aspx page checks to see if the person is logged in (i.e. if they’re authenticated). If they are logged in, error.aspx will display the error summary generated within Global.asax. The error summary is retrieved out of the HttpContext.Current.Items collection. If the person isn’t logged in, they just see a message similar to error404.aspx, indicating an “unexpected error has occurred”, and the developer will be tortured, blah blah. :-)

Displaying the error details directly on error.aspx for logged in users is helpful for two reasons. (a) Immediate knowledge of the error, and (b) even if the new error logging option is turned off, you still can see the error message in your browser when you’re transferred to error.aspx.

I’ve mentioned this new error logging option twice now. On the Settings tab in the control panel, in the Advanced Settings section, there is a new checkbox labeled “Enable error logging”. By default, it’s turned off. While this is turned off, the only notifications the Logger extension will receive (if you leave the Logger extension enabled) will be messages coming from some piece of code that explicitly makes a call to Utils.Log(). If you turn this new Enable Error Logging feature on, then when an unhandled exception occurs, Global.asax will pass the error details to Utils.Log() for any registered event handlers to deal with.

Result & Extensibility Possibilities

From version 1.5.1.11, any extension, widget or even BE.NET itself can now simply make a call to Utils.Log() to have any message logged. Logging can be done with the built-in Logger extension, or messages can be logged to a database, sent via email, etc. by any other extension someone creates. I’m also very excited about the new error handling mechanism which will give administrators a lot more information about errors that may be occurring in their blog.

Please download and test out the latest build. If any problems show up or you have any ideas for improvements, you can leave a comment here, or post a message on the CodePlex discussion boards.