This project is read-only.

Uh, do themes actually work in this app?

Topics: Controls, Themes
Jan 27, 2008 at 9:12 AM
So could anyone enlighten me as to what would cause the themes to work only when they are specified as a Querystring value (i.e., during theme preview) and not when the value is actually set, even when the values read the same on the same request? That would be nice to figure out.
Jan 27, 2008 at 9:22 AM
so, this gets emitted (and fails to work) when there is not a theme added to the querystring:
<link rel="stylesheet" href="/blogengine/themes/Indigo/css.axd?name=style.css" type="text/css" />

And this gets emitted when the theme IS added to the querystring:
<link rel="stylesheet" href="themes/Indigo/style.css" type="text/css" />

Different HTML rendered for different conditions - not good. Judging from this, I would guess that nobody tested the application as an IIS application off of a main website. I would suppose that this application HAS to run in the root of a website to execute properly.

Jan 27, 2008 at 9:47 AM
Satarter, BE.NET (and themes) should work in subfolders as well. As long as you've specified in which subfolder in the web.config.

So if your subfolder is blogengine, your web.config includes this snippet:
    <add key="BlogEngine.FileExtension" value=".aspx" />
    <!-- You can e.g. use "~/blog/" if BlogEngine.NET is not located in the root of the application -->
    <add key="BlogEngine.VirtualPath" value="~/blogengine/" />

However, what might solve CSS/theme issues on an external website is using "trim stylesheets" admin-setting.
(Makes all stylesheets of any theme smaller by removing all whitespace at runtime)

Have you tried to disable this setting and/or the web.config value and see how that works out?
Jan 27, 2008 at 10:11 AM
The HTML output is different because the stylesheet compression optimization is specifically turned off while previewing a theme.
Jan 27, 2008 at 12:50 PM
... which otherwise breaks many shared hosted sites due to security restrictions.

That's why most GoDaddy-like customers need to disable this trim option on hosts with a Medium Trust Level.
Jan 27, 2008 at 5:10 PM
MikevZ - you had the answer correct! It was the CSS compression that was causing the issue - so you mention a security restriction here as the cause, would you care to elaborate? What exception is occuring to prevent the style-sheet from being compressed/applied correctly?
Jan 27, 2008 at 6:38 PM
Edited Jan 27, 2008 at 6:39 PM
I was having this problem and my friend Jesse showed me the following trick. You can put the entries below to your web.config file and your site will send you emails with the various errors it encounters. I noticed some issues involving CSS compression as well and this helped me know when it was happening.

<healthMonitoring enabled="true">
<add name="EmailProvider"
subjectPrefix=" Error: "
bufferMode="Notification" />
<add provider="EmailProvider" name="All App Events" eventName="All Errors" />

<smtp from="">
<network host="localhost" />
Jan 27, 2008 at 6:48 PM
Thanks for the info! I will try to apply this, but I am apparently having all sorts of other issues, of which this one described could be a symptom. I can only navigate to admin pages and the login page - dynamic pages are showing up as "File Not Found" - not sure what is causing this. I am running on Vista with IIS 7.0 and using SQL Server Express 2005 SP2.
Jan 27, 2008 at 6:51 PM
At this point, I cannot even figure out how to debug this application to figure out what is happening.
Jan 27, 2008 at 8:20 PM
Satarter, ding ding ding, what's the 1st prize? ;-)

But seriously, let's dive a bit deeper into that security exception.

Most web hosting providers allow ASP.NET only to run in Medium Trust Level.
Typically, they limit file system access to the application's virtual directory structure.

BE.NET retrieves the CSS theme files by such basic file/system access.
This should work as long as the code uses the application path with tildes (e.g. ~/themes).

However, certain code and/or settings (*) access these files via the server's physical path (e.g. D:\Hosting\You\YourApp\),
which causes a security exception in Medium Trust environments.


(*) Deeper technical plunge in case you're interested
BlogEngine.Core.DLL contains the CSSHandler class, which uses Server.MapPath to get the physical path for feeding the StreamReader.
You can find this line in the source code: Core/Web/HttpHandler/CSSHandler.cs and looks like this:
public void ProcessRequest(HttpContext context)
   string file = context.Server.MapPath(Utils.RelativeWebRoot + "themes/" + BlogSettings.Instance.Theme + "/" + context.Request.QueryString["name"]);
   ReduceCss(file, context);
   SetHeaders(file, context);
   if (BlogSettings.Instance.EnableHttpCompression)

If you removed the tilde/~ in the VirtualPath (setting in web.config) the security exception will most definitely occur because the Medium Trust level restricts you from accessing outside the virtual/application path. I'm unsure if that's your case as well. What's your VirtualPath app setting in BE.NET's web.config?
Jan 27, 2008 at 8:41 PM
Edited Jan 27, 2008 at 8:43 PM
Hi Mike - thanks for the responses! I am not sure what the first prize is, but I am sure I am at the tail-end of the pack! :-)

Anyhow, I did not change the virtual path setting inside of the web.config, so it still reads as such:

<add key="BlogEngine.VirtualPath" value="~/" />

However, because none of the dynamically generated pages/posts are appearing there appears to be something else. I recall from previous versions of IIS and ASP.NET, that there is a setting which allows ASP.NET to process dynamic pages without validating if they exist on the file system first. For example, the first post in the site is the default post provided by the BE.NET team. It appears on the front page, but when I attempt to access it, I get a File Not Found at this Url:


Presumably, the request is actually going to the post.aspx page and then the Url is being re-written based upon some dynamically constructed information, but I cannot get that far. I haven't figured out the permalink stuff yet, but I am assuming since this post (and Url) are pulled from the database, it is somehow causing ASP.NET to choke.


Jan 27, 2008 at 9:09 PM
Hi Shane, you're very welcome and our only first prize aim is you to have a fine working BE.NET instance ;-)

Thanks for sharing your VirtualPath and IIS test environment.

Actually, that might be the root of your issues and 404/file not found, looking at your localhost/blogengine part and web.config.
Because your local IIS runs BE.NET as application in a virtual subdirectory (/blogengine/).

Good chance if you update your VirtualPath in web.config to:

<add key="BlogEngine.VirtualPath" value="~/blogengine/" />

... that your links might work correctly.

If it does, just keep in mind to update this setting again whenever you're deploying it to a public site (instead of your local IIS).
I remember it can be a pain to test on the XP/Vista local IIS or the one with Visual Web Developer.

So if you try that, does it fix the issue?

Jan 27, 2008 at 9:23 PM
Mike - it does appear that the links are being generated correctly, so I do not believe the virtual path is the issue here. I was able to solve the CSS issue that started this thread by your earlier post of removing the CSS compression. I had tried the virtual path that you suggested earlier, but to no avail. This is the error that I receive when trying to view this default.aspx using the above entry:

Virtual Path entry:
<add key="BlogEngine.VirtualPath" value="~/blogengine/" />
The file '/blogengine/blogengine/themes/Indigo/site.master' does not exist.

Of course, this makes sense, because the tilda refers to an application root and thus IIS is trying to find an application root named blogengine inside the application root called blogengine.

However, if I remove the tilda from the front of the entry, like so:
<add key="BlogEngine.VirtualPath" value="/blogengine/" />

The default.aspx page will work again, but I am still unable to generate the dynamic pages correctly, and still receive the errors detailed above.

Also, I failed to mention that I am running this site on a Vista machine with IIS 7.0 and Visual Studio 2008... I don't know if this affects anything.


Jan 28, 2008 at 2:30 AM
If you are experiencing some of these issues, please check out the resolution at this post:
Jan 28, 2008 at 11:55 AM
Hi Shane, glad you've fixed your issue in the end! Thank you for posting your full guide to BE.NET on IIS 7.0, very useful!