Umbraco 17.7.0 readiness

[KevinJump]

Umbraco 17.7.0 (due 17 Sept 2026) contains three changes that alter uSync behaviour. This issue tracks working through them.

Reviewed against the actual commit range release-17.6.2...release-17.7.0-rc (160 commits). No breaking changes are declared for the release, and our floor is Umbraco.Cms.Core 17.3.0, so no reference bump is required to run on 17.7 — but the three items below change behaviour we currently depend on.

---

1. First-boot migration no longer inherits a published-cache rebuild

Umbraco PR: umbraco/Umbraco-CMS#23533 — Migrations: Only rebuild the published cache for migration plans that request it

MigrationPlanExecutor is a singleton, and its _rebuildCache flag was never reset between plans. On an upgrade path where the core plan sets the flag (e.g. v13 → v17), every package plan that ran afterwards inherited a full cache rebuild. uSync_FirstBoot was one of them — so a first-boot import on an upgrade has been getting a free published-cache rebuild that it never asked for.

17.7 resets the flag per plan. FirstBootMigrationPlan does not set RebuildCache, so that rebuild goes away silently.

This is the one to test first: it is a behaviour change on the upgrade path with no error and no log line.

• Reproduce a first-boot import on an upgrade path (not a fresh install) against 17.6 and confirm the inherited rebuild is happening today
• Repeat against 17.7 and check whether the published cache is left stale after the import
• If stale: set RebuildCache = true on the uSync migration, or trigger the refresh from StartupImportAsync itself
• Confirm fresh-install first boot is unaffected either way
• Check the same question for umbraco/Umbraco-CMS#23709 (no rebuild after a failed plan) — FirstBootMigration catches everything and always calls Context.Complete(), so it should never be seen as failed, but worth confirming

Files: uSync.BackOffice/Boot/FirstBootMigration.cs

---

2. MovePropertyType(alias, null) is fixed in core — our workaround and its test go stale

Umbraco PR: umbraco/Umbraco-CMS#23493 — Content Types: Fix MovePropertyType orphaning the property when moving it to no group

This is exactly the bug behind #1009. Core now removes the property from wherever it lives and adds it to wherever it is going, in both directions, and the second parameter is annotated string?.

Our workaround in ContentTypeBaseSerializer.MoveProperties is guarded (if ... PropertyTypes.Any(...) is false), so it stays correct on 17.7 — it simply stops doing anything. The test does not survive: MoveToNull_OrphansTheProperty asserts the buggy behaviour and will fail as soon as the test project references 17.7 or later.

The PR also fixed the mirror direction — moving a property from no-group into a group previously left it in both collections until reload. Our plain MovePropertyType(move.Key, move.Value) path gets that fix for free.

• Rewrite MoveToNull_OrphansTheProperty so it asserts the outcome we need rather than the core bug, or drop it and keep only MoveToNull_ThenReAdd_LandsInNoGroup
• Decide whether to keep the re-home workaround (safe on both, still needed for 17.3–17.6) or version-gate it
• Drop the now-unnecessary null! on item.MovePropertyType(move.Key, null!)
• Add coverage for the reverse direction (no-group → group) now that core no longer leaves duplicates

Files: uSync.Core/Serialization/Serializers/ContentTypeBaseSerializer.cs (~L1245-1266), uSync.Tests/Serializers/MovePropertyTypeTests.cs

Related: #1009

---

3. Culture code casing is normalised, and invalid codes now throw

Umbraco PR: umbraco/Umbraco-CMS#23425 — Normalize culture code casing in SetCultureInfo and SetPublishInfo

SetCultureInfo / SetPublishInfo now run the culture through EnsureCultureCode(), which uses CultureInfo.GetCultureInfo(culture).Name. Two consequences:

• en-us is persisted as en-US. Sites whose content was saved with oddly-cased culture codes may export differently on 17.7 than on 17.6 — one-off churn across everyone's uSync/v17 folder.
• An invalid culture code now throws CultureNotFoundException. On import that would come from a .config file referencing a culture that no longer exists on the site.

ContentSerializerBase mixes two paths — it adds new ContentCultureInfos(culture) directly, then calls SetCultureName — so only part of what we write goes through the normalising route.

• Export the same variant content on 17.6 and 17.7 and diff, to confirm whether serialised culture casing shifts
• If it does, decide: normalise on export ourselves, compare culture keys case-insensitively in change detection, or accept the churn and note it in the release notes
• Import a .config file naming a culture that is not installed and confirm we surface a clean uSync error rather than an unhandled CultureNotFoundException mid-import
• Check the direct item.CultureInfos.Add(new ContentCultureInfos(culture)) path is consistent with what SetCultureName now stores

Files: uSync.Core/Serialization/Serializers/ContentSerializerBase.cs (~L505-525, L590-600), uSync.Core/Serialization/Serializers/ContentSerializer.cs

---

Also reviewed, no action taken

Logged so we do not re-review them:

Area	Umbraco PR	Verdict
Ambient scope isolation across execution flows	#23492	Win for us. SyncScopedNotificationPublisher already hand-rolls ExecutionContext.SuppressFlow() for this; now belt-and-braces. Worth a background-import regression test.
LogIncompletedScopes warning restored	#23424	Watch for new log noise from uSync scopes during import.
Compositions on inherited doctypes allowed	#23433	Imports that previously failed validation in this shape should now succeed. Add a test case.
Block editor value shape	#23527, #23383, #23404, #23602	Re-check the structured block diff view (#1060) against 17.7 block JSON, especially invariant blocks containing variant blocks.
Property variance / segment validation	#23445, #23587, #23691	Likely wins. Re-test content import with mandatory segmented properties — validation that passed before may now correctly fail.
Save before publish-with-descendants	#23554	Ordering change near DoSaveOrPublishAsync. Smoke test.
Backoffice timing (Context API, config repositories, UmbArrayState)	#22519, #23416, #23584	Smoke-test the dashboard. Nothing looks likely to break.
Operation ID generation	#23499	Unaffected — the dot substitution is scoped to the Umbraco.Cms.Api.Management namespace, so our generated client is untouched.
Auth deprecations	#23502, #23759	Clear. signalr.context.ts uses getOpenApiConfiguration() / getLatestToken(), neither deprecated; the obsoleted C# services are all preview-related.
New userEntryPoint extension type	#23409	Possible future fit for per-user backoffice setup.