This project is read-only.

Submitting Comments and Contact Forms....goes to home page?

Topics: Core, Customizing Orchard, Troubleshooting
Jan 22, 2012 at 5:19 AM

Whether it's a blog comment or a contact form submitted using the CyberStride.Contacts module, both cases bring me to my home page.

The only errors I say in the logs are the following:

2012-01-21 22:37:01,403 [23] Orchard.ContentManagement.DefaultContentManager - InvalidOperationException thrown from IContentHandler by CyberStride.Contacts.Handlers.ContactHandlerSystem.InvalidOperationException: Having more than one storage filter for a given part (Orchard.ContentManagement.ContentPart`1[[CyberStride.Contacts.Models.ContactPartRecord, CyberStride.Contacts, Version=, Culture=neutral, PublicKeyToken=null]]) is invalid.   at Orchard.ContentManagement.Handlers.StorageFilter`1.Activated(ActivatedContentContext context, ContentPart`1 instance) in C:\Users\John\Source\GE ONE Portal\src\Orchard\ContentManagement\Handlers\StorageFilter.cs:line 41   at Orchard.ContentManagement.Handlers.StorageFilterBase`1.Orchard.ContentManagement.Handlers.IContentStorageFilter.Activated(ActivatedContentContext context) in C:\Users\John\Source\GE ONE Portal\src\Orchard\ContentManagement\Handlers\StorageFilterBase.cs:line 24   at Orchard.ContentManagement.Handlers.ContentHandler.Orchard.ContentManagement.Handlers.IContentHandler.Activated(ActivatedContentContext context) in C:\Users\John\Source\GE ONE Portal\src\Orchard\ContentManagement\Handlers\ContentHandler.cs:line 192   at Orchard.ContentManagement.DefaultContentManager.<>c__DisplayClass6.<New>b__4(IContentHandler handler) in C:\Users\John\Source\GE ONE Portal\src\Orchard\ContentManagement\DefaultContentManager.cs:line 96   at Orchard.InvokeExtensions.Invoke[TEvents](IEnumerable`1 events, Action`1 dispatch, ILogger logger) in C:\Users\John\Source\GE ONE Portal\src\Orchard\InvokeExtensions.cs:line 19


The only thing I can see is that the both of these at the end of their cshtml file has the following:


            <button class="primaryAction" type="submit">@T("Submit Comment")</button>
            @Html.Hidden("CommentedOn", (int)Model.ContentPart.ContentItem.Id) 
            @Html.Hidden("ReturnUrl", Context.Request.ToUrlString()) 

I suspected that this value might not be getting set correctly....but it looks perfect.

 @Html.Hidden("ReturnUrl", Context.Request.ToUrlString()) 

Is it possible that there is bug and it's not reading this somewhere in the core product since Comments is an internal module and ContactUs is done by an entirely different team?

Jan 22, 2012 at 5:28 AM
Edited Jan 22, 2012 at 5:33 AM

More information.  I read a few other posts and found this in the controllers for both:


            return this.RedirectLocal(returnUrl, "~/"); 


returnUrl contains the entire request url like http://localhost:30202/news_contactform

I tried to play with different variations on returnURL like: "news_contactform" or ~/news_contactform without success.  

I looked into the method and found the issue with no idea on how to solve:

This works: "/news_contactform"

Because the criteria in the method is this:

 public static ActionResult RedirectLocal(this Controller controller, string redirectUrl, string defaultUrl) {
            if (!string.IsNullOrWhiteSpace(redirectUrl) 
                && controller.Url.IsLocalUrl(redirectUrl)
                && redirectUrl.StartsWith("/") //THIS IS THE ONE IT FAILS.....normally!
                && !redirectUrl.StartsWith("//")
                && !redirectUrl.StartsWith("/\\")) {
                return new RedirectResult(redirectUrl);
            return new RedirectResult(defaultUrl ?? "~/");




Any thoughts based on this new info?

Jan 22, 2012 at 5:35 AM

Okay it appears this is a bug in the core product which has been fixed.  Please see this issue :


Thanks and I hope this will find someone else.

Feb 10, 2012 at 3:37 PM

Did this actually work for you? I'm having exactly the same problem and I tried downloading the latest version and it made no difference at all as the return url that is in the comment form is always absolute so always fails the islocalurl method.

Feb 10, 2012 at 6:09 PM

I confirm this has been fixed in the 1.x branch. Just remove the failing line if you can't wait.



Feb 10, 2012 at 8:31 PM

Sorted cheers, I was stupidly commenting out the wrong line!

Feb 11, 2012 at 12:56 AM

Yes, this did indeed resolve the issue.