That does sound strange. I've installed it on a clean version of 7.1.6 and it worked fine. I've also used it on 7.1.3 and it worked, but never actually tried 7.1.4
All that comes to mind is the fact that the WebAPI controller that returns the log-file data inherits from UmbracoAuthorizedApiController - this should ensure that only authorised backend users can call this controller. Now there was an issue in earlier versions of Umbraco were this inheritance didn't work - I've even logged an issue here about it - http://issues.umbraco.org/issue/U4-5354 Maybe that issue somehow affects 7.1.4 ?
Hi! Thanks for your swift response. I've read those issues as well but this should have been fixed in 7.1.4, as fas as I know.
I will update in the near future and am a bit in time pressure now. Let's see if I can alter the sources, thanks for the idea. I will let you know where this goes ;-)
Yup, that was it. Inherited from UmbracoApiController instead of UmbracoAuthorizedApiController and that did the trick.
For this same project I developed two other backend controllers, one inheriting from UmbracoApiController, the other from UmbracoAuthorizedJsonController and that worked all as expected. Now lets find some time to migrate to 7.1.6 :-)
I was just asking because I have seem some issues with IOC containers and 3rd party packages that use API controllers when IOC is not set up correctly.
I've been using 2.2.1 with a number of 7.2.8 sites without experiencing this issue. I also know a fair number of other people are using it without this issue, so I can only guess it's something particular to your set-up... Is there something special about your set-up that might be causing an issues (eg. custom routing, firewall, or something)?
Is there anything in the javascript console to indicate an issue?
Are you able to replicate in a clean install of 7.2.8?
Hmmm, I really don't understand. I know it works on the beta 7.3.0 build as Seb has been using it a lot and I've also tested. All I can think is that there's something in your install that's causing this, but don't really know what.
Not sure if it's related, but when debug="true" is on this disables the use of ClientDependency caching. Could you try deleting the contents of the client dependency cache (in /App_Data and App_Data/Temp/) to see if this makes any difference? Also try clearing browser cache (or using Chrome in dev tools mode with cache disabled).
If anyone can pinpoint something to fix please let me know :)
I'm experiencing the same error and debug='false' does fix it. After upgrading from 7.2.8 -->7.3.0 a few days ago the entire TraceLog package appeared to be missing and I had to reinstall it.
No surprise, but the header of the ng-table is visibly missing when the error is occurring.
I'm still puzzled by this. If I install a default installation of Umbraco 7.3.0 and then add my package from NuGet then it works for me (with debug="false").
Have you tried clearing the ClientDependency cache?
Ok, I pushed my Chrome dev tools debugging skills to limit and found the issue is that Umbraco is clearing the template cache on init which is wiping the templates from ng-table.min.js.
That's fantastic debugging! I'd got as far as figuring it was to do with caching and that the header file was referenced from ng-table.min.js - but hadn't put it all together.
I think I'll point Seb to this thread so we can decide whether this is an Umbraco issue (as it sees to be new behaviour in 7.3.0) or whether it's something that we'll have to work around (such as your suggestion).
One way or another we'll get to the bottom of it :)
Yeah it's was tricky to track down! It's a sort of non bug as it's intentional but it will stop any Angular module that directly uses template caching from working.
OK, thanks to your help Jeavon I've been able to find a workaround for this issue. I found this issue - https://github.com/esvit/ng-table/issues/393 - on the GitHub tracker for NgTable and it gave me an idea.
Cool, that's fab! I think it would be worth you logging a issue on YouTrack as well as other's may hit it when using Angular modules as mentioned in the GitHub issue you linked to.
We haven't changed anything around how angular caches templates in 7.3, the line the jeavon refers to has been in Umbraco for ages - we clear the angular template cache to help developers who build extensions for the back-office, they would otherwise have to deal with really heavy browser-caching (as anyone working with 7.0 can attest!)
The way Angulars template caching works is that you give it a path, it then tries to lookup the path in the cache, if the path is not in the cache, it will load from disk.
So ng-table pretends to load templates from a path that does not exist, which I don't really have a good answer to how we can work with, without taking away the cache clearing that helps anyone else working on back office extensions.
Was there an issue with reaching an api controller as well, or was that solved?
Thanks for your input, it's appreciated it. If it's something that only affects ng-table and nothing else then I can live with the work around.
Though I'm curious to why, if this has been in Umbraco for ages, it only seems to have caused an issue recently?
I've seen a couple of reports about problems with an API Controller, but nothing I can reproduce, and it's been fine for most people. So I don't think that is related.
Beats me, the error reported on ng-table which is caused by the same as our setup is over a year old.
we might be able to something, so that the cache only partially clears, so in case there are app_plugin files there, we clear them, otherwise not, but its not something $templateCache supports OOTB tho.
I was trying to think why it has suddenly changed in v7.3, only thing I could think was that the order of loading/execution has changed between v7.2 and v7.3...?
Request error: The URL returned a 404 (not found)
Installed the package in two Umbraco 7.1.4 installations, however, I get the following red error displayed.
Request error: The URL returned a 404 (not found):
/Umbraco/TraceLogViewer/TraceLog/GetLogData
The URL /Umbraco/BackOffice/TraceLogViewer/TraceLog/GetLogDat, as stated in the controller, returns the right data. How can this be explained?
That does sound strange. I've installed it on a clean version of 7.1.6 and it worked fine. I've also used it on 7.1.3 and it worked, but never actually tried 7.1.4
All that comes to mind is the fact that the WebAPI controller that returns the log-file data inherits from UmbracoAuthorizedApiController - this should ensure that only authorised backend users can call this controller. Now there was an issue in earlier versions of Umbraco were this inheritance didn't work - I've even logged an issue here about it - http://issues.umbraco.org/issue/U4-5354 Maybe that issue somehow affects 7.1.4 ?
If you are comfortable with code then you could get the source from GitHub and modify this file - https://github.com/DanDiplo/UmbracoTraceLogViewer/blob/master/Diplo.TraceLogViewer/Controllers/TraceLogController.cs Instead of inheriting from UmbracoAuthorizedApiController just inherit from a standard API controller. If you need protection add the [Umbraco.Web.WebApi.UmbracoAuthorize] attribute.
That's all I can think. Other things to try would be logging in / out again or restarting the app pool.
Let me know if you get any further...
Hi! Thanks for your swift response. I've read those issues as well but this should have been fixed in 7.1.4, as fas as I know.
I will update in the near future and am a bit in time pressure now. Let's see if I can alter the sources, thanks for the idea. I will let you know where this goes ;-)
Yup, that was it. Inherited from UmbracoApiController instead of UmbracoAuthorizedApiController and that did the trick.
For this same project I developed two other backend controllers, one inheriting from UmbracoApiController, the other from UmbracoAuthorizedJsonController and that worked all as expected. Now lets find some time to migrate to 7.1.6 :-)
That's cool, thanks for letting me know. I might recompile and release a fix, then, if it doesn't work in 7.1.4 - oh the joys! :)
The same problem with Umbraco 7.2.8 and Diplo 2.2.1
Are using any kind of IOC container ?
Dave
Hi Dave,
No IOC containers.
Thanks, Mike
I was just asking because I have seem some issues with IOC containers and 3rd party packages that use API controllers when IOC is not set up correctly.
Dave
Michael,
I've been using 2.2.1 with a number of 7.2.8 sites without experiencing this issue. I also know a fair number of other people are using it without this issue, so I can only guess it's something particular to your set-up... Is there something special about your set-up that might be causing an issues (eg. custom routing, firewall, or something)?
Is there anything in the javascript console to indicate an issue?
Are you able to replicate in a clean install of 7.2.8?
Hello,
Just installed and tried to use your package, and having same error.
Is it possible the issue is related to the fact my Umbraco site is not running at the root of the domain name ?
ex: www.mydomain.com/mysite/myumbracoroot
The error indicates:
Request error: The URL returned a 404 (not found): /Umbraco/Backoffice/TraceLogViewer/TraceLog/GetLogData
But shouldn't it look for data in: /mysite/Umbraco/Backoffice/TraceLogViewer/TraceLog/GetLogData
Or if you have other ideas where might be the issue, please help :)
Peter
Hello,
I just upgraded to Umbraco 7.3 final from the RC and when I try to view the logs of a date I get the following error:
Request error: The URL returned a 404 (not found): ng-table/header.html
Jeroen
Hmm just reverted to the RC and I've still got the error. So it seems it's not related to the upgrade.
Hmmm, I really don't understand. I know it works on the beta 7.3.0 build as Seb has been using it a lot and I've also tested. All I can think is that there's something in your install that's causing this, but don't really know what.
You are free to grab the source code from GitHub and try debugging if that will help: https://github.com/DanDiplo/UmbracoTraceLogViewer
If you find anything definitive let me know!
We are seeing the "The URL returned a 404 (not found): ng-table/header.html" on v7.3 RTM upgrades.
The strange thing is it's requesting this file form the following path "/umbraco/ng-table/header.html"
Yup same error. I think it was also there on the 7.3 RC.
Ok, turn off debug=true and it works, I think it's a relative path issue somewhere
Not sure if it's related, but when
debug="true"is on this disables the use of ClientDependency caching. Could you try deleting the contents of the client dependency cache (in/App_DataandApp_Data/Temp/) to see if this makes any difference? Also try clearing browser cache (or using Chrome in dev tools mode with cache disabled).If anyone can pinpoint something to fix please let me know :)
I'm experiencing the same error and debug='false' does fix it. After upgrading from 7.2.8 -->7.3.0 a few days ago the entire TraceLog package appeared to be missing and I had to reinstall it. No surprise, but the header of the ng-table is visibly missing when the error is occurring.
I'm still puzzled by this. If I install a default installation of Umbraco 7.3.0 and then add my package from NuGet then it works for me (with
debug="false").Have you tried clearing the ClientDependency cache?
Hey Dan,
You need debug="true" to recreate the error.
Do you know where this header.html is coming from, it doesn't seem to be within the package files?
Jeavon
I see it's a cached template within the ng-table.js, I can't work out why it's making a http request for the file...
Ok, I pushed my Chrome dev tools debugging skills to limit and found the issue is that Umbraco is clearing the template cache on init which is wiping the templates from ng-table.min.js.
This is the line causing the issue as you can see it is only executed when in debug mode, hence it working when debug="false"
I'm not sure if this is a Umbraco bug or not....?
You can see the templates being loaded in the template cache here (please note the ng-table v1.0.0 requires Angular v1.2+)
I tired a workaround of downloading the header.html file and editing the path in ng-table.min.js to
It does work but it's not ideal...
Hi Jeavon,
That's fantastic debugging! I'd got as far as figuring it was to do with caching and that the header file was referenced from
ng-table.min.js- but hadn't put it all together.I think I'll point Seb to this thread so we can decide whether this is an Umbraco issue (as it sees to be new behaviour in 7.3.0) or whether it's something that we'll have to work around (such as your suggestion).
One way or another we'll get to the bottom of it :)
Hi Dan,
Yeah it's was tricky to track down! It's a sort of non bug as it's intentional but it will stop any Angular module that directly uses template caching from working.
Certainly one for Seb and Per to think about...
Jeavon
OK, thanks to your help Jeavon I've been able to find a workaround for this issue. I found this issue - https://github.com/esvit/ng-table/issues/393 - on the GitHub tracker for NgTable and it gave me an idea.
Basically in my Angular controller I check for debug mode and then force the templates into the Ng template cache. It's not elegant, but seems to do the trick. See https://github.com/DanDiplo/UmbracoTraceLogViewer/blob/f3f9485bbe49216c40c8e816e4091f50822eaa64/Umbraco7.1.3/App_Plugins/DiploTraceLogViewer/backoffice/diplotracelog/EditController.js
I've updated both the NuGet package and the Umbraco package to 2.2.3
https://www.nuget.org/packages/DiploTraceLogViewer/
Let me know how you get on....
Cool, that's fab! I think it would be worth you logging a issue on YouTrack as well as other's may hit it when using Angular modules as mentioned in the GitHub issue you linked to.
Hi Dan
We haven't changed anything around how angular caches templates in 7.3, the line the jeavon refers to has been in Umbraco for ages - we clear the angular template cache to help developers who build extensions for the back-office, they would otherwise have to deal with really heavy browser-caching (as anyone working with 7.0 can attest!)
The way Angulars template caching works is that you give it a path, it then tries to lookup the path in the cache, if the path is not in the cache, it will load from disk.
So ng-table pretends to load templates from a path that does not exist, which I don't really have a good answer to how we can work with, without taking away the cache clearing that helps anyone else working on back office extensions.
Was there an issue with reaching an api controller as well, or was that solved?
Hi Per,
Thanks for your input, it's appreciated it. If it's something that only affects ng-table and nothing else then I can live with the work around.
Though I'm curious to why, if this has been in Umbraco for ages, it only seems to have caused an issue recently?
I've seen a couple of reports about problems with an API Controller, but nothing I can reproduce, and it's been fine for most people. So I don't think that is related.
Beats me, the error reported on ng-table which is caused by the same as our setup is over a year old.
we might be able to something, so that the cache only partially clears, so in case there are app_plugin files there, we clear them, otherwise not, but its not something $templateCache supports OOTB tho.
I was trying to think why it has suddenly changed in v7.3, only thing I could think was that the order of loading/execution has changed between v7.2 and v7.3...?
Thanks Dan,
I was having the same problem when using MrFlo's Media Editor package. I added your fix to my local copy and it works fine now :D
Ver
https://www.nuget.org/packages/DiploTraceLogViewer/2.2.3 works great on 7.3.0. Thanks guys!
Hi Veronica,
I have applied Dan's fix to my package as well. Thanks Dan!
MrFLo
is working on a reply...