Support in-place publishing page conversion with existing parameters

[TaoziZ03]

Type

• Bug Fix
• New Feature
• Sample

Related Issues?

Depends on pnp/pnpframework#1290, which adds the in-place publishing transformation and the PublishingPageTransformator.CreateInPlace factory this PR calls. This PR must not be merged before that change ships in a PnP.Framework release that the PnP.Framework 1.21.*-* reference resolves to.

What is in this Pull Request ?

ConvertTo-PnPPage -PublishingPage can convert a publishing page within the currently connected Web. The existing -TargetWebUrl and -TargetConnection parameters still select an explicit target in another site collection, and the public parameter surface of the cmdlet is unchanged.

The validation that rejected -PublishingPage without a target is removed. When no target parameter is supplied the cmdlet now builds the transformator through PublishingPageTransformator.CreateInPlace, which is the companion Framework's explicit opt-in for in-place transformation. Cross-site conversion keeps using the existing constructor with the resolved target context, so its behavior is unchanged.

In-place conversion is not simply "pass a null target". The publishing pipeline dereferences the target context without null checks, so the mode is expressed by using the source context as the target. Choosing that explicitly at the call site is what keeps the Framework constructors able to keep rejecting a null target for every existing caller.

The companion Framework determines the transformation mode from the actual Site and Web identities. Same-Web conversion requires an existing writable Site Pages library, retains the source publishing page, and rejects an existing target even when -Overwrite is supplied.

Help and the changelog describe publishing pages among the page types supported for conversion in the connected Web, and record that -PublishingTargetPageName is optional: when neither it nor -TargetPageName is supplied, the modern page keeps the file name of the source publishing page. Because the modern page is created in the Site Pages library, that name cannot collide with the publishing page it is converted from.

This PR no longer modifies src/Commands/PnP.PowerShell.csproj. Those changes only affected developer builds that set PnPFrameworkPath and were unrelated to this feature.

Validation

• The solution builds against the companion Framework with 0 warnings and 0 errors: dotnet build src\Commands\PnP.PowerShell.csproj -c Debug -p:PnPFrameworkPath=<local pnpframework>\src\lib\.
• The default package build cannot validate this change until the companion Framework release exists, because the released PnP.Framework does not expose CreateInPlace. That build also still reports a pre-existing CS1705 from the feed resolving PnP.Core 1.18.49 while PnP.Framework 1.21.49 references 1.18.51. The package references are unchanged by this PR.
• Reviewers reproducing a local companion build should note that referencing a locally built PnP.Framework.dll does not bring in its transitive NuGet packages. The released package supplies them, so only that local workflow is affected.
• PublishingPage remains optional and no additional in-place switch was introduced.
• Companion Framework tests: 27 passed, 0 failed, 0 skipped, across all four target-framework builds.

The live results below were produced before the call sites were moved to CreateInPlace. That factory supplies the same source-as-target state those runs exercised, so the observed conversion behavior is unchanged; only the way the transformator is constructed differs.

• Live Enterprise Wiki tests passed for same-Web conversion without target parameters and cross-site conversion through both existing target parameters.
• Three non-Enterprise-Wiki Publishing pages were each tested in-site and cross-site: rich ArticleLeft, simple ArticleLeft with List web part, and custom IPKit_Home. All six generated native modern drafts and completed editor save/exit. All original source hashes, identities and versions remained unchanged.
• The rich ArticleLeft test exposed a missing-file image JSON failure. The companion Framework now returns numeric defaults and a warning for a missing image. All 31 checked body blocks, 8 tables and 3 Image web parts persisted; the 404 image references remain unresolved.
• IPKit_Home converted using the existing -PageLayoutMapping parameter and a mapping verified against its body field and zone IDs. All 16 checked body blocks persisted. Default automatic mapping fails for this tenant's catalog item, which lacks PublishingAssociatedContentType.
• Cross-site retained existing missing-target-list skip behavior (1 List web part on each ArticleLeft fixture; 4 on IPKit_Home). Same-Web retained the lists. Default Script Editor behavior is unchanged. These tests do not claim full page, asset, list or script fidelity.
• Existing-target -Overwrite, missing Site Pages, and different-Web/same-site-collection negatives behaved as expected. Failed mapping runs produced no target page.
• The Enterprise Wiki SVG remains a readable source reference under the existing copy allow-list.
• git diff --check passed.

Live acceptance is scoped to the tested tenant, the stock Enterprise Wiki and ArticleLeft layouts, and the supplied IPKit_Home mapping.