I have an issue in updating contents in Umbraco. Whenever I update something in Umbraco, I have to wait at least one hour, sometimes 12 hours to see the changes at front-end.
The only way to see the changes immediately at front-end is "empty the connection string value umbracoDbDSN and refresh the page, then put the connection string back and refresh the page". I have to do everything I update something in CMS.
Do you guys have any idea what is happening here? Thanks.
The problem was. Umbraco was configured to run on load balanced servers on our old servers. I had to turn it off on the new server.
<distributedCall enable="false"> in umbracoSettings.config
What version are you running? When v5 first came out, I had a big problem with that (and solved it like you by touching the web.config to force a reset. Hopefully you are not using v5 (as its been discontinued and has extreme performance issues).
I have not had that problem in any v4.x versions that I can remember; changes should show up instantly after you republish.
Are you running in a standard configuration? Using a webfarm by anyt chance?
Is the ~/App_Data/umbraco.config file being written to on publish? This is the XML cache file that is used in displaying you website.
When you publish a node, the data is serialized into XML, stored in a database table and then written out to the umbraco.config cache.
This could be some kind of permissions issue, if umbraco doesn't have rights to read/write the file. Or you could have a corrupt dll that just isn't writing to it correctly. Or perhaps it's writing it out just fine, but your server is caching you pages in a weird way. Either way, I'd take a look first at the umbraco.config and make sure the data is being written to it on publish.
Related
I am having some recent problems with TFS 2018 that have escaped my ability to troubleshoot. The application runs on a Hyper-V VM hosting Server 2019 and connects to a separate MS SQL 2016 database over on a separate Windows 2019 VM.
A few weeks ago we migrated our database server over to a new machine which, over the course of setting our existing TFS server up to use the new database, required us to run though the TFS setup wizard again.
Everything was fine for about a week when we started to have issues, specifically with the TFS web front-end we use. First we lost various icons on the webpage, with the browsers (Chrome, Firefox, etc). replacing them with rectangles:
A little while after that we lost our project Dashboards, and the whole dashboard page is just blank now. A little while after that, our WIP build/test automation feature also lost its management section of the site.
Other than these things not displaying, things generally "work" - the source control stuff functions, work items can be interacted with, etc. It's just that the interface is clumsier without the icons (which extends to every icon within every work item type, not just the banner I shared) and we can't get our automated test reports without the site's front-end for it. The latter is the real show stopper.
I spent some time troubleshooting and at best was able to figure out a maybe solution for the icon problem: https://social.msdn.microsoft.com/Forums/en-US/c1038468-9d94-473d-a020-254789e9a19b/tfs-2015-update-2-missing-icons?forum=tfsgeneral
This seemed to do the trick for just the icon problem, though some time later they disappeared and reappeared when people were refreshing pages. I'm still unsure if the re-failure was a fluke or not, as we rolled back the VM snapshot the changes were made on shortly after.
Using Chrome's developer tools, it seems like the lack of dashboard data is related to issues retrieving content on the host server for a cause we cannot determine.
Here is what shows up on the DevTool in Chrome for our main project's Dashboard:
What's interesting is the error claims widget.css is either not present or empty. Neither of these are the case as I can find the file and read data in it.
I recognize MIME types as a thing that shows up in IIS but I don't know what to do with the information. Should I be adding .css to the MIME Types list within IIS? Maybe that was set and the wizard reverted it?
Here's what shows up in the Builds section:
Thing is, I don't know what to do with this information. I found some vague hints online from people having similar issues with sites they were themselves coding (which stated the errors in question were red herrings), but this TFS front end is not something I've created and I had not any idea what to do with the information shared.
Does anyone have an idea of what might have gone wrong with the dashboards here? I have run out of ideas and can't figure out a different attack angle to approach this from.
Codekit is so darn slow in reloading files. Why is that and what can I do against it?
I use MAMP3 on Yosemite with Chrome 39. Refresh delay is on 0 seconds.
I just have a bunch of php files and some less. Nothing extraordinary.
And it reloads the files with a delay of about 10seconds.
The LESS files are compiled very fast, but not the page reload. Internet sharing is deactivated.
What else could be the problem?
From time to time there is a message Codekit connection is unstable. But everything is hosted local. How can this be unstable?
Okay. I figured out some things who slow down codekit significantly.
Mistake Nr. 1: Amount of Files
It seems to play a huge role how much files are added per project. My cms lives outside webroot but my less & css live inside webroot. So I threw in the whole project including the cms. This way I had no path conflicts (lazy me). This resulted in about 4000 Files. That is too much for codekit.
Solution: Still throw in the whole project but exclude the cms folders in codekit (Yeah I know RTFM)
Mistake Nr. 2: custom file extension
I started to work with twig files (after php was done) and miraculously browser refresh stoped working. Because Codekit doesn't doesen't seem to know twig. In order to keep Browser reload working one have to add twig into the Generig Page Extensions.
Thats it. Everything works just fine now.
We are in the process of switching our game from our own canvas page, to using the Unity integration on Facebook. However, during our development tests we have occasionally run into a problem where the webplayer binary gets loaded from the browser cache, even though a newer version was uploaded to the server.
Manually clearing the browser cache solves the problem, but that's not exactly a solution we want to present to our users all the time. Previously, when we embedded the unity object ourselves, we also passed in a ?version flag with the url, which would keep it up to date, but we can't exactly do that anymore with integration turned on, unless we manually update the binary location link in our app settings every time we do a build (Kind of a pain in the butt, since the rest of our build process is automated)
Is there any way around this?
Thanks.
We have exactly same problem and I can say only solution is to change the binary file name everytime you made a build but only for your production environment. Here is our solution:
We have development (sandbox mode)and production environment and one app for each one.
For development, we ran everything locally, we have buildpipeline that builds and copies the binary file to appropriate place with the same name always like MyGame.unity3d, and we have set our browsers not to cache anything, that solves the problem for testing.
For production, our buildpipeline constructs the binary name with:
YourGameNameMainVersion.SubVersion.TimeStamp like: MyGame0.3.1006-1004.unity3d and this one is manually set from facebook's app settings page in every build. But this is not a big problem as you won't want to make a new build more than once/twice a day for production.
We've found that all that needs to be done is to add "?version=xxxx"
This works, and perfectly fine. I do now, is only change version (?version=1.52) in main link:
<a href="http://cometoplaynow.com/Labyrinth3D/Labyrinth3D.html?version=1.52">
Have advantages using it:
Changing only 1 number - link is still the same (if people open game from your site)
Savings will stay as it was (if you change .unity3d you will lost PlayerPrefs).
I have started creating my first project with GWT. In first lines of code, it worked normally and I had no need to GWT Compile every time to see a simple change in my browser.
For client changes, a save file was enough and for server a save and refresh server. But now it has stopped working like before.
For the smallest change like adding a "Window.alert("msg")" I need to reGWTCompile the whole project to see it! What could have issued this?
Make sure you're running in DevMode (i.e. have ?gwt.codesvr= in your URL)
Ok, I have a ClickOnce app that I'm testing and I ask the user for a couple of pieces of information the first time they use load the app; Customer Id and Name. I then set the Properties so that they'll be saved across sessions. The property is Properties.Settings.Default["Customer ID"] and similar for name.
So I uninstall the application through control panel and reinstall the application but the settings are still there! I go and find all directories for my application and delete out the settings but the application acts like it still has them. I can even step through the debugger and see that they are still there.
How do I get rid of them all? This is very frustrating since it makes it almost impossible to test new data and to debug any first time installs.
Thanks...
I believe the user config values are stored in this location:
%APPDATA%\<AppName>\<AppName><AppConfigName_GUID>\<AssemblyVersion>\user.config
Have you checked there?
ok, in case anyone has the same problem in the future. I had set the properties in Visual Studio through the Settings.settings editor. I removed them and everything was normal again...
In answer to the general problem of removing settings when the program is reinstalled, you could add unique piece of data as well, such as the date of the executable, its checksum, or something similar.
Then check that against the saved data when you program starts. If they don't match, it's a reinstall and you can delete the stored data.