Does anybody have SignalR and Sitecore working together?
There is an issue in Sitecore with hitting the
Application_Start in Sitecore and getting it to kickoff RouteTable.Routes.MapHubs().
I have double checked that I am mapping to my URL/signalR/hubs default on the layouts.
The script blocks for JQuery, JQuery SignalR, and the custom JS are also included.
It pulls everything down fine on the Client Side, except that the URL/signalr/hubs is not mapping.
I have noticed some special handling needed in Sitecore for MVC RouteTables, but these do not directly address the issue currently experienced.
Thanks -
So after so working on this for a bit...
It was the simple thing that makes this work.
You have to add the /signalr and /signalr/hubs to the Ignore Path for SignalR to work with Sitecore.
<setting name="IgnoreUrlPrefixes" value="/sitecore/default.aspx|/trace.axd|.....|/signalr|/signalr/hubs" />
After I got that into place, I was able to see the MapHubs wire up correctly in the Application_Start. It would not consistently hit the break point before since it couldn't provide the URL without trying to get a Sitecore item. Now I see it hit the breakpoint consistently.
Thanks for the responses!
I'm assuming that you are using Sitecore 6.6 as you've mentioned the Sitecore MVC RouteTables. Try using WebActivator to register your hub mappings in the RouteTable. WebActivator gives you options to add this bootstrap code into either a PreApplicationStartMethod or a PostApplicationStartMethod so that you can register your routes and avoid Sitecore's wildcard route taking precedence. I have used this approach to bootstrap Web API routes under Sitecore.
using System;
[assembly: WebActivator.PreApplicationStartMethod(
typeof($rootnamespace$.App_Start.MySuperPackage), "PreStart")]
namespace $rootnamespace$.App_Start {
public static class MySuperPackage {
public static void PreStart() {
// Add your start logic here
}
}
}
An alternative approach would be to add the registration code into a custom pipeline processor and add this processor into the initialize event pipeline in App_Config\Include\Sitecore.Mvc.config
<pipelines>
<!-- Loader -->
<initialize>
<processor type="Sitecore.Mvc.Pipelines.Loader.InitializeGlobalFilters, Sitecore.Mvc"/>
<processor type="Sitecore.Mvc.Pipelines.Loader.InitializeControllerFactory, Sitecore.Mvc"/>
<processor type="Sitecore.Mvc.Pipelines.Loader.InitializeRoutes, Sitecore.Mvc"/>
</initialize>
Related
I am trying to update (using PUT operation) a sitecore item with a 'Rich Text' field with the Sitecore ItemWebApi 1.2. I am running in to an issue with the server saying
"A potentially dangerous Request.Form value was detected from the client"
I could do the validationRequest=false in the web.config. But that will disable the validation for all requests which is not ideal. Is there a way to save html text using ItemWebApi without using the validationReques=false? Seems for aspx pages you could use #Page. Not sure where something like that could be configured in this case.
May be you have already figured out the answer for yourself, but in interest of our fellow community I posting answer here.
Actually myself get struck into this similar issue from last week, but because of your question i found the solution.
By Default Sitecore nowdays comes with
<pages validateRequest="false">
but it is not effective until or unless we do following
<httpRuntime requestValidationMode="2.0"/>
It is also indicated in Sitecore KB article and in another stack overflow answer.
Regards
Vishal Gupta
I did double escaping on client before sending to server and double unescaped with a custom item web api processor to essentially achieve the same effect for this one ajax call. This way, I did not have to turn off validation application wide and had to add the validateRequest=true on all pages. Turning of default html validation would also mean every other developer on our team needs to be aware that html validation is turned off and they have to add special xml on top to enable it. Someone missing that will make our site insecure.
I want to call a LayoutResolver custom pipeline on time of browsing a page.
For that i created a custom pipeline and configured as below
<httpRequestBegin>
<processor patch:after="*[#type='Sitecore.Pipelines.HttpRequest.LayoutResolver, Sitecore.Kernel']"
type="Agents.Common.PipeLines.LayoutResolver, Agents.Common" />
</httpRequestBegin>
But its not working on time of browsing a page but its working when i am clicking any even from sitecore .
How it will work on time of browsing a page.
Based on the patch syntax you provided, it looks like you have configured your LayoutResolver to run after the existing LayoutResolver.
Were you intending instead to replace the existing resolver? Or to run your logic before it?
For replacing, you will want to use patch:instead. For running before the existing resolver, you will want to use patch:before
Regardless of how your processor is configured, the HTTP request begin pipeline executes for most if not all Sitecore requests - even shell ones, which I think is what you refer to in your question.
The easiest thing to start off with would be to verify that the context site is website (or whichever Sitecore site you want to affect) and anything else that might distinguish requests you want (e.g. page mode).
I've recently created an aspx and aspx.cs page that needs to run alongside a sitecore website. Does anyone know how i can add these pages into the site? Our set up is very odd and would like to know recommendations before trying anything and risking breaking our setup.
You don't necessarily have to add your page to the IgnoreUrlPrefixes.
Before the ItemResolver is executed, the FileResolver is executed which checks if your request points directly to a file on disk.
You do need to configure the allowed URL extensions in the FilterUrlExtensions processor of the preprocessRequest pipeline, as such:
<preprocessRequest
<processor type="Sitecore.Pipelines.HttpRequest.FilterUrlExtensions, Sitecore.Kernel">
<param desc="Allowed extensions (comma separated)">aspx, ashx, asmx</param>
<param desc="Blocked extensions (comma separated)">*</param>
</processor>
</preprocessRequest>
So that configuration will allow *.aspx, *.ashx and *.asmx to be requested directly (it's the default configuration in Sitecore 7.0).
If you're using Sitecore 6.6 or lower, the FilterUrlExtensions processor can be found in the httpRequestBegin pipeline.
If you just drop the ASPX page in at the path you'd like it to reside, by default, Sitecore should let it be served as is by going to the corresponding URL.
Just add the pages to the projects as normal (as DustinDavis suggested) but you also need to modify IgnoreUrlPrefixes in web.config (or add a config patch file) and include the pages or folders as pipe delimited values that you want the Sitecore handlers to ignore.
You can configure the value attribute of the
/configuration/sitecore/settings/setting element in web.config with
name IgnoreUrlPrefixes to prevent Sitecore from processing specific
requests, causing ASP.NET to process the request without Sitecore.
From Sitecore Presentation Component Reference
There is more information about the how and why in this blog post by Alex Ahyba
If you have sitecore open in Visual Studio, just add them in to the project. You can access the new page directly.
We're running Sitecore in a multi-site configuration and currently have custom 404 pages for each of our sites.
What we would also like is to have custom 500 pages for each site. I haven't found much on how that works (if it does) in Sitecore, and was hoping the community had some insight into how to set up custom 500 pages in a multi-site Sitecore setup. Currently, we have one 500 page the two sites share. This is fine in development, but in production we don't want to expose the fact that these sites share the same box.
Well as per my knowledge, what you can do is you can directly set a URL to be executed (.i.e. it goes to your common Custom Error Page), where you decide the site-specific error details to be shown.
Considering that you are using IIS 7.0 or 7.5, please follow the steps as below:
Open IIS Manager
Go to your Site, in the Sites Section.
Click on Error Pages in the IIS Section.
Next, you will move to the Error pages set by IIS. Go to Error code 500, select it and click on Edit in Actions Pane.
Now select the option of Execute a URL and select a common page, say /sitecore/MyErrorPage/500ErrorPage.aspx and then, handle site-specific error messages in that particular page.
Hope this Helps!
Regards,
Varun Shringarpure
A 500 error is a server error so Sitecore can't process it. It should be a generic flat HTML file configured is IIS or the web.config
You can override the processor "Sitecore.Pipelines.HttpRequest.ExecuteRequest, Sitecore.Kernel" to handle Sitecore error like item not found, layout not found etc. See more details here: http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2013/04/Handling-Errors-in-the-Sitecore-ASPNET-CMS.aspx
But when handling 500 errors you should do it outside of Sitecore, think about what happens if you serve your 500 error page in Sitecore but Sitecore is down due to for example sql connection issues or timeouts? Your users will end I a redirect loop.
Take a look at the Error Module on the marketplace. I think it will give you want you want.
We have a couple of MVC 3.0 web application some of them combination of Web Form and MVC3.0 within on project/solution.
I'm quiet new to sitecore, could someone please help me understand following in regards to migrating the existing application to Sitecore?
On what type of scenarios should we move MVC3.0 razor views to sitecore?
What are the key gotchas migrating MVC3.0 to sitecore?
Do I need to inject anything on sitecore pipeline?
Do I need to change any of the navigation links to work under sitecore?
Any link to sitecore best practice for migrating existing web app will be good.
I followed the blog below and still unclear why and when should we convert web control and razor views to Sitecore Rendering.
Thank you.
When migrating MVC applications into a Sitecore solution you have a few options available - depending on the nature of the component you are migrating you would have to choose the most appropriate option.
I'll try and address your 5 specific questions:
1. When to use Razor views
I'm not sure if the question is "when to use a Razor view" or if the questions is "when to use Sitecore View Rendering" - I'll assume the latter.
A View Rendering is great if your are writing presentation components that do not require any business logic and only deals with rendering items. If you are contemplating adding code in your Razor view you should probably consider if a Controller Rendering would be more appropriate or perhaps customising the mvc.getModel pipeline.
2. Migration gotchas
Some of the things that may catch you out when migrating a MVC application to Sitecore.
Component based controllers - in MVC you have one controller per page. Sitecore supports the concept of ControllerRenderings that allows you to have multiple controllers on a page (note: there will always be one route controller that can be perceived as the primary).
Item routing - Sitecore has a catch all route that is effective for all paths that map to an item path. Standard MVC routes and "item routes" can happily coexist. Item routes do not currently support route parameters (e.g. you cannot specify {action} or other parameters on the item route).
MVC4 - Currently no official support for MVC4 (this won't hold true for long - but in the meantime have a look at http://herskind.co.uk/blog/2012/10/sitecore-66-mvc4)
Areas - Currently areas are not fully supported.
Not knowing what rendering types to use and when to convert existing functionality into components.
3. Pipeline customisation
You are not compelled to customise the Sitecore pipelines. I can see a few examples where it would be useful to modify pipelines in the context of a migration story. One example I recently talked about at a Sitecore User Group involved adding a ActionFilter globally (through mvc.resultExecuting pipeline) that would inject a ASP.Net MVC application into a Sitecore place holder. In my example I injected the MVC Music Store into a placeholder and had Sitecore control window dressing (headers/footers/menus). This way I could bring my existing MVC application into Sitecore without having to change it much.
4. Navigation links
If your navigation endpoints are Sitecore item routes (e.i. the path to an item on the website) you should use Sitecore's LinkManager to generate the appropriate links. If the endpoints are standard MVC routes RouteLink and ActionLink should work just fine.
I guess without a concrete example the answer will be "maybe".
5. Best practice migration blog post
I'm not aware of any blog posts or articles dealing with Sitecore MVC migration best practice. Keep in mind that full MVC support is a recent addition to Sitecore and not many seen this journey from start to end yet.
Why and when to convert to Sitecore Rendering
You end your question stating that you are still confused about when and why you would convert controls and Razor views to Sitecore renderings. Here are some indicators that something is a candidate for being a Sitecore rendering:
It is a component that can be reused on many pages.
You want to enable Sitecore users to add the component to pages. (think Page Editor)
You want to leverage Sitecore's component level caching.
You want to leverage Sitecore security to restrict who can use/see the component.
You want to control the component with personalisation, rules or run MVT on it.
In the context of MVC here are some indicators that it may not be right to convert something to a Sitecore rendering:
It relies heavily on routing and route parameters.
I'm sure many of the points in this answer could be expanded on and I know that there are no clear cut rules for this - but I hope this answer helps clear up some of the confusion...