I was wondering about Umbraco.config and figured you would know :).
Long story short, as part of one of my Umbraco project (I am pretty new to Umbraco), I have this .config file as part of my repository and was wondering if I should remove it from there. I am investigating how it gets generated.
What I have learned is that if I start my visual studio solution with no Umbraco.config file it gets generated on the fly. If I go to the backend and republish my whole website, it refreshes it as well with the latest changes in the database.
So that's cool, my conlusion is that I do not need this file in my source control however there is one thing I am not sure I understand and it bugs me.
The umbraco.config file generated at start up differs from the one after I republish the whole site (within minutes after starting my solution). Is this because the first, takes from a default date, while the second checks for the latest?
The umbraco.config file is the XML cache, which is where data is fetched from when you're rendering your pages. It represents each published node from the content tree. So you will need this file to make sure that things are speedy when rendering. You don't want to delete it permanently at all. The umbraco.config file will be updated each time that you save and publish a new page on your site or if you update the content of an exisiting page/node.
Sometimes you will need to refresh the xml cache to make new changes appear on the frontend, which is done by right clicking the "CONTENT" node in Umbraco and choosing the "REPUBLISH ENTIRE SITE" function, which really should be named "Refresh the cache" or something like that because that's what it's doing.
sorry Jan but I have to disagree with the last point :-(
You don't need the file although this is often an area of contention between me and my colleagues. Umbraco creates the XML in the database first, and then the umbraco.config file is created from that. The file is simply a locally cached view of the database, which in itself has additional tables that are caches.
I've had issues when several developers are working on a site at the same time as content is being added. Urls of nodes stop being shown on the properties tab, so the republish all content option is the only way to generate these because my umbraco.config file isn't updated immediately.
I get around this issue by disabling the umbraco.config file. If you open up you config/umbracoSettings.config file in your website, you can add a line to disable the creation of the umbraco.config file. You can find out how to do this by checking out this link.
Caveat Lector: You should only do this during development as it does put the database under considerably more strain since every page property is read from the database directly. This makes the content more timely but at a cost of overall CMS performance. The correct way around this is to setup and enable distributed caching but I prefer this option.
Just delete the umbraco.config file. You'll see the site still works and it will be regenerated if you don't have the caching switched off. It can actually also be used to manually set site values by editing the values in the file and so long as the correct configuration option is enabled, your site will display any changes you make to the file - until the cache is regenerated on the next content publication.
Chris, I think you hit the nail on the head there. It is also an area of contention between me and my colleagues. My current goal is to improve our deployment process.
Moving from our dev environments, to our nightly build, to our staging, to our productions environments. In my mind having the file generated as part of this process, instead of copying it accross is more accurate as it would allow us to spot straight away if there are any issues (and not one day when an editor re-publishes a pages).
I did not now about the possibility to disable the file through umbracoSettings. I will look to see if this could be useful for part of our setups.
Question about Umbraco.config file.
Hi everyone,
I was wondering about Umbraco.config and figured you would know :).
Long story short, as part of one of my Umbraco project (I am pretty new to Umbraco), I have this .config file as part of my repository and was wondering if I should remove it from there. I am investigating how it gets generated.
What I have learned is that if I start my visual studio solution with no Umbraco.config file it gets generated on the fly. If I go to the backend and republish my whole website, it refreshes it as well with the latest changes in the database.
So that's cool, my conlusion is that I do not need this file in my source control however there is one thing I am not sure I understand and it bugs me.
The umbraco.config file generated at start up differs from the one after I republish the whole site (within minutes after starting my solution). Is this because the first, takes from a default date, while the second checks for the latest?
Hi Alex
The umbraco.config file is the XML cache, which is where data is fetched from when you're rendering your pages. It represents each published node from the content tree. So you will need this file to make sure that things are speedy when rendering. You don't want to delete it permanently at all. The umbraco.config file will be updated each time that you save and publish a new page on your site or if you update the content of an exisiting page/node.
Sometimes you will need to refresh the xml cache to make new changes appear on the frontend, which is done by right clicking the "CONTENT" node in Umbraco and choosing the "REPUBLISH ENTIRE SITE" function, which really should be named "Refresh the cache" or something like that because that's what it's doing.
So yes you do need this file :)
/Jan
sorry Jan but I have to disagree with the last point :-(
You don't need the file although this is often an area of contention between me and my colleagues. Umbraco creates the XML in the database first, and then the umbraco.config file is created from that. The file is simply a locally cached view of the database, which in itself has additional tables that are caches.
I've had issues when several developers are working on a site at the same time as content is being added. Urls of nodes stop being shown on the properties tab, so the republish all content option is the only way to generate these because my umbraco.config file isn't updated immediately.
I get around this issue by disabling the umbraco.config file. If you open up you config/umbracoSettings.config file in your website, you can add a line to disable the creation of the umbraco.config file. You can find out how to do this by checking out this link.
Caveat Lector: You should only do this during development as it does put the database under considerably more strain since every page property is read from the database directly. This makes the content more timely but at a cost of overall CMS performance. The correct way around this is to setup and enable distributed caching but I prefer this option.
Just delete the umbraco.config file. You'll see the site still works and it will be regenerated if you don't have the caching switched off. It can actually also be used to manually set site values by editing the values in the file and so long as the correct configuration option is enabled, your site will display any changes you make to the file - until the cache is regenerated on the next content publication.
Thank you guys for your input.
Chris, I think you hit the nail on the head there. It is also an area of contention between me and my colleagues. My current goal is to improve our deployment process.
Moving from our dev environments, to our nightly build, to our staging, to our productions environments. In my mind having the file generated as part of this process, instead of copying it accross is more accurate as it would allow us to spot straight away if there are any issues (and not one day when an editor re-publishes a pages).
I did not now about the possibility to disable the file through umbracoSettings. I will look to see if this could be useful for part of our setups.
You two have a good weekend.
-Alex.
is working on a reply...