Replace NuCache references

Author: sofietoft

15/umbraco-cms/fundamentals/code/source-control.md

@@ -38,7 +38,7 @@ appsettings-schema.json
 # Packages created from the backoffice (package.xml/package.zip)
 /umbraco/Data/CreatedPackages/
 
-# Temp folder containing Examine indexes, NuCache, MediaCache, etc.
+# Temp folder containing Examine indexes, MediaCache, etc.
 /umbraco/Data/TEMP/
 
 # SQLite database files

15/umbraco-cms/reference/notifications/contentservice-notifications.md

@@ -217,8 +217,8 @@ Child scope will inherit the parent Scope's notification object which means if a
 
 **Why would one want to suppress events?**
 
-The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by the Published Content Cache to populate the `cmsContentNu` table and populate the content caches. They are also used to populate the Examine indexes.
 
-So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+So if you did suppress events, it will require you to rebuild the Published Content Cache and examine data manually.
 
 </details>

15/umbraco-cms/reference/notifications/hot-vs-cold-restarts.md

@@ -4,32 +4,32 @@ description: When rebooting an Umbraco CMS website it is common to distinguish b
 
 # Hot vs. cold restarts
 
-The load time of your site is dependent on a few different things. When talking about hot vs. cold restarts of your Umbraco CMS website it comes down to whether NuCache needs to be rebuilt.
+The load time of your site is dependent on a few different things. When talking about hot vs. cold restarts of your Umbraco CMS website it comes down to whether the search indexes need to be rebuilt.
 
-* **Cold restart**: When NuCache needs to rebuild.
-* **Hot start**: When NuCache does not need to rebuild.
+* **Cold restart**: When the search indexes need to rebuild.
+* **Hot start**: When the search indexes do not need to rebuild.
 
 ## Hot start
 
 When no cache needs to be rebuild, the restart of your site is generally faster. This is why it is referred to as a **hot restart**.
 
 ## Cold start
 
-The **cold restart** expression is generally used for when the NuCache needs to rebuild. This will resolve in a slower startup time, depending on the amount of content on the site. Generally speaking, the more content you have the longer a cold boot will take.
+The **cold restart** expression is generally used for when the search indexes need to rebuild. This will resolve in a slower startup time, depending on the amount of content on the site. Generally speaking, the more content you have the longer a cold boot will take.
 
 ## Troubleshooting slow startup
 
 Different things could be in play when your site is slow to startup after a reboot/restart.
 
 Below is a list of some of the more common reasons:
 
-* NuCache needs to rebuild (cold restart).
+* The search indexes need to rebuild (cold restart).
 * Examine indexes need to rebuild - for large sites, this can take some time.
 * The custom code on the website is not optimized and does not live up to .NET standards.
 
 ## In Memory Auto
 
-Another factor that can slow down time to first page load is the [In Memory Auto models builder](../templating/modelsbuilder/builder-modes.md#in-memory) setting. Having this setting enabled will result in the first page load being slower. The reason for this is that when the first page is requested, the strongly typed models needs to be compiled and loaded in. 
+Another factor that can slow down time to first page load is the [In Memory Auto models builder](../templating/modelsbuilder/builder-modes.md#in-memory) setting. Having this setting enabled will result in the first page load being slower. The reason for this is that when the first page is requested, the strongly typed models needs to be compiled and loaded in.
 
 This is, however, less noticeable on consecutive restarts, a bit like hot and cold restarts. Since the compiled models will be cached on disk, they don't need to be recompiled until the models change again.
 

15/umbraco-cms/reference/notifications/mediaservice-notifications.md

@@ -128,8 +128,8 @@ Child scope will inherit the parent Scope's notification object which means if a
 
 **Why would one want to suppress events?**
 
-The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by the Published Content Cache to populate the `cmsContentNu` table and populate the content caches. They are also used to populate the Examine indexes.
 
-So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+So if you did suppress events, it will require you to rebuild the Published Content Cache and examine data manually.
 
 </details>

15/umbraco-cms/reference/notifications/memberservice-notifications.md

@@ -69,8 +69,8 @@ Child scope will inherit the parent Scope's notification object which means if a
 
 **Why would one want to suppress events?**
 
-The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by NuCache to populate the cmsContentNu table and populate the content caches. They are also used to populate the Examine indexes.
+The main reason for ever doing this would be performance for bulk operations. The callers hould be aware that suppressing events will lead to an inconsistent content cache state (if notifications are suppressed for content or media services). This is because notifications are used by the Published Content Cache to populate the `cmsContentNu` table and populate the content caches. They are also used to populate the Examine indexes.
 
-So if you did suppress events, it will require you to rebuild the NuCache and examine data manually.
+So if you did suppress events, it will require you to rebuild the Published Content Cache and examine data manually.
 
 </details>