I have deployed a website to a server, the front end of the website works fine, but when I try to login to the backend I only get a white screen. It is umbraco version 7.2.4. The site works fine locally. I think it is a permissions issue, but not quite sure
I ran fiddler on the site and noticed that there were 404 errors on the files inside /umbraco/lib/angular/1.1.5/ for example 404 /umbraco/lib/angular/1.1.5/angular.min.js.
Did a search for "404 /umbraco/lib/angular/1.1.5/angular.min.js" and came across this post
It mentions this issue was caused by UrlScan and following the steps in this page.
I removed urlscan from the isapi filters in iis and the back office worked again
Guys, I'm having the same "white Umbraco backoffice screen" issue with a site, using Firefox (43.0.4). The Umbraco version is: 7.2.8 assembly: 1.0.5675.23466.
Following the previous answers I checked for the URLScan ISAPI filter, but that isn't present at all for the site. Requesting the backoffice in Chrome gives me the logon screen (as it should).
Hereunder a screenshot of the console with script errors and the Fiddler result (no 404's whatsoever...).
Something wrong with minimizing? With bundling? What should I look for?!
Anyone else who might run into this, in my case back-end works fine locally but not on the server upgraded from 7.3.4 to 7.8.1 and was getting the back-end white screen with an error "SCRIPT5022: No module: ngFileUpload" from the dependencyhandler.axd file and so far the only fix that seems to work is having the debug set to true on the server if i set if off back-end goes back to white screen no clue why though :(
I am having the same issue on a local, never-upgraded installation of 7.8.0. It works fine in debug mode, but the backoffice is totally dead when I turn it off.
It doesn't sound like it'll help David, but generally when I get a white screen instead of the back office login it's because some file in /umbraco or /umbraco_client is missing. Delete both folders and replace them with a copy from a fresh install.
If you've got client-side files that only work when debug=true, most likely you have a problem with your configuration of ClientDependency. Check web.config and config/clientdependency.config. The only specific problem I know of is if you're running in a subfolder/virtual directory rather than the root of an IIS site. In that case ClientDependency points to /ClientDependency.axd, but you don't have the handler registered in the root so it's not found. If that's the problem, there's a config setting to change the path.
Well at least its good to know its not directly related to upgrading, in my case i have literally deleted all files in the Umbraco and Umbraco_Client folders and copied them from my local to the server and still the same.
When i done my upgrade replaced all the configs as well and only changed the tree and applications adding back the package items changes and thats all. @Rick what sort of config settings do we need to look for.
Here are all the possible configuration settings. The one I needed was compositeFileHandlerPath. With debug=false check what response you're getting for calls to DependencyHandler.axd. If it's 404 that might be the setting you need as well.
<compositeFiles defaultProvider="defaultFileProcessingProvider" compositeFileHandlerPath="~/DependencyHandler.axd">
<fileProcessingProviders>
<add name="CompositeFileProcessor"
type="ClientDependency.Core.CompositeFiles.Providers.CompositeFileProcessingProvider, ClientDependency.Core"
enableCssMinify="true"
enableJsMinify="true"
persistFiles="true"
compositeFilePath="~/App_Data/TEMP/ClientDependency"
bundleDomains="localhost:123456"
urlType="Base64QueryStrings"
pathUrlFormat="{dependencyId}/{version}/{type}" />
</fileProcessingProviders>
<!-- A file map provider stores references to dependency files by an id to be used in the handler URL when using the MappedId Url type -->
<fileMapProviders>
<add name="XmlFileMap" type="ClientDependency.Core.CompositeFiles.Providers.XmlFileMapper, ClientDependency.Core" mapPath="~/App_Data/TEMP/ClientDependency" />
</fileMapProviders>
Now the only visible difference i can see between the 2 is in the web config the path is just path="DependencyHandler.axd" and in the client dependency config its compositeFileHandlerPath="~/DependencyHandler.axd" not sure it the web config one should be with "~/" as well or should the client on not have that lol.
In my case the error is more a script error in the console log than a 404 not found will try and get the actual error. Just to point out my live environment is a web app on azure could that make or cause some issues maybe?
Umbraco back office white screen
I have deployed a website to a server, the front end of the website works fine, but when I try to login to the backend I only get a white screen. It is umbraco version 7.2.4. The site works fine locally. I think it is a permissions issue, but not quite sure
For those who may get this issue.
Guys, I'm having the same "white Umbraco backoffice screen" issue with a site, using Firefox (43.0.4). The Umbraco version is: 7.2.8 assembly: 1.0.5675.23466. Following the previous answers I checked for the URLScan ISAPI filter, but that isn't present at all for the site. Requesting the backoffice in Chrome gives me the logon screen (as it should).
Hereunder a screenshot of the console with script errors and the Fiddler result (no 404's whatsoever...). Something wrong with minimizing? With bundling? What should I look for?!
Anyone else who might run into this, in my case back-end works fine locally but not on the server upgraded from 7.3.4 to 7.8.1 and was getting the back-end white screen with an error "SCRIPT5022: No module: ngFileUpload" from the dependencyhandler.axd file and so far the only fix that seems to work is having the debug set to true on the server if i set if off back-end goes back to white screen no clue why though :(
I am having the same issue on a local, never-upgraded installation of 7.8.0. It works fine in debug mode, but the backoffice is totally dead when I turn it off.
I am too having the same problem,
It doesn't sound like it'll help David, but generally when I get a white screen instead of the back office login it's because some file in /umbraco or /umbraco_client is missing. Delete both folders and replace them with a copy from a fresh install.
If you've got client-side files that only work when debug=true, most likely you have a problem with your configuration of ClientDependency. Check web.config and config/clientdependency.config. The only specific problem I know of is if you're running in a subfolder/virtual directory rather than the root of an IIS site. In that case ClientDependency points to /ClientDependency.axd, but you don't have the handler registered in the root so it's not found. If that's the problem, there's a config setting to change the path.
Well at least its good to know its not directly related to upgrading, in my case i have literally deleted all files in the Umbraco and Umbraco_Client folders and copied them from my local to the server and still the same.
When i done my upgrade replaced all the configs as well and only changed the tree and applications adding back the package items changes and thats all. @Rick what sort of config settings do we need to look for.
Here are all the possible configuration settings. The one I needed was
compositeFileHandlerPath. Withdebug=falsecheck what response you're getting for calls toDependencyHandler.axd. If it's 404 that might be the setting you need as well.Thanks for that so checked my web config got the handler, module and section in all looks good see below
and in the client dependency config got:
Now the only visible difference i can see between the 2 is in the web config the path is just path="DependencyHandler.axd" and in the client dependency config its compositeFileHandlerPath="~/DependencyHandler.axd" not sure it the web config one should be with "~/" as well or should the client on not have that lol.
In my case the error is more a script error in the console log than a 404 not found will try and get the actual error. Just to point out my live environment is a web app on azure could that make or cause some issues maybe?
We're on Azure too and just use the standard clientdependency.config.
Ok debugging a live site now :(, so the error i am getting is below:
Changed the web config to also use the path="~/DependencyHandler.axd" and now got a new error lol, from the /umbrao/application below:
As well as a few 404s and 500s for the dependencyhandler.axd looks liek it def doesnt like that either lol.
is working on a reply...