The problem I'm having is that Umbraco doesn't seem to reload my controller.js script for ny custom datatype. It loads once (initially), however any changes I make to the script from then on aren't applied - it's as if the script isn't updated within Umbraco following the first time the plugin/datatype is seen by Umbraco.
I've tried recycling the app pool, resetting the application, resetting the server, publishing the website, etc, etc, and nothing seems to work.
"Google Chrome has notoriously aggressive caching, so if something doesn't seem to work well in the backoffice, make sure to clear cache and cookies thoroughly (for other browsers as well).
One way to nudge the cache in Chrome is to open the developer tools (F12) and go to the settings (the cog icon). There will be a checkbox that says "Disable cache (while DevTools is open)". Once this checkbox is on you can refresh the page and the cache should be invalidated. To force it even more, the "reload" button next to your address bar now has extra options when you right-click it. It should have "Normal reload", "Hard reload" and "Empty cache and hard reload" now. The last option is the most thorough and you might want to try that."
Now I experienced the same problem in an Umbraco 7.2.4 solution and came up with another solution.
In my manifest file, I added an url parameter to the reference to the controller, which triggered Umbraco to use the new version of the file. See example beneath using the manifest file from the tutorial which Dacre referenced. Under "javascript" you can see the edited url - hope this can help someone!
{
//you can define multiple editors
propertyEditors: [
{
/*this must be a unique alias*/
alias: "My.MarkdownEditor",
/*the name*/
name: "Markdown editor",
/*the html file we will load for the editor*/
editor: {
view: "~/App_Plugins/MarkDownEditor/markdowneditor.html"
}
}
]
,
//array of files we want to inject into the application on app_start
javascript: [
'~/App_Plugins/MarkDownEditor/markdowneditor.controller.js?v=24-03-2017'
]}
@Dacre spent a few hours last night trying to find out why the Spectrum Color Picker wasn't workin in production but was in dev on my local machine - it came down to setting debug=true.
I'm not sure whether it's because web.config was changed, or the actual debug setting but it worked, and that is consistent with the dev environment in that running the site in debug mode seems to clear a lot of the issues around cache. May have to dig into how the cache is implemented in Umbraco - it seems that it's effectively disabled in debug mode on the server side.
Just took a look at your video - seems you've used the same technique to fix this. However, you may need to leave debug=true set - I had turned it on, tried it and noted it works in my browsers, then turned it off thinking that it was fixed. Client rings up saying it still isn't working, turn it back on again and then it works for them.
My guess is that turning debug=true on is changing the behaviour of umbraco (or rather ASP.Net) in the way it sends it's headers/cookies to the client which is effectively having the client cache things differently. Or, alternatively, the server is caching the files it serves, but debug=true is effectively bypassing the cache. Setting debug=false may be telling the server it can resume using it's cache, but that cache isn't being updated and is stale. I like to think that's the more likely scenario.
I just got a similar issue in Umbraco with a custom made Section.
Despite the staging environment and the live environment having the same JS/HTML/CSS files for my Section, the backoffice looked different on live.
Having the cache disabled in Firefox did not help resolve this on its own.
I found that setting debug to true on live fixed the problem.
What I have discovered is that the JS files which I have written don't seem to load with debug=true. My theories are:
a dependency handler is minifying all of the required files to load an Umbraco section and is serving it all out in one big file
or the required files are loaded the first time Umbraco is opened, and Angular is doing some kind of special caching (which can't be influenced by disabling the cache in the browser)
To fix the issue I changed my package.manifest for my Section and appended a query string (?v=1.1) to each of the files which were required. I then restarted the website (a web.config change or IIS App Pool restart should do this) and the issue was fixed. Looking at what files were loaded in my dev tools, I can now (for some reason) see that my packages files are being loaded with the query string (even though they weren't showing before).
Can't reload AngularJS Controller for custom data type
I'm relatively new to AngularJS and I'm trying to make a simple extension to Umbraco 7.0.4 by creating a custom data type.
I've followed this guide: http://umbraco.github.io/Belle/#/tutorials/CreatingAPropertyEditor and have made a simple datatype.
The problem I'm having is that Umbraco doesn't seem to reload my controller.js script for ny custom datatype. It loads once (initially), however any changes I make to the script from then on aren't applied - it's as if the script isn't updated within Umbraco following the first time the plugin/datatype is seen by Umbraco.
I've tried recycling the app pool, resetting the application, resetting the server, publishing the website, etc, etc, and nothing seems to work.
Please help me!! :-)
Hello,
This is probably a cache problem. More info in the release note: http://our.umbraco.org/contribute/releases/704
"Google Chrome has notoriously aggressive caching, so if something doesn't seem to work well in the backoffice, make sure to clear cache and cookies thoroughly (for other browsers as well).
One way to nudge the cache in Chrome is to open the developer tools (F12) and go to the settings (the cog icon). There will be a checkbox that says "Disable cache (while DevTools is open)". Once this checkbox is on you can refresh the page and the cache should be invalidated. To force it even more, the "reload" button next to your address bar now has extra options when you right-click it. It should have "Normal reload", "Hard reload" and "Empty cache and hard reload" now. The last option is the most thorough and you might want to try that."
Also set debug=true in the web.config.
Jeroen
Now I experienced the same problem in an Umbraco 7.2.4 solution and came up with another solution. In my manifest file, I added an url parameter to the reference to the controller, which triggered Umbraco to use the new version of the file. See example beneath using the manifest file from the tutorial which Dacre referenced. Under "javascript" you can see the edited url - hope this can help someone!
Hi Jeroen, thanks so much for the help!
This solved it:
I'm not sure why this works though?
@Dacre spent a few hours last night trying to find out why the Spectrum Color Picker wasn't workin in production but was in dev on my local machine - it came down to setting debug=true.
I'm not sure whether it's because web.config was changed, or the actual debug setting but it worked, and that is consistent with the dev environment in that running the site in debug mode seems to clear a lot of the issues around cache. May have to dig into how the cache is implemented in Umbraco - it seems that it's effectively disabled in debug mode on the server side.
- Rob.
Just took a look at your video - seems you've used the same technique to fix this. However, you may need to leave debug=true set - I had turned it on, tried it and noted it works in my browsers, then turned it off thinking that it was fixed. Client rings up saying it still isn't working, turn it back on again and then it works for them.
My guess is that turning debug=true on is changing the behaviour of umbraco (or rather ASP.Net) in the way it sends it's headers/cookies to the client which is effectively having the client cache things differently. Or, alternatively, the server is caching the files it serves, but debug=true is effectively bypassing the cache. Setting debug=false may be telling the server it can resume using it's cache, but that cache isn't being updated and is stale. I like to think that's the more likely scenario.
Edit: oops, wrong thread - this is actually in reply to http://our.umbraco.org/projects/backoffice-extensions/spectrum-colour-picker/general/48554-Cant-make-it-works?p=0#comment177403
I just got a similar issue in Umbraco with a custom made Section.
Despite the staging environment and the live environment having the same JS/HTML/CSS files for my Section, the backoffice looked different on live.
Having the cache disabled in Firefox did not help resolve this on its own.
I found that setting debug to true on live fixed the problem.
What I have discovered is that the JS files which I have written don't seem to load with debug=true. My theories are:
To fix the issue I changed my package.manifest for my Section and appended a query string (?v=1.1) to each of the files which were required. I then restarted the website (a web.config change or IIS App Pool restart should do this) and the issue was fixed. Looking at what files were loaded in my dev tools, I can now (for some reason) see that my packages files are being loaded with the query string (even though they weren't showing before).
is working on a reply...