This project is read-only.

Upgrade to 1.5 on Mosso: js errors and work-around

Apr 23, 2009 at 2:36 PM
Edited Apr 23, 2009 at 3:22 PM
I need to upgrade a number of blogs to 1.5...  so far I had trouble with the first, which is a shame but there it is. The first problem was some interaction with JQuery which I don't fully understand but which at least I can work around by changing the arcane JQuery syntax somewhat to get the same effect in a different way. That's sorted, but I mention it for completeless.

The remaining problems ... well everything looks ok, and everything works on on my test machine (IIS7 running on Vista, app with default Pipeline, 3.5), but on live (Moasso, IIS7, 3.5), I get the following strange behaviour:
 (1) I bring up a post, say this one:, and I see the following JS error:
BlogEngine is not defined
return;dragableAreaWidth = dragableEleme...gine.addLoadEvent(initdragableElements);
(2) Trying to edit any widget (which works fine on my test machine) gives me the grey screen background, but no pop up. That's kind of weird and definitely broken.

Does anyone have any thoughts on that? I'm sure I've done something wrong, although the non-video upgrade instructions are much easier to follow than the video and I can't think what it is. I nuked everything except the app data and the enclosing directory, so there's no permission error there and the enclosing applciation is unchanged (except on my test machine as noted above).

The web.config file has changed, and I was using one specially set up for IIS7 (see other posts here). Now I have the release web.config (this blog isn't DB based so no issues there). I thought it may be my theme, so I tried the thing with the shipping theme and that's broken in precisely the same way on this target machine, so it's not that.

Any ideas what may cause this error please? I stress this is an upgrade; nothing's changed other than BE from 1.4.5 -> 1.5
Apr 23, 2009 at 4:21 PM
I thought it may be the IIS6/ IIS7 thing with the system.webServer handlers/ modules which has been discussed here before. I know Mosso are on IIS7, but I don't know which pipeline my application (which they created) is using. But... I can make it work either way on my test machine (classic or integrated pipelines), and then I tried every combination of the handlers/ modules from the web.config, all to do avail. I tried explicitly removingf the modules/ handlers from the (standard 3.5) web.config of the parent site, makes no odds.

Anyone got any ideas... looks like I'll have to regress to the previous BE, but I someone else must be using IIS7 and shared hosting...
Apr 23, 2009 at 6:31 PM
It sounds like some files may not have been correctly deployed.  Specifically the blog.js file in the root of the blog.  You might want to check the version got deployed.  It should be 19,167 bytes in size.
Apr 23, 2009 at 8:12 PM
Edited Apr 23, 2009 at 8:23 PM
Thanks - I wondered that earlier too, as it seems like it's not finding the blog.js file, although firebug shows no errors in the network loading.

Anyway, I deleted the file and re-uploaded it from the copy I have on my test machine (which works fine), no soap. I took a new copy from the distribution, still no go. Finally I downloaded the source, took the version from there... but they're all the same file. This is Mosso, so you have to kick the system to clear its internal caches, but I did all that and still no soap - the file's there and it's got all the lines in it, but somehow it's not being found, despite everything loading over http ok.

To get the error, you just display a post and hit "preview" on the comment tab. The JS call to
hits it straight away.

I can't quite screen-shot the firebug list of JS files, but there are four files which are loaded via js.axd, it seems, from Firebug's list. Three look ok - the parameter is a path and those all start with http and the domain name, but the first of the three, that's got no http in the path... strange... the file is:
and when I look at that file with Firebug... it's got nothing in it, an empty file.

So that's my problem I think - the file isn't being loaded. But I don't know why that would be... it's there ok. /BlogEngine.Net/Blog.js is precisely where the file should be (give or take some capitalization), but presumably it should have HTTP and the domain on the front of it somewhere. In fact the other two file loads have http and the domain name right there....   harumph, why no protocol or domain for this one I wonder?

I note again that I'm running this in a subdirectory (as I have since version 1 or whatever we started at), and it's set as an application on both my test server (which works) and my deployment server cluster at Mosso. It's run at Mosso with version 1.4.5 for some time without hassle. But then.. I just looked at one of the other 1.4.5 blogs I run, and that has the same   js.adx?path=%2fBlogEngine.Net%2fBlog.js&v= and that sucker works just fine, *but the difference is that in that case I can see the js in the blog.js file*.

So for some reason the js.axd is not serving content for this specific case, although it does just fine for three other cases on the same page, the only difference being in the missing protocol/ domain for the path parameter here. Ring any bells for anyone?

Apr 23, 2009 at 8:21 PM
The JS.axd handler can retrieve both local and remote scripts.  So the domain & protocol aren't needed.  This is actually normal.

So, the requests for blog.js and widget.js look pretty much the same?


And the widget.js script is coming through, but the blog.js script is blank?

You can try clearing your browser cache, or doing a no-cache refresh in your browser (usually Ctrl-F5) or even try a different browser to see if it makes any difference.
Apr 23, 2009 at 8:29 PM
Thanks, and apologies - I edited that one under your feet, adding the information you just told me (that js.axd works with or without protocol and domain, although the results are different for my deployed machine).

I already have the cache disabled on the browser, although Mosso can be tricksy with caching too; you have to delete a file, try to get it, then put it up there, or it'll not notice it's changed. But in this case, I deleted and uploaded all the files together; I never had an incorrect blog.js file there; the issue is that I'm getting (apparently) zero bytes for that, not an old version or anything. I bounced the server a few times already, which clears Mosso's caches, but still no change.

I use a bunch of browser stuff to diasable the cache there, but I also tried a couple of other browsers (this page: ) and they're all failing in the same way (display the page, press "preview", kaboom, well js error).

As it works fine on my deployment server it's particularlly galling, but at least I only tried it on one unimportant site; I can leave the others at 1.4.5 until I can figure out the problem here. What I can't figure out is that this all worked fine n 1.4.5, and it looks similar enough from FireBug's perspective that it's hard to see what changes could have affected this. Hmm.

Apr 23, 2009 at 10:41 PM
Actually I get an error on page display as above, because the blog.js file isn't being read at all. I can get rid of that error if I manually include the blog.js file via the site.master file for my theme. But that doesn't fix the problem when I press "preview" on a comment.... I don't know the logic of the code here so I'm not sure why that should be.

The "widget.js" file is logically the same but appears to be loaded just fine, although I do have that funny "gray screen" problem with editing widgets, although I get no JS console error there.

I'll post in Mosso support to see if they have any ideas. I don't know which "pool" type they're using, although either type works on my test machine. GoDaddy are not yet on 1.5 so won't be usefu;.

I guess I could create a new site and try a straight install to the top level directory, but I'm sure that works as after all it works ok in a subdirectory on my own IIS7 machine. So that doesn't get me very far forward in any useful direction. I could try disabling all the plug-ins, but again, those don't cause any trouble on my test machine. Perhaps I can find the place in the code where the file's loaded and hard code the path in there, just to make it work.
Apr 23, 2009 at 10:59 PM
If you add a script tag for blog.js directly in the site.master file, like you did, you should be able to preview comments and do everything else.

You can prevent BE from inserting the JS.axd script tag by modifying the BE core and re-compiling it.  In the BlogBasePage.cs file in the Web\Controls folder (in the BE core files), it's being added with the line of code:

AddJavaScriptInclude(Utils.RelativeWebRoot + "blog.js", true, true);

You could remove that and re-compile the core.  Then the script tag you add in your site.master file would look something like:

<script type="text/javascript" src="/BlogEngine.NET/blog.js?v="></script>

If you're still seeing a JS error when trying to preview a comment, what JS error message are you seeing?
Apr 24, 2009 at 8:50 AM
Thanks... If I put the file explicitly in my theme's site.master, then that does get rid of the initial page-load error message about the object not being there, as you'd expect. The remaining problems then are:
(1)  pressing preview or save comment both result in:
BlogEngine.comments.nameBox is null
addComment()(undefined)blog.js?v= (line 59)
onclick(click clientX=186, clientY=604)zlWt2knO...oHQ%3D%3D (line 3)
var author = BlogEngine.comments.nameBox.value;
Which makes no sense to me.

(2) trying to edit a widge then interestingly changes behaviour too, now, I get a dialog box, but with a 404:
Requested URL: /BlogEngine.NET/post/2009/04/17/admin/WidgetEditor.aspx

Hmm. Maybe it's some jquery interaction - I have Jquery in  one extension, although it's all noconflicted and disabling that extension doesn't seem to help. Hmm... it works on the one machine but not the other. I'm sure someone else is running BE on Mosso, so I can't believe it's that. I'll spend another day poking about...

Apr 27, 2009 at 3:00 AM
I have a site on mosso and found this same issue. Perhaps a brute force method, but I didn't recompile the blogengine core or edit my .master file. I just added a reference to the blog.js in the settings section of the control panel, where additional scripts can be added to the <head> section:
<script src="./blog.js" type="text/javascript"></script>
Apr 27, 2009 at 8:33 AM
Edited Apr 27, 2009 at 8:41 AM
That's a much better place to put it, although in my case I have the blog in a subdirectory (an application) so I had to use the full site-relative path of the js file to make the include work.

However, whilst that provides the client with the BlogEngine object, removing the "page load" JS error from the console, it doesn't for me fix the second error, the one I get when hitting "preview" or "save comment".

I wonder if you'd mindn confirming - you have a Mosso blog, BE, and with this one include you can make it work including the ability for people to comment? If so, then the only difference between what you have and what I have is that my BE is in a subdirectory/ application, so that at least tells me where I may need to look for further problems.

It looks like a Mosso specific problem, and it's something to do with the serving of JS files, which is weird. I tried to switch off the minification but that didn't seem to fix it. It looks like this problem:
Apr 28, 2009 at 12:02 AM

In that other thread, William modified the BE core's BlogBasePage.cs file that inserts the <script> tag into the page.  He changed it from

AddJavaScriptInclude(Utils.RelativeWebRoot + "blog.js", true, true);

... to ...

AddJavaScriptInclude(Utils.AbsoluteWebRoot + "blog.js", true, true);

This will insert a <script> tag in the page with an absolute URL to the blog.js file.  So instead of the <script> tag looking something like:

<script type="text/javascript" src="/BlogEngine.NET/js.axd?path=/BlogEngine.NET/blog.js&v="></script>

It instead looks like:

<script type="text/javascript" src="/BlogEngine.NET/js.axd?path="></script>

In this second case, the JS.axd handler sees the 'path' to blog.js is an absolute URL and makes a HTTP request for that file.  In the first case, the JS.axd handler sees the 'path' to blog.js is a relative path and just uses the System.IO classes to open the file up from disk.

The second case using the absolute URL is working for William.  The only "catch" was that the JS.axd handler was getting some junk characters because of the encoding issue mentioned in that thread.  The solution was to explicitly set the encoding to UTF8 in the RetrieveRemoteScript() method.

If you modified the BE core, you could make these two changes and it would probably work for you.  Just a guess ...
Apr 28, 2009 at 9:29 AM
Edited Apr 28, 2009 at 9:45 AM
Thanks Ben, unfortunately I'm running with the freebie developer tools so I can look at the core source but I can't tweak it, at least I think I can't.

However, if there are two ways of serving the file (from the local disk or over http) sounds like a clue as to why things aren't working on Mosson's cluster.

But still, on the work-around... I should be able to make that work. I manually, explicitly, include the blog.js at the bottom of the page, immediately after where the js.axd tries to pull the same thing in. My include has the full path, so should prove the above, right?
<script type="text/javascript" defer="defer" src="/BlogEngine.NET/js.axd?path=%2fBlogEngine.NET%2fblog.js&amp;v="></script>
<script type="text/javascript" defer="defer" src="" ></script>
[update..] Ok, Fiddler2 shows a zero length response for the js.axd call - that's broken right there on Mosso. Then my own manual include (similar to above) returns compressed JS, which appears to work on IE at least. Hmm.
Apr 28, 2009 at 10:09 AM
Ok, thanks - that work-around works, see:
I have some intermittent remaining JS error:   "Permission denied to call method Location.toString"
I can't repeat that.

the problem
If you're using Mosso hosting and you have BE 1.5.07 running as an application in a subdirectory with Integrated Pipeline mode on IIS7, then you may have problems with comment entry.

the work-around
Manually load the required JS file as per this thread.
Apr 29, 2009 at 12:13 PM
Edited Apr 29, 2009 at 12:16 PM
(delete me please)
May 5, 2009 at 10:15 PM
Hi guys,

I had the same issue on Mosso. It was working on my dev machine, but not on live site. I've tried a few things and probably all the above, but the solution that worked for me was very simple:
The first line of the blog.js script:
// global object

Just delete it and thats it!

I hope it helps.

Dmitri @