Elements: Contextualize variant blocks rendering for invariant content

[kjac]

Prerequisites

• I have added steps to test this contribution in the description below

Description

We currently have issues contextualizing blocks of variant element types in an invariant context. While we have tests proving it works, these are actually false positives; it only works for the first request... then the cache takes over, and continues to serve the initially accessed variant for all requested languages.

This PR amends that shortcoming.

Testing this PR

You'll need to use the Management API here, because block editors do not (yet) support the use of variant element types in invariant content:

1. Create an invariant and a variant element type.
2. Create elements of both types in the library.
3. Configure a block list data type to use both element types.
4. Create an invariant document type with a block list property using this data type.
5. Use the Management API to create and publish a document with a mix of blocks based on both invariant and variant element types.
6. Render the document in multiple languages and verify that the rendering contextualizes the element output correctly.

Breaking change

This changes the signature of the public interface IBlockElementService, and that is a breaking change. Unfortunately, it is not possible to create any meaningful overload to retain backwards compatibility, because it would require either:

a. Handling a nullable owner parameter in the service implementation, which kinda defeats the purpose, or
b. New'ing up a PublishedElement instance to pass as default, which is a super complex entity, filled with a lot of inner workings.

Since IBlockElementService will be introduced in V18, and the target PR for this PR is slated for V19, the impact of this breakage will be quite limited, so I think we should just accept it. Also, the target PR will probably be breaking in itself anyway 🤷

[claude]

Claude finished @kjac's task in 4m 28s —— View job

---

PR Review

Target: origin/v18/feature/reusable-block-content · Based on commit: b37d8788

Fixes a cache poisoning bug where variant block elements in invariant content rendered correctly on the first request, then served the initially-cached culture for all subsequent requests. The fix threads the owning IPublishedElement through to BuildElementAsync, detects the invariant-owner/variant-element mismatch, and replicates the default-language property value across all languages before building the cache node.

• Modified public API: IBlockElementService.BuildElementAsync — new required IPublishedElement owner first parameter
• Affected implementations (outside this PR): Any external code that implements IBlockElementService directly (none in src/)
• Breaking changes: BuildElementAsync signature changed without backwards-compat mitigation — compile error for external implementors

---

Important

• src/Umbraco.Core/PublishedCache/IBlockElementService.cs:8: BuildElementAsync adds a required owner parameter without a Pattern-2 or Pattern-3 backwards-compat mechanism. Per CLAUDE.md §5 any public interface/method signature change requires retaining the old signature. The PR description explains the difficulty, but the repo policy still applies — even a Pattern-3 default that throws is better than a silent compile error for external implementors. A workable approach: add an obsolete default implementation that delegates to the new overload using a minimal invariant-stub owner, preserving the new (correct) behaviour for legacy callers:

  // Internal helper — not exposed in the public namespace
  internal sealed class InvariantPublishedContentTypeStub : IPublishedContentType
  {
      // implement only what VariesByCulture() reads: Variations = ContentVariation.Nothing
      public ContentVariation Variations => ContentVariation.Nothing;
      // remaining members throw NotImplementedException
  }
  
  internal sealed class InvariantOwnerStub : IPublishedElement
  {
      public static readonly InvariantOwnerStub Instance = new();
      public IPublishedContentType ContentType { get; } = new InvariantPublishedContentTypeStub();
      // remaining members throw NotImplementedException
  }

  Then in the interface:

  [Obsolete("Use BuildElementAsync(IPublishedElement, BlockItemData, bool?) instead. " +
            "Scheduled for removal in Umbraco 20.")]
  Task<IPublishedElement?> BuildElementAsync(BlockItemData blockItemData, bool? preview = null)
      => BuildElementAsync(InvariantOwnerStub.Instance, blockItemData, preview);

  This keeps external callers compiling while giving them the corrected behaviour. Fix this →

Suggestions

• src/Umbraco.PublishedCache.HybridCache/Services/BlockElementService.cs:61: allLanguages.Single(l => l.IsDefault) throws InvalidOperationException if no language is marked as default (shouldn't happen in a correctly configured system, but defensive code here is cheap). Consider SingleOrDefault() with an early-return null guard.

• tests/Umbraco.Tests.Integration/Umbraco.PublishedCache.HybridCache/PropertyValueLevelDetectionTests.cs:106: The new mock owner (invariant ContentVariation.Nothing) is correct for the updated signature. Worth noting: the test element type (umbElement) has only invariant properties, so the new special-case branch in BlockElementService is not exercised here. That path is covered by BlockListElementLevelVariationTests.Parsing.cs, so no coverage gap — just worth knowing where the new logic is actually tested.

---

Request Changes

The breaking-change pattern violation is an Important issue that should be addressed before merge. The fix logic itself is correct and well-tested — the dual-culture assertion loop in the integration tests (AssertBlockValues() called once per language) cleanly proves the cache-poisoning regression is closed. A backwards-compat shim on the interface is the only thing needed before this is ready.

[AndyButland]

Updates all look good to me. We'll do pair review of the before and after later.