Hi everyone, I’m receiving 2 errors, not really sure why...
The website is working ok, the errors don’t seem to effect the site.
All my controllers inherits from SurfaceController.
The web server is locked down, no outbound traffic allowed, I think this could be the issue for the scheduling failing.
Any help or pointers much appreciated.
Tom
2018-11-21 00:03:05,598 [P5932/D2/T27] ERROR Umbraco.Web.Scheduling.KeepAlive - Failed (at "https://:443/umbraco"). System.UriFormatException: Invalid URI: The hostname could not be parsed. at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) at System.Net.Http.HttpRequestMessage..ctor(HttpMethod method, String requestUri) at Umbraco.Web.Scheduling.KeepAlive.
2018-11-21 00:20:27,568 [P5932/D2/T30] WARN Umbraco.Web.Mvc.RenderRouteHandler - The current Document Type home matches a locally declared controller of type ILF.Controllers.HomeController. Custom Controllers for Umbraco routing must implement 'Umbraco.Web.Mvc.IRenderController' and inherit from 'System.Web.Mvc.ControllerBase'.
1) The warning is just that, for a route hijacked controller you would create a controller with the convention:
documentTypeAliasController
and have it inherit from RenderMvcController
and then any requests to a page based on the document type with the specified alias, would be rooted via the controller...
... the warning is therefore that you do have a controller in your codebase that matches that pattern, and Umbraco thinks you are trying to do RouteHijacking so is warning you that you have forgotten to make your custom controller inherit RenderMvcController.
If you want it to go away, then rename your surface controller as ILF.Controllers.HomeSurfaceController...
2) I've done these in the wrong order, haven't I?
With the error, Umbraco needs to be able to make a request to itself, in order to 'keep alive' to enable scheduled publishing to work, the url that it makes this request on is either the first request the site receives after application start up, or can be configured in /config/umbracosettings.config routing element as umbracoApplicationUrl...
... so my guess is if you set umbracoApplicationUrl="https://www.yoursite.co.uk/umbraco" in the routing element of umbracosettings, then your error should disappear.
A RenderMvcController is used for handling (or hijacking) the whole request, for a particular type of page, based on convention, this can be useful if you want to build a custom model for the template, executing code in the controller to add new properties to the 'view model' to send to the template - this approach can make your views less cluttered, and follows more closesly to the MVC paradigm.
https://our.umbraco.com/Documentation/Reference/Routing/custom-controllers
So nothing wrong with using Surface Controllers, and as explained above the error, is just because RenderMvcController route hijacking works by naming convention, and you just have a clash on the name of your Surface Controller, but it's useful to get your head around the differences between the two and when best to use them.
For example if you had a page with 4 or 5 different displays of information that all needed some information from a particular 'Member' you might write 4 or 5 different Surface Controller actions to render the different areas.. (this is a convoluted example) - inside these implementations you might make the call for the same information, eg the underlying Member 4 to 5 times.... in this kind of scenario it is better to route hijack the whole request with a RenderMvcController and get the member info, once, to be shared by the areas of the template, via the underlying viewmodel.
Receiving errors within the log file
Hi everyone, I’m receiving 2 errors, not really sure why...
The website is working ok, the errors don’t seem to effect the site.
All my controllers inherits from SurfaceController.
The web server is locked down, no outbound traffic allowed, I think this could be the issue for the scheduling failing.
Any help or pointers much appreciated.
Tom
2018-11-21 00:03:05,598 [P5932/D2/T27] ERROR Umbraco.Web.Scheduling.KeepAlive - Failed (at "https://:443/umbraco"). System.UriFormatException: Invalid URI: The hostname could not be parsed. at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) at System.Net.Http.HttpRequestMessage..ctor(HttpMethod method, String requestUri) at Umbraco.Web.Scheduling.KeepAlive.
2018-11-21 00:20:27,568 [P5932/D2/T30] WARN Umbraco.Web.Mvc.RenderRouteHandler - The current Document Type home matches a locally declared controller of type ILF.Controllers.HomeController. Custom Controllers for Umbraco routing must implement 'Umbraco.Web.Mvc.IRenderController' and inherit from 'System.Web.Mvc.ControllerBase'.
Hi Tom
1) The warning is just that, for a route hijacked controller you would create a controller with the convention:
documentTypeAliasController
and have it inherit from RenderMvcController
and then any requests to a page based on the document type with the specified alias, would be rooted via the controller...
... the warning is therefore that you do have a controller in your codebase that matches that pattern, and Umbraco thinks you are trying to do RouteHijacking so is warning you that you have forgotten to make your custom controller inherit RenderMvcController.
If you want it to go away, then rename your surface controller as ILF.Controllers.HomeSurfaceController...
2) I've done these in the wrong order, haven't I?
With the error, Umbraco needs to be able to make a request to itself, in order to 'keep alive' to enable scheduled publishing to work, the url that it makes this request on is either the first request the site receives after application start up, or can be configured in /config/umbracosettings.config routing element as umbracoApplicationUrl...
... so my guess is if you set umbracoApplicationUrl="https://www.yoursite.co.uk/umbraco" in the routing element of umbracosettings, then your error should disappear.
regards
marc
Thanks Marco, I have now fixed the issues, can you confirm my understanding is correct...
If I create documentTypeAlias
I then need to create a Controller with the same name as the documentTypeAlias and inherits from RenderMvcController
Thanks again for your help much appreciated.
Hi Tom
It depends on what you are trying to do :-)
You have two different types of MVC Controller in Umbraco.
SurfaceController RenderMvcController
They are used for different things.
SurfaceController is predominantly there to handle 'posting back' of forms but also is useful as a 'ChildAction' to encapsulate some code, and render a partial view from within a template page. https://our.umbraco.com/Documentation/Reference/Routing/surface-controllers
A RenderMvcController is used for handling (or hijacking) the whole request, for a particular type of page, based on convention, this can be useful if you want to build a custom model for the template, executing code in the controller to add new properties to the 'view model' to send to the template - this approach can make your views less cluttered, and follows more closesly to the MVC paradigm. https://our.umbraco.com/Documentation/Reference/Routing/custom-controllers
So nothing wrong with using Surface Controllers, and as explained above the error, is just because RenderMvcController route hijacking works by naming convention, and you just have a clash on the name of your Surface Controller, but it's useful to get your head around the differences between the two and when best to use them.
For example if you had a page with 4 or 5 different displays of information that all needed some information from a particular 'Member' you might write 4 or 5 different Surface Controller actions to render the different areas.. (this is a convoluted example) - inside these implementations you might make the call for the same information, eg the underlying Member 4 to 5 times.... in this kind of scenario it is better to route hijack the whole request with a RenderMvcController and get the member info, once, to be shared by the areas of the template, via the underlying viewmodel.
Hope that helps shed some light anyway!
regards
marc
Thanks again Marc, much appreciated.
Tom
is working on a reply...