Issue with Godaddy + multiple blog with single hosting account

Topics: Business Logic Layer
Dec 4, 2008 at 4:05 PM
Hello everyone,

I have a hosting account with godaddy which provides an option to host multiple domains with single hosting account...
Here is the issue...

My parent site
root - 
       - [debuganalyzer]

root points to awesomeideas.net and runs blogengine with XML data store
folder [debuganalyzer] under that points to debuganalyzer.net and runs blogengine with SQL data store

Everything works fine but with a small trouble. All the links (post/pages) have folder name with the links
http://www.debuganalyzer.net/debuganalyzer/post/2008/11/18/test-page-to-see-the-comments.aspx

This looks like something to do with URL rewriting but unable to trace it. I would like to remove the folder name [debuganalyzer] appearing in the link for debuganalyzer.net site

I'm even ready to hard-code or make changes in code to achieve this. Don't have enough time to debug it :(
Any help is highly appreciated. Thanks in advance!
Coordinator
Dec 4, 2008 at 8:19 PM
If you put a basic HTML page in the debuganalyzer folder, can you get to it in your browser like

http://www.debuganalyzer.net/somepage.html

I'm guessing you can't.  I don't know about GoDaddy, but if your account is on IIS7 and the Url Rewrite Module is available, you should be able to set up some rewriting rules with that module.  If the Url Rewrite Module isn't available, there may still be some other Url rewriting technology available at GoDaddy.  http://www.urlrewriting.net may be a possibility too (haven't personally used it).
Dec 5, 2008 at 5:16 AM
Thank you Ben for the response.

To add more details, the hosting is on IIS6

Best part is http://www.debuganalyzer.net/about.aspx works fine but the issue is only with posts/pages which gets into url rewriting from blogengine.

So in short I'm asking the code path where url rewrite gets involved in blogengine where I can patch or fix the issue.
Coordinator
Dec 5, 2008 at 6:48 PM
Hi.  You could make changes in BE, but I think if configured right, then you don't need to make any changes.  Maybe someone else will chime in, but just thought I'd give some more input - or ask more questions :-)

 - Is that about.aspx page in the debuganalyzer folder, or is it in the root folder?

 - Is debuganalyzer a separate website, or is at least a separate web application within your main website?  Or is debuganalzyer just an alias domain that points to the same root folder as awesomeideas.net?

 - Is blogengine installed in both the root folder and a separate installation in the debuganalyzer folder?

 - In the Web.Config file in the debuganalzyer folder, what value do you have for the "BlogEngine.VirtualPath" appsetting?

I'd think that if debuganalzyer is a separate web application, and you have a separate installation of BE in the debuganalzyer folder, and the "BlogEngine.VirtualPath" appsetting in web.config is "~/" then the URL for the pages shouldn't include the debuganalyzer folder in it like you are seeing.

Actually, I just went to your site and it looks like the URL for one of the posts is:

http://debuganalyzer.net/debuganalyzer.net/post/2008/11/16/Website-Coming-Soon.aspx

So there is a "debuganalyzer.net" in the URL, not "debuganalzyer".  I'm wondering where debuganalzyer.net is coming from.  That's not the name of your folder, right?
Dec 6, 2008 at 7:59 AM

- Is that about.aspx page in the debuganalyzer folder, or is it in the root folder?
> both places have the about.aspx and it comes from the correct place and works fine!

 - Is debuganalyzer a separate website, or is at least a separate web application within your main website?  Or is debuganalzyer just an alias domain that points to the same root folder as awesomeideas.net?
> Debuganalyzer is a separate application and the folder [debuganalyzer.net] is under the root folder which has awesomeideas.net

 - Is blogengine installed in both the root folder and a separate installation in the debuganalyzer folder?
>Yes both folders have blogengine and keep in mind the issue is only for posts/pages.

 - In the Web.Config file in the debuganalzyer folder, what value do you have for the "BlogEngine.VirtualPath" appsetting?
>Both sites have
<add key="BlogEngine.VirtualPath" value="~/"/>

and ~/ works fine which is getting used for about.aspx and contact.aspx directly.

The blogengine urlrewrite comes into play only in the case of posts/pages which is where the issue is coming up

So there is a "debuganalyzer.net" in the URL, not "debuganalzyer".  I'm wondering where debuganalzyer.net is coming from.  That's not the name of your folder, right?
>Yes that is the folder name = [debuganalyzer.net] sorry my bad!

Dec 6, 2008 at 2:27 PM
I host multiple domains on godaddy too.  I also get the url along with the folder for the url repeated.  This issue is in Utils.RelativeWebRoot and how godaddy handles it.  From my limited research, the relative web root goes all the way back to your hosting root.  Everything works fine, except the URLs look wierd.  I created a custom page list widget to grap the actual path so the correct URL is used.  For my blog, I noticed the subdomain goes to http://brian.chipsofttech.com/blogs/brian/ showing the folders.  

I too am interested in how others have solve this for hosting multiple domains on GoDaddy.  Thanks for listening.  Brian. 
Coordinator
Dec 6, 2008 at 8:29 PM
Edited Dec 6, 2008 at 8:29 PM
Interestingly, I notice the contact page works with and without the debuganalyzer.net in the URL:

http://debuganalyzer.net/contact.aspx
http://debuganalyzer.net/debuganalyzer.net/contact.aspx

Just an idea ... what if you change the BlogEngine.VirtualPath appsetting to:

<add key="BlogEngine.VirtualPath" value="~/debuganalyzer.net/"/>
Coordinator
Dec 6, 2008 at 8:48 PM
Actually, changing the BlogEngine.VirtualPath appsetting to ~/debuganalzyer.net/ probably won't help since you'll end up getting URLs with debuganalyzer.net in it.

I noticed in GoDaddy help, they have an article on "Set Application Root" in IIS.

http://help.godaddy.com/article/3973

Is the debuganalzyer.net folder already set as an application root?  If not, this might be what you need.
Dec 7, 2008 at 4:22 AM

Ben,

Just FYI, I work as Escalation Engg in MS, but I'm too busy working on the content of the new site and something else going to come up on the site as well (just a small secret).

To answer your question, Yes its set as Application Root and thats why other pages work fine when I give ~/ like the top menu.

Issue here is happening somewhere the URLrewriting is coming into play. And urlrewriting happens for posts/pages only...

I put the question here since this is something others might have also encountered like Brian!
It should be a bug when taking the URL base address for URLrewrite...

Coordinator
Dec 7, 2008 at 5:10 PM
In the BE core code, there is a Post.cs file.  In that, there is a "Links" region where properties for a post's PermaLink, RelativeLink, AbsoluteLink and TrackbackLink are contained.  You can try making modifications there to see if it'll fix the URL issues you're seeing.
Dec 30, 2008 at 6:38 PM
I also found the same problem.
[],
Dec 30, 2008 at 6:43 PM
Same problem here. I have tried every configuration and no success. I host several domains at godaddy and can't get this subdirectory out of the way. Does anybody have a patch?
[]s
Giovanni Bassi
Coordinator
Dec 30, 2008 at 9:45 PM
See this post.

It looks like the problem is when "~/" is passed into the VirtualPathUtility.ToAbsolute() function.

VirtualPathUtility.ToAbsolute("~/");

If that is changed to:

VirtualPathUtility.ToAbsolute("/");

Then the problem *should* be fixed.  At least this is what I gathered from that previous discussion thread.  In the Utils.cs file in the BE core, in the RelativeWebRoot property, VirtualPathUtility is used like:

_RelativeWebRoot = VirtualPathUtility.ToAbsolute(ConfigurationManager.AppSettings["BlogEngine.VirtualPath"]);

You could try changing the BlogEngine.VirtualPath appsetting in your Web.Config file from "~/" to "/", but this may cause other problems.  The other solution would be to change the RelativeWebRoot property in Utils.cs (and recompile the core).  You would want that line above to look like:

_RelativeWebRoot = VirtualPathUtility.ToAbsolute("/");

But, it looks like VirtualPathUtility.ToAbsolute() is also called with a leading, hardcoded ~ (tilde) in some other places within BlogEngine.  The places I see VirtualPathUtility.ToAbsolute() called with a hardcoded tilde value are:

== CORE ==
Utils.cs, RelativeWebRoot property (as mentioned above).
PostViewBase.cs, CategoryLinks function.

== NON-CORE ==
PostView.ascx (in theme folder), VirtualPathUtility.ToAbsolute() is called twice.

In these locations, you could remove the hardcoded ~ in the VirtualPathUtility.ToAbsolute() function calls so it would be / instead of ~/

Or even better would be to create a new appSetting in your Web.Config file, like:

<add key="BlogEngine.GoDaddyVirtualPath" value="/"/>

And replace the hardcoded ~/ values with this new appSetting so it'll be easier to make changes later, if necessary.

Just to see if any of this makes a difference at GoDaddy, you could do a simple test by changing the line below in PostView.ascx in the Standard themes folder (or whatever theme you're using) to see if you get the desired result.

== SNIPPET OF CURRENT TEXT in POSTVIEW.ASCX ==
<a href="<%=VirtualPathUtility.ToAbsolute("~/") + "author/" + Post.Author %>.aspx">

== TRY CHANGING THAT TO ==
<a href="<%=VirtualPathUtility.ToAbsolute("/") + "author/" + Post.Author %>.aspx">
Dec 31, 2008 at 7:42 AM
Godaddy uses third-party url rewrite components to access files on a virtual directory, and this cannot be simply solved by any setting on godaddy's control panel. I have made a modified copy of BlogEngine to solve such specified issue, but all modifications are hard coded so the version is not very new. If you're interest in it, try this patched version:
http://www.codeplex.com/Project/Download/FileDownload.aspx?ProjectName=blogengine&DownloadId=40295 
It's based on BlogEngine 1.4.5.0.
Dec 31, 2008 at 9:30 AM
I spent almost a day playing around with this issue and figured out there are too many places to be changed mainly because VirtualPathUtility.ToAbsolute is used in several places and could not find a easy way out.
I tried this 1st

Function - RelativeWebRoot
_RelativeWebRoot = VirtualPathUtility.ToAbsolute(ConfigurationManager.AppSettings["BlogEngine.VirtualPath"]);
To
_RelativeWebRoot = VirtualPathUtility.ToAbsolute("/");

Errors with

[ArgumentException: The virtual path '/themes/debuganalyzer/site.master' maps to another application, which is not allowed.]
System.Web.VirtualPath.FailIfNotWithinAppRoot() +3199922
System.Web.Compilation.BuildManager.ValidateVirtualPathInternal(VirtualPath virtualPath, Boolean allowCrossApp, Boolean codeFile) +27
System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +104
System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +93
System.Web.Compilation.BuildManager.GetVPathBuildResultWithAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +51
System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) +90
System.Web.UI.MasterPage.CreateMaster(TemplateControl owner, HttpContext context, VirtualPath masterPageFile, IDictionary contentTemplateCollection) +103
System.Web.UI.Page.get_Master() +48
System.Web.UI.Page.ApplyMasterPage() +18
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +685


Also it breaks in a lot of places than I thought (post links, widget rendering etc...). Having little time to spare to find a quick workaround I took the suggestion of BenAmanda (post of 7th Dec)

So here is what I finally did
Added the following inside web.config
<add key="BlogEngine.GoDaddyVirtualPath" value="/debuganalyzer.net/"/>

Modified the following files
Core
\Post.cs

/// <summary>
/// The absolute permanent link to the post.
/// </summary>
public Uri PermaLink
{
get {
// Edits by sukeshak
string AbsoluteWebRootBase = Utils.AbsoluteWebRoot.ToString().Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");
return new Uri(AbsoluteWebRootBase + "post.aspx?id=" + Id.ToString());
}
}

/// <summary>
/// A relative-to-the-site-root path to the post.
/// Only for in-site use.
/// </summary>
public string RelativeLink
{
get
{
string slug = Utils.RemoveIllegalCharacters(Slug) + BlogSettings.Instance.FileExtension;

// Edits by sukeshak
string RelativeWebRootBase = Utils.RelativeWebRoot.Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");

if (BlogSettings.Instance.TimeStampPostLinks)
return RelativeWebRootBase + "post/" + DateCreated.ToString("yyyy/MM/dd/", CultureInfo.InvariantCulture) + slug;

return RelativeWebRootBase + "post/" + slug;
}
}

/// <summary>
/// The absolute link to the post.
/// </summary>
public Uri AbsoluteLink
{
get { return Utils.ConvertToAbsolute(RelativeLink); }
}

/// <summary>
/// The trackback link to the post.
/// </summary>
public Uri TrackbackLink
{
get {

// Edits by sukeshak
string AbsoluteWebRootBase = Utils.AbsoluteWebRoot.ToString().Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");
return new Uri(AbsoluteWebRootBase + "trackback.axd?id=" + Id.ToString()); }
}


\Page.cs
/// <summary>
/// A relative-to-the-site-root path to the post.
/// Only for in-site use.
/// </summary>
public string RelativeLink
{
get
{
string slug = Utils.RemoveIllegalCharacters(Slug) + BlogSettings.Instance.FileExtension;

// Edits by sukeshak
string RelativeWebRootBase = Utils.RelativeWebRoot.Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");

return RelativeWebRootBase + "page/" + slug;
}
}

\Web\Controls/PostViewBase.cs
/// <summary>
/// Gets the comment feed link.
/// </summary>
/// <value>The comment feed.</value>
public string CommentFeed
{
get {
// Edits by sukeshak
string RelativeWebRootBase = Utils.RelativeWebRoot.Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");
return RelativeWebRootBase + "syndication.axd?post=" + Post.Id; }
}


Web
\App_Code\Controls\CategoryList.cs

private HtmlGenericControl BindCategories()
{
SortedDictionary<string, Guid> dic = SortGategories();
if (dic.Keys.Count == 0)
{
HtmlGenericControl none = new HtmlGenericControl("p");
none.InnerText = "None";
return none;
}

HtmlGenericControl ul = new HtmlGenericControl("ul");
ul.ID = "categorylist";

// Edits by sukeshak
string RelativeWebRootBase = Utils.RelativeWebRoot.Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");

foreach (string key in dic.Keys)
{
HtmlGenericControl li = new HtmlGenericControl("li");

if (ShowRssIcon)
{
HtmlImage img = new HtmlImage();
img.Src = Utils.RelativeWebRoot + "pics/rssButton.gif";
img.Alt = "RSS feed for " + key;
img.Attributes["class"] = "rssButton";

HtmlAnchor feedAnchor = new HtmlAnchor();


// Edits by sukeshak
feedAnchor.HRef = RelativeWebRootBase + "syndication.axd?category=" + dic[key].ToString();
feedAnchor.Attributes["rel"] = "nofollow";
feedAnchor.Controls.Add(img);

li.Controls.Add(feedAnchor);
}

int posts = Post.GetPostsByCategory(dic[key]).FindAll(delegate(Post p)
{
return p.IsVisible;
}).Count;

string postCount = " (" + posts + ")";
if (!ShowPostCount)
postCount = null;

HtmlAnchor anc = new HtmlAnchor();

// Edits by sukeshak
anc.HRef = RelativeWebRootBase + "category/" + Utils.RemoveIllegalCharacters(key) + BlogSettings.Instance.FileExtension;
anc.InnerHtml = HttpUtility.HtmlEncode(key) + postCount;
anc.Title = "Category: " + key;

li.Controls.Add(anc);
ul.Controls.Add(li);
}

return ul;
}

With these few changes I could get almost all relevant links corrected. Although I won't consider as a resolution it's obviously a good/quick workaround without changing any logic of the application.
Will investigate a better way to fix it later.

Don't forget to add the following line in each of those source files
using System.Configuration;

Thanks miller for posting the code changes but I spent enough time to figure out the issue and workaround now that I'll give my way a try.
Although it's not a direct issue with blogengine I would consider using common functions/properties for base url everywhere in the application instead of VirtualPathUtility.ToAbsolute calls in several locations.

Thank you all for your time. If you have any questions do let me know...

Dec 31, 2008 at 11:15 AM
Edited Dec 31, 2008 at 11:20 AM
I am testing and is going very well. Thank you all. Some points that are still without changing

- Home (Link) / Title link
- Archive
- Contact (Link)
- Log In (Link)
- Feed
Category
Month List
Tag Cloud
A suggestion to complement?
[],
Thanks
Dec 31, 2008 at 1:51 PM
Edited Jan 1, 2009 at 3:50 PM
In addition modify the files below changing the path to replace the command as previously described.

ADD:

.Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/")

Ex:
Utils.RelativeWebRoot.Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"],"/");


Files:

Core\MetaWeblogHandler.cs
>GetCategories
Core\SIOC.CS
>WriteSiocPost

Core\PostViewBase.cs
>CategoryLinks
>TagLinks

Web/App_Code/Controls/TagCloud.cs
>RenderControl

Web/widgets/Tag cloud/Widget.ascx.cs
>LoadWidget

Web/APP_CODE/Controls/MonthList.cs
>RenderMonths
Web/Archive.cs
>CreateRowHeader
Web/User Control/PostList.ascx
InitPaging()

Core / Util.cs ==> ADD Method

 

public static Uri AbsoluteWebRootBase // NEW
{
get
{
return new Uri(AbsoluteWebRoot.ToString().Replace(ConfigurationManager.AppSettings["BlogEngine.GoDaddyVirtualPath"], "/"
));
}
}

Edit your Theme  > web/themes/mytheme/site.master
Replace all <%=Utils.AbsoluteWebRoot%> to <%=Utils.AbsoluteWebRoot%>
[],

 

 

 

 

 

 

 




Apr 22, 2009 at 9:47 PM
What would be incredibly super duper is if there was a working copy of a modified BlogEngine codebase that does all this.  I've tried modifying a brand new BE code base several times, and each time it falls short of being 100% accurate.  Either the post pages cause a 404 due to the above changes, or something else becomes wonky.

I vote for establishing another code base with a complete set of understandable instructions on the changes made.  Once that is in place, perhaps the devs can take a look at creating an admin control for this type of scenario.  I've tried, and the Url stuff is just blowing my mind.  My jedi skills suck at this particular problem.

This really sucks for me, because I'm now paying for two hosting accounts.  The second one is an unlimited GoDaddy, where this problem showed itself to my own eyes.  Not only that, but my own efforts to get this working have failed thus far.

Is there someone that can help with this?  Let's get this organized!

Cheers!

Wayne
Apr 22, 2009 at 10:47 PM
As wide-ranging as the problem is (given GoDaddy's in-house manipulation that messes up ToAbsolute) if it were me, I'd create an extension that hooks into the HttpApplication.BeginRequest event that applies a custom stream to HttpContext.Current.Response.Filter so I could parse the output itself (likely using RegEx because you can probably find a decent RegEx expression that'll find anchor tags for you). That way you don't have to edit the source code and it'll work for any release of BlogEngine.Net that continues to support extensions. It also makes it easy for beginners to apply because you can put GoDaddy's subdirectory into the extension settings so it is configurable.
Apr 24, 2009 at 5:02 PM
That's the best idea I've heard so far (of course, I've been talking to myself).

I will pay someone to help me get this extension written.  I'm in serious need of this and, of course, I'm buried in projects right now.  This is a side thing, but still very important to me personally.

Any takers?  What would be an acceptable amount of US $ for the dev of this?

Wayne
Apr 25, 2009 at 12:47 AM
After a little experimentation: extensions don't do well hooking into application events (at least not on IIS 7 where integrated mode means that you don't have an actual instantiated application when Extensions are loaded). Maybe hooking into Page.Serving and Post.Serving is adequate, though. I've created an Extension that seems to work using those events and a filter on the Response. I'd attach it here, but I just realized that I can't attach files to a discussion. I've put it on my site, but no guarantees how long it'll stay available.
Apr 25, 2009 at 6:19 PM
That's awesome Proffitt, I've got it and will mess around with it after I upgrade a few sites to 1.5.

Would you like me to package this up and place it on the extensions category on BlogEngineTheme.com?  I know many, many people and sites that would benefit from it (SEO).

Thanks mucho!

Wayne
Apr 25, 2009 at 7:24 PM
If you could put it through it's paces on your site and see that it does what you expect it to, that'd be cool. I tested it out as much as I could, but since I don't have a GoDaddy hosting account I couldn't verify that it actually solves the problem. And by all means make it as available as possible. I have no problem with tossing this into the world for broader use. Maybe I'll turn it into a blog post myself in a bit...

Jacob
Apr 26, 2009 at 10:23 PM
Having an issue getting it all set up.  The extension page is blowing up because I don't have any data yet.  Could you toss me a sample bit of data, which I presume would be in App_Data/datastore/extensions/ModifyLinks.xml.  If I need to do something else, call it out.  I tried it on 1.4 and 1.5.

I'm actually stuck until I get past this.  At first glance the code looks like it will do it's thing. Let me know what you think.

Thanks!

Wayne
Apr 26, 2009 at 11:09 PM
Edited Apr 26, 2009 at 11:10 PM
My fault. It's a matter of getting the parameters correctly configured in the code. I'll see if I can't get that fixed up and a new file uploaded. Likely sometime this afternoon.
Apr 26, 2009 at 11:19 PM
Edited Apr 26, 2009 at 11:23 PM
Okay, I worked it out, I think (it helps if when you create a parameter list, you actually assign it to the settings object...). The same link should have the file (http://scruffylookingcatherder.com/Files/ModifyLinks.zip). Verify that you have version 0.6 if you want to be sure.
Apr 27, 2009 at 4:47 PM
Awesome, I haven't played much with the extensions in that manner, so thanks for doing that.

I've got everything nearly ready to upload to my host and give it a test run.  I'll let you know what happens.  May be a few more days.

Wayne
Apr 27, 2009 at 4:47 PM
Just to make it clear, I installed this extension, and here are the values I used to get it to work. Make sure you include the trailing slashes and change:

domainname.com/godaddydirectory/

To:

domainname.com/

Voila! Thank you very much for this re-writer - it solves the problem beautifully.

Apr 27, 2009 at 5:54 PM
Sure thing, I'm glad it's working. Keep an eye on performace because it's essentially re-buffering and parsing every page as it is served. Also, it'll only work on pages that hit the "Serving" events for Page or Post objects so I'm not sure it'll work in places like the Archives page.
Apr 28, 2009 at 3:12 PM
Initial attempt failed for me.  However, I'm having another issue where the front page post doesn't show, and I can't access the extensions admin page at all.

I don't think it's due to the extension you wrote, guess it could be.  But I'd lean towards something I screwed up along the way. lol

I'll be able to dig deeper into this tonight.


Apr 28, 2009 at 7:40 PM
I made a mistake when I set up the values originally, and it completely broke the site - the opening page was displayed without CSS, and I couldn't browse back to the admin page to fix it. I had to actually delete the record from the be_DataStoreSettings table and do an IISReset, and all was restored after that.

Maybe some sort of value enforcement in the extension that could check to make sure the values look right (that they won't break the site when they're tested on a few pages) before you can commit them to the DB.
Apr 28, 2009 at 8:53 PM
Not a bad idea, rwmnau. It is a dangerous extension in its ability to remap all href attributes on your page (including in the page header--primarily in link tags). Suggestions for useful rules that'd help hedge the potential damage?
Apr 28, 2009 at 10:06 PM
Can you check for the validity of the main default.aspx site using the rewriting rules they've entered? Or maybe check for an admin page using those rules?

Another option is to use some kind of a "failsafe" address - if they go to http://domainname.com/bedotnetfolder/extensionfailsafepage.aspx, it gives them the option to disable that extension, and that link always works. Even if they lose the link, googling for the problem would return instructions, as it returns this conversation pretty quickly when you google for multiple blogengine.net installations on godaddy.

Any other ideas?
Apr 29, 2009 at 7:45 AM
Edited Apr 29, 2009 at 7:48 AM
I like the idea of a failsafe address that resets (removes) the substitution values. I'll give that some consideration. I'm not sure how you'd go about validating the main site, though.
Apr 29, 2009 at 3:37 PM
Edited Apr 29, 2009 at 3:43 PM
When the user hits "Save", could the extension, as part of the validation, grab the current URL (the extension settings page), pass it through the new rules, and confirm that it's still a valid address? You could use HttpWebRequest to do it:


For example:

' Initialize the WebRequest.Dim myRequest As WebRequest = WebRequest.Create(PassThroughTheRuleTheyJustCreated(Request.ServerVariables["URL"] )' Return the response. Dim myResponse As WebResponse = myRequest.GetResponse()
If myResponse.StatusCode = 200 Then Page still exists - you're safe'
End If

If, after passing through the rule that was just created, the URL for the current page is still valid (returns an HTTP 200), then there's a good chance the rule they've created is okay. It might still be good to have a "failsafe" page, but if you think this is possible, it would provide protection against a rule that breaks the whole site. Does that make sense?
Apr 29, 2009 at 4:05 PM
Hmmm. That's viable, but I'm afraid it'd increase the overhead of this extension by an order of magnitude (or more). I'm already concerned about the overhead of filtering every request through RegEx. If I do that, I'd want to add a parameter to turn validation on and off (maybe with having it on by default?).
Apr 29, 2009 at 4:22 PM
I see what you're saying. I was thinking that it would only validate it a single time - when the user makes a change to the settings - and then not again until they make another change. That way, the validation code wouldn't need to run on every single request - that would introduce a large amount of overhead for sure.

I'm not sure which segment of the extension actually saves the user values to disk, but I'd expect to put the validation code there, in the same place that it's confirming that you've entered all the properties needed.
Apr 29, 2009 at 11:57 PM
Ah. Extensions don't have a validator or an event that is called when the settings are changed. Not that I could find, anyway. I could do something wonky to try to maintain an independent isChanged state or something, but that makes me feel all icky inside... :)
Apr 30, 2009 at 4:18 PM
You want 'icky'?  lol  I'm not sure if I mentioned above that I have the GoDaddy unlimited domain option, but I hadn't noticed this before.  A new install of BE1.4.5 or 1.5 doesn't seem to work very well.  (note, I had mangled BE down for a very specific use, so had not noticed a full installs behavior on GoDaddy Unlimited)

Failures:
  1. homepage doesn't show any content, even though it should.  The entire content area is missing, however everything else is fine.  It just seems like PostView fails to render anything and results in an empty space.  With the footer bar acting like a turtle-neck sweater choking the sidebar and header....
  2. After logging in, clicking the Extensions link in the admin link list results in a postback that takes you to the homepage (see #1).  I also noted that the menu item "Ping Services" shows up on the list only after clicking an admin menu item.
  3. Of course, the url issue that is being addressed here.  I tried the extension, and hacking around it due to #2, but I don't see any change in the urls at all.  Could be something else (1 or 2) impacting this.
This happens on both 1.4.5 and 5.0 straight out of the box with no changes to the code at all.  I don't have an older version to test with, so I can't speak to those versions.

I'm not entirely sure what I can do to fix this since, of course, everything works fine locally, but then fails once it's up on the server.  Without resorting to dumping errors to the screen, I don't have my head around this well enough to get me out of the trial and error approach to debugging it.

I would be more than happy to create an account to use for testing.  In fact, I have a good relationship with some people at GoDaddy, perhaps they would offer a free account for the use of testing. 

The way they do unlimited hosting is killing me...either I need to close the account, change BE to work with them, or roll my own.  Neither of these sound like something I want to spend my Saturday doing.

You guys have any ideas?  I'm all ears.

Thanks,

Wayne
Apr 30, 2009 at 4:21 PM
I'd be happy to help test if you get an account setup for it. Send details through my contact info here?

Jacob
May 11, 2009 at 9:24 PM

Any news on this topic?

I have tried some of the solutions posted here, but most of them seems to work very good with BE 1.5.

 

Any more ideas?

May 12, 2009 at 6:02 AM

One or two of us have successfullly used the extension I posted above. I've gotten together with Wayne, but I got swamped the last couple days/week so I haven't been able to poke at the issue he's seeing yet. :(

Oct 8, 2009 at 2:31 PM

Any updates on a clean way to deal with this? I'm in the same boat, hosting multiple pages off of my godaddy account and suffering from messy url's...

Oct 10, 2009 at 12:58 PM
for client facing pages, I update the urls in the user controls.

for admin, i've been just living with the messy urls. cheaper than
purchasing 1 account per customer. also, be.n is so much better than
what's out there.

On 10/8/09, dumbguy5689 <notifications@codeplex.com> wrote:
> From: dumbguy5689
>
> Any updates on a clean way to deal with this? I'm in the same boat, hosting
> multiple pages off of my godaddy account and suffering from messy url's...
>
>
Aug 30, 2010 at 6:17 PM

My setup:

One website:

/

Two IIS applications in sub-folders:

/Application1/

/Application2/

IIS 7 Rewrite module set to map root of Application1Domain.Com to /Application1/, root of Application2Domain.Com to /Application2/.

BlogEngine.Net installed into /Application1/ sub-folder.

Using the core suggested code edits by sukeshak above, got it working. However, the CSS file referenced from the MasterPage file in the themes I was using, kept getting replaced. This is due to the CompressCss() method inside of BlogEngine.Core.Web.Controls.BlogBasePage. The same methodology of replacing the physical sub-directory name solves the problem, as this method scans the header section of the ASPX, and modifies the URLs to force the CSS HTTP handler.

Aug 31, 2010 at 12:28 AM
Good stuff.  Thanks for the update.  Brian.

On Mon, Aug 30, 2010 at 2:17 PM, twaldron <notifications@codeplex.com> wrote:

From: twaldron

My setup:

One website:

/

Two IIS applications in sub-folders:

/Application1/

/Application2/

IIS 7 Rewrite module set to map root of Application1Domain.Com to /Application1/, root of Application2Domain.Com to /Application2/.

BlogEngine.Net installed into /Application1/ sub-folder.

Using the core suggested code edits by sukeshak above, got it working. However, the CSS file referenced from the MasterPage file in the themes I was using, kept getting replaced. This is due to the CompressCss() method inside of BlogEngine.Core.Web.Controls.BlogBasePage. The same methodology of replacing the physical sub-directory name solves the problem, as this method scans the header section of the ASPX, and modifies the URLs to force the CSS HTTP handler.

Read the full discussion online.

To add a post to this discussion, reply to this email (blogengine@discussions.codeplex.com)

To start a new discussion for this project, email blogengine@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com




--

Brian Carter, PhD
ChipSoftTech & iAppFusion, Partner
briancarter@ChipSoftTech.com

502.410.4CST (4278) 

Apr 22, 2014 at 1:25 PM
For 2.9 below additional changes I had done

Core

Blog.cs
public string RelativeWebRoot
    {
        get
        {
            //return relativeWebRoot ??
            //       (relativeWebRoot =
            //        VirtualPathUtility.ToAbsolute(VirtualPathUtility.AppendTrailingSlash(this.VirtualPath ?? BlogConfig.VirtualPath)));
            return relativeWebRoot ?? (relativeWebRoot = VirtualPathUtility.ToAbsolute("/"));
        }
    }
Web

Post.cshtml

change line 7 from
string loginUrl = Href(util.relativeWebRoot + "Account/login.aspx");
To
string loginUrl = Href("~/Account/login.aspx");
change line 9 from
if (string.IsNullOrEmpty(returnUrl)) { returnUrl = "util.relativeWebRoot + "admin/#/content"; }
To
if (string.IsNullOrEmpty(returnUrl)) { returnUrl = "~/admin/#/content"; }

index.cshtmk

change line 6 from
string loginUrl = Href(util.relativeWebRoot + "Account/login.aspx");
To
string loginUrl = Href("~/Account/login.aspx");
Most of links are working but still there are some issues with AjaxEditor toolbar buttons not showing up properly