Quick Fixes or Emergency Edits of Production Content

You might occasionally need to make unplanned edits to content on the Production instance that must be live within a short period of time. You can configure page cache partitions so that it is safer and has less of an effect on site performance to make these edits and replicate them.

What Are Page Cache Partitions?

A page cache partition is the page cache for a group of pipelines. If the partition is invalidated, then the page cache for those pipelines is invalidated, but no other page caches are invalidated.

Why Are Page Cache Partitions Useful?

While it is possible to edit products directly in Business Manger on a Production instance to make a quick fix, if the page that shows the product is cached, it might take a long time until the change appears in the storefront. To make the change appear faster, you must invalidate the page cache for the entire site. This makes the change go into effect within fifteen minutes, but has a significant performance impact, because the entire page cache is regenerated.

Changes made directly to the Production instance are outside the normal workflow, which allows for testing and previewing content. It also requires more work to get the Staging and Production instance data back in sync, which must happen before the next replication of data from Staging to Production.

Salesforce recommends that you configure page cache partitions and replication jobs for quick fixes of product or content information for a better workflow and site performance. Configuring partitions requires the permissions and expertise of your administration or operations staff.

Configuring Page Cache Partitions

Configure page cache partitions on your Staging instance.
Note: Changing your page cache configuration causes a reset of the cache clear time and should be done infrequently. Every time a partition is updated (pipelines added or removed) the page clear time of the updated partition and site is set to the shorter value of the partition or site. When a partition is deleted, the site's page clear time is set to the partition's page cache clear time if it's shorter. The clear time for the page cache can be seen as the last invalidated date for page cache of the site.
Replicate the cache settings site-level replication task to the Production instance. This replicates the required configuration to the Production instance. When replicated, you only need to replicate it again if you change the configuration of the partitions.
Important: Replicating the cache settings causes a full page cache invalidation across all sites.

When You Need to Make a Quick Fix:

1. Change product or search Information

Make the quick fix to product information on your Staging instance.

2. Configure Replication Jobs Without Page Cache Invalidation

Create a replication job for your changes where the Page Cache option is set to Do not invalidate. See New Data Replication Process Step 1 General page.

Selecting Don't invalidate for your replication process means that the page cache for the entire site is not invalidated, as it normally is when you replicate. Because the entire page cache isn't invalidated you will see no performance effect on the storefront because of the replication. You will also not see any of your changes reflected in the storefront.

3: Invalidate Page Cache Partitions

After replicating your changes to product or search, you invalidate the page cache partition manually in Business Manager on the Production instance.

Note: The page cache does not include the static content cache, which must be invalidated separately. The developers in your organization can tell you what pipelines to include in your partition definitions.