Removing default template from doc type doesn't set template of existing nodes to 0

[jaandrews]

I was getting an error about UmbracoContext.Current being null. I eventually determined that the error occurred because the problem nodes were still connected to a template after I had removed the default template from their doc type (see here for thread about that issue).

I removed the default template from the doc type in order to get the urls tied to the pages to throw a 404 error, as they aren't meant to be navigable. This approach works fine for new nodes, but causes issues when there are already existing nodes.

Reproduction

Bug summary

The assigned templates aren't removed from existing nodes when all allowed templates are removed from their doc type. This leads to errors when attempting getting the url of those nodes and also causes problems when trying to extract certain kinds of information from those nodes, like data in the textarea control. That error may be expected, but since the template isn't 0, there isn't a reliable way to filter out nodes that have had all their allowed templates removed.

Specifics

Umbraco: 7.12.3

Steps to reproduce

1. Create a new doc type with a default template.
2. Create a node using that new doc type.
3. Remove the default template from the new doc type.
4. Save the created node again.
5. Check umbraco config to confirm whether the template attribute still points to the previous default template.

Expected result

When the default template is removed from a doc type, I expect the nodes using that doc type to have template set 0.

Actual result

The nodes continue to point at the old default template.

[kjac]

@jaandrews pretty sure this is by design. What happens if you explicitly delete the old template? (might want to backup the DB first).

[jaandrews]

Deleting it isn't an option, as the template is used by other doc types. I can test, but I doubt doing so would update the template settings if the update to the doc type didn't. I know I can check this via the contentTypeService, but I want to avoid the database call, which an updated template id would do. If this is by design, it would be helpful to a property/method on IPublishedContent to check this, though if it requires pinging the database, that wouldn't be feasible, since the method I'm running into this issue in is called many times on pages it's used on.

However, I don't believe this issue is contributing to the UmbracoContext issue I mentioned in my initial report, as I tried allowing the template again and that didn't mitigate the issue. So this would be more of a feature request than a bug to make checking whether the page has allowed templates simple. Should be low priority though, as this can be worked around with compositions. If this a complete no go, then this task can just be closed as "won't fix."

[nul800sebastiaan]

Hi @jaandrews - I understand what you're trying to do but unfortunately this isn't and won't be supported, we wouldn't want to republish all the nodes you already have after updating a document type, that is a big performance hit on most sites.

If you need this functionality, you're advised to hook into the ContentTypeService.SavingContentType event and update your content from there. Be warned: this can take a long time depending on the number of nodes you have. Make sure to test this thoroughly.

[jaandrews]

That makes sense. Thanks for clarifying the reason.

[TFAstudio]

We accidentally created a template for a Document Type that was not meant to have a template. Before we noticed the mistake, we created many nodes as sub-nodes of a node Document Type that did have a template. The discovery was made when we created an XML Sitemap for search engines, and we noticed that these nodes that should not be appearing were in the list of pages. We discovered our erroneous template, and removed all templates (in this case, only one) from the Document Type.

Like the original poster, we were expecting the TemplateId to become 0 for that node, but the nodes were still appearing in the XML Sitemap. Further debugging showed that the TemplateId for the node did not change - it was still the old TemplateId!.

There is no indication in the Umbraco CMS that this is still bound, nor does this make any sense that there is no way to remove a template id from an existing node without deleting and removing the node, or implementing a hook to the ContentTypeService.SavingContentType event for a singular mistake.

Surely there is a different work-around for this one-off mistake? Surely, Umbraco CMS would indicate that there is some residual Template that is attached to this node that (seemingly!) cannot be removed? While this is an edge case, I hope there are procedures to work around this, but regardless, this is not good User Experience for a content editor. Some indication of this mysterious link should be visible in Umbraco CMS

[Myster]

I cannot remove the template ID, I have exactly the same scenario as TFAstudio, we use the sitemap ID as one method to determine if a node should be in the sitemap. after removing the only templates on a doctype I then tried the following to remove the templateID from the affected 3 nodes I had.

• I tried unpublishing and republishing nodes individually
• deleting then undeleting nodes
• copying nodes even the copy has the erroneous templateID
• I also tried all the buttons on the settings dashboard > published status.
• restarting the application

I don't want to automatically republish nodes after updating a doctype, I don't want the perf hit either.
I am happy to do it manually
I don't even understand where the templateID could be stored that is not affected by at least one of these things I tried.

using umbraco v8.6.1
I've created a new ticket for this very specific issue of not being able to publish manually this node without a templateID here: #9303