I know that the integration between umbraco and VS2010 isn't perfect. For example, things linger in umbraco because it stores things in flat files like umbraco.config. In general, when I delete things like document types or make certain kinds of changes to document properties in them, in VS I delete the umbraco.config, clean the solution and rebuilt before running the CMS. After that, I know the db keeps some things around, so I go into the Settings section and delete the approprite document properties, etc.
That said, I haven't yet figured out where umbraco is storing certain master pages/templates since, when I delete certain ones of those, when I clean and rebuild, the files will reappear (thought not included in the project). Can anyone tell me where the reference to these deleted templates lives in the umbraco SiteBuilder code so that I can get rid of them permanently?
A copy of master pages and views are kept in the database, in the cmsTemplate table. It's possible the system keeps rebuilding the missing files based on the record it finds in the database?
With that said, I suppose it's possible if you deleted the template file as well as deleted the corresponding template row in the database, this would work for you, but be very careful of all of the references which may or may not be protected via referential integrity. For example, documents (current published version as well as any older saved versions) relate to templates, as well as document types or cached information of course. So it's probably best to delete through the admin UI whenever possible.
Yeah, the persisting reference had to be in the db or in a flat file somewhere. I hate touching the db directly, so will try deleting through the admin ui first. Though I've noticed that when things have been partially removed in umbraco, that you can get a yellow screen when trying to delete them through the ui. This usually means donning your headlamp and going spelunking through the tables and their foreign keys to eradicate the pest entirely. :-)
Yes, there currently is (as of 6.1.x at least) a strong dependency between the file on disk and a matching row for it in the database. It is recommended to thus always first attempt to delete a template from the admin UI only, just as you must for creating a template as well in order to keep the database in synch. In rare cases, bugs or other types of development scenarios means you might have to spelunk through the DB to clean up templates that won't delete, reassign or nullify references, etc., but is certainly not the recommended approach. (Love your spelunking metaphor on this!)
But now my note for posterity is that this may become simpler in the future; there are plans to one day de-couple the file on disk entirely from the database row, and just use what's on disk, I think. See U4-59 to follow the progress on this.
I found that most of the time, the trouble can be dealt with by going into Settings through the CMS and opening up Templates. There, you will usually find the persisting template file and if you delete it there and from the source in VS after it's creation has been forced by its presence in the db, it will not be re-created. That said, there are times when the CMS won't let you delete the template file. To address it, I attempted to delete the dead templates from cms.Template. There is a foreign key dependency between the nodeId column in that table and the templateId column in cms.Document. However, when deleting all nodes with the templateId matching the dead node's nodeId in cms.Document and then deleting the dead nodes in cms.Template, it broke something because trying to run the site gave me a missing Object reference error. Thank goodness I backed it up. When I figure out the issue, I'll post more.
My approach when dealing with the dreadful foreign key reference error when trying to delete templates through the admin UI, has been to set referencing TemplateID values from cmsDocument to NULL, rather than deleting the row. This is because as you noted, more and more stuff relates to these rows so the easiest approach is to just un-assign the template rather than nuking the document. Although the UI should be pretty good at deleting templates for you, there are still cases where you do run into this error. See U4-2356 for example.
My approach when dealing with the dreadful foreign key reference error when trying to delete templates through the admin UI, has been to set referencing TemplateID values from cmsDocument to NULL, rather than deleting the row. This is because as you noted, more and more stuff relates to these rows so the easiest approach is to just un-assign the template rather than nuking the document/revision. Although the UI should be pretty good at de-referencing these for you when you delete templates, but there are still cases where you do run into this error. See U4-2356 for example.
Template Files Reappearing after Deletion in VS2010
I know that the integration between umbraco and VS2010 isn't perfect. For example, things linger in umbraco because it stores things in flat files like umbraco.config. In general, when I delete things like document types or make certain kinds of changes to document properties in them, in VS I delete the umbraco.config, clean the solution and rebuilt before running the CMS. After that, I know the db keeps some things around, so I go into the Settings section and delete the approprite document properties, etc.
That said, I haven't yet figured out where umbraco is storing certain master pages/templates since, when I delete certain ones of those, when I clean and rebuild, the files will reappear (thought not included in the project). Can anyone tell me where the reference to these deleted templates lives in the umbraco SiteBuilder code so that I can get rid of them permanently?
A copy of master pages and views are kept in the database, in the
cmsTemplatetable. It's possible the system keeps rebuilding the missing files based on the record it finds in the database?With that said, I suppose it's possible if you deleted the template file as well as deleted the corresponding template row in the database, this would work for you, but be very careful of all of the references which may or may not be protected via referential integrity. For example, documents (current published version as well as any older saved versions) relate to templates, as well as document types or cached information of course. So it's probably best to delete through the admin UI whenever possible.
Best of luck!
Yeah, the persisting reference had to be in the db or in a flat file somewhere. I hate touching the db directly, so will try deleting through the admin ui first. Though I've noticed that when things have been partially removed in umbraco, that you can get a yellow screen when trying to delete them through the ui. This usually means donning your headlamp and going spelunking through the tables and their foreign keys to eradicate the pest entirely. :-)
Some added notes for posterity on this:
Yes, there currently is (as of 6.1.x at least) a strong dependency between the file on disk and a matching row for it in the database. It is recommended to thus always first attempt to delete a template from the admin UI only, just as you must for creating a template as well in order to keep the database in synch. In rare cases, bugs or other types of development scenarios means you might have to spelunk through the DB to clean up templates that won't delete, reassign or nullify references, etc., but is certainly not the recommended approach. (Love your spelunking metaphor on this!)
But now my note for posterity is that this may become simpler in the future; there are plans to one day de-couple the file on disk entirely from the database row, and just use what's on disk, I think. See U4-59 to follow the progress on this.
Some further posterior notes:
I found that most of the time, the trouble can be dealt with by going into Settings through the CMS and opening up Templates. There, you will usually find the persisting template file and if you delete it there and from the source in VS after it's creation has been forced by its presence in the db, it will not be re-created. That said, there are times when the CMS won't let you delete the template file. To address it, I attempted to delete the dead templates from cms.Template. There is a foreign key dependency between the nodeId column in that table and the templateId column in cms.Document. However, when deleting all nodes with the templateId matching the dead node's nodeId in cms.Document and then deleting the dead nodes in cms.Template, it broke something because trying to run the site gave me a missing Object reference error. Thank goodness I backed it up. When I figure out the issue, I'll post more.
My approach when dealing with the dreadful foreign key reference error when trying to delete templates through the admin UI, has been to set referencing TemplateID values from cmsDocument to NULL, rather than deleting the row. This is because as you noted, more and more stuff relates to these rows so the easiest approach is to just un-assign the template rather than nuking the document. Although the UI should be pretty good at deleting templates for you, there are still cases where you do run into this error. See U4-2356 for example.
Great. I'll give it a go and report back.
My approach when dealing with the dreadful foreign key reference error when trying to delete templates through the admin UI, has been to set referencing TemplateID values from cmsDocument to NULL, rather than deleting the row. This is because as you noted, more and more stuff relates to these rows so the easiest approach is to just un-assign the template rather than nuking the document/revision. Although the UI should be pretty good at de-referencing these for you when you delete templates, but there are still cases where you do run into this error. See U4-2356 for example.
is working on a reply...