post.aspx NullReferenceException CS 2.1

Reply

joedave Posted: Mon, Mar 19 2007 6:24 PM

rated by 0 users

Hi everyone,

It seems that browsing to post.aspx results in a NullReferenceException.  I also noticed that browsing to Post.aspx without any query string results in a NullReferenceException with a different stack trace (the latter one below).  There doesn't appear to be any other problems with CS and I can even browse to single blog posts using the archive-format urls, just not with post.aspx.

Does anyone know how I can fix this?  Anyway, what is the purpose of post.aspx and where is the link on my site?  It doesn't appear to be linked and the request is certainly not originating from my browser, so someone found a way to get there.  I recently upgraded CS, so maybe it's just an old link that was cached by a browser or search engine?

I'm on a godaddy shared server and I have access to the CS files.  I'm running ASP.NET 2.0.

Here's the error as it appears in the exceptions report:

User Agent: Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/hel
Path: /blog/blogs/post.aspx?App=blog&y=2006&m=12&d=01&PostName=[any post name] as HTTP GET
Referrer:
Message: Object reference not set to an instance of an object.
System.NullReferenceException: Object reference not set to an instance of an object.
at CommunityServer.Blogs.Controls.EntryViewContainer.BindData()
at CommunityServer.Blogs.Controls.EntryViewContainer.AttachChildControls()
at CommunityServer.Controls.TemplatedWebControl.CreateChildControls()
at System.Web.UI.Control.EnsureChildControls()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Browsing to post.aspx without a query string produces the same exception as above but with a different stack trace.  Here's how it appears in the browser when I request post.aspx without a query string:

[NullReferenceException: Object reference not set to an instance of an object.]
   CommunityServer.Blogs.Components.Weblogs.GetWeblog(String applicationKey, Boolean cacheable, Boolean ignorpermissions) +7
   CommunityServer.Blogs.Controls.WeblogTemplatedWebControl.get_CurrentWeblog() +70
   CommunityServer.Blogs.Controls.WeblogThemedControl.get_ThemeName() +7
   CommunityServer.Blogs.Controls.WeblogThemedControl.LoadThemedControl() +32
   CommunityServer.Controls.TemplatedWebControl.CreateChildControls() +58
   System.Web.UI.Control.EnsureChildControls() +87
   System.Web.UI.Control.PreRenderRecursiveInternal() +41
   System.Web.UI.Control.PreRenderRecursiveInternal() +161
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1360

Thanks for your help

Reply

Jose Lema replied on Wed, Mar 21 2007 9:11 PM

rated by 0 users

Hi joedave,

The first thing you should know is that "Yahoo! Slurp" is Yahoo!'s web crawler/spider. So *users* aren't necessarily experiencing any issue. As such, there's nothing to change.

Second, and more as background, since Community Server uses url rewriting extensively requests to one form of url are actually handled by a different one. If you open SiteUrls.config you'll see the following:

<url name = "weblogpostId" location = "weblogs" path="##blogdirectory##archive/{1}/{2}/{3}/{4}.aspx" pattern="##blogName##/archive/(\d{4})/(\d{1,2})/(\d{1,2})/(\d+)\.aspx" vanity="post.aspx?App=$1&amp;y=$2&amp;m=$3&amp;d=$4&amp;PostID=$5" />

In this case, requests to /blogs/[appkey]/archive/[year]/[month]/[day]/[postid].aspx are actually handled by post.aspx (and those values are passed on the querystring).There's also a similar entry for "weblogpostName".

Hope that helps...

Reply

joedave replied on Thu, Mar 22 2007 12:50 AM

rated by 0 users

Hi Jose,

Thanks for the reply - it makes sense.  It seems that the query string variable PostName is causing the problem since archive urls are rewritten to use PostID, and they work just fine.

By any chance is PostName a legacy variable?

My site rewrites requests that are for ~/cs/ to ~/blog/ because I recently updated Community Server and changed the name of the root directory from cs to blog.  I had to do that because I needed the legacy content in the cs directory after the upgrade was installed so that I could copy it, one post and comment at a time, to the new version of CS (godaddy didn't allow access to the original CS database and files).  Unfortunately, I was stuck with /blog/ because godaddy said that the root couldn't be changed.  I thought I could change it to /cs/ after the migration was complete, but that's not the case.  Now my blog url is /blog/blogs/blog.  Ridiculous. 

Anyway, the point is that my site may be rewriting the request from Yahoo's spider for the old version of CS to the new one.  In that case, I'll definitely ignore the exception; otherwise, I'm curious where Yahoo could be getting the PostName variable from.

Thanks for the help

Reply

Jose Lema replied on Thu, Mar 22 2007 1:12 AM

rated by 0 users

joedave:

By any chance is PostName a legacy variable?

I apologize for the confusion. In pasting the siteurl I realized (late) that I had pasted in the one for weblogpostId and not weblogpostName. I made a short reference to that but should have re-opened the file and re-pasted the url you're referencing.

In SiteUrls.config, there is indeed an entry for the url format you're seeing:

<url name = "weblogpostName" location = "weblogs" path="##blogdirectory##archive/{1}/{2}/{3}/{4}.aspx" pattern="##blogName##/archive/(\d{4})/(\d{1,2})/(\d{1,2})/([a-zA-Z0-9\-\._]*?)\.aspx" vanity="post.aspx?App=$1&amp;y=$2&amp;m=$3&amp;d=$4&amp;PostName=$5" />

So, yes, it's just Yahoo! and you needn't worry about it.

Again, sorry for the confusion...