1769553043
2026-01-26 20:00:00
Optimizely CMS 13 がプレビューで利用可能になったため、拡張機能の開発者は、パッケージを新しいバージョンと互換性を持たせるためにどのような変更が必要かを理解する必要があります。この投稿では、移行のために行った具体的な変更について説明します。 OptiGraphExtensions – Optimizely Graph 内で同義語、ピン留めされた結果、Webhook、およびカスタム データ ソースを管理するための Optimizely CMS アドオン。
CMS 13 の変更点の概要
技術的な詳細に入る前に、この移行の範囲を理解しておく価値があります。 CMS 11 から CMS 12 への大規模なアップグレード (.NET Framework から .NET への移行を伴う) とは異なり、CMS 12 から CMS 13 への移行はかなり簡単です。主な変更点は次のとおりです。
- .NET 10の要件 – CMS 13 は .NET 10 をターゲットとします
- 非推奨の API – いくつかのレガシー API は廃止済みとマークされています
- 新しいアプリケーションモデル – SiteDefinition は、より柔軟なアプリケーション構成に置き換えられます。
- シェル UI タグ ヘルパー – 新しい
要素は従来のナビゲーション ヘルパーを置き換えます
ステップ 1: ターゲット フレームワークを更新する
最初の最も基本的な変更は、ターゲット フレームワークを .NET 8 から .NET 10 に更新することです。
以前 (CMS 12):
net8.0
後 (CMS 13):
net10.0
ステップ 2: NuGet パッケージ参照を更新する
すべての Optimizely パッケージをバージョン 13.x に更新する必要があります。メインの拡張プロジェクトでの変更点は次のとおりです。
以前 (CMS 12):
後 (CMS 13):
サンプル CMS サイトには、追加のパッケージが必要です。
ステップ 3: global.json を更新する
ソリューションで グローバル.json ファイルを使用して SDK バージョンを固定し、.NET 10 に更新します。
{
"sdk": {
"version": "10.0.102",
"rollForward": "latestMinor"
}
}
ステップ 4: 非推奨の API を処理する
CMS 13 では、拡張機能で一般的に使用されていたいくつかの API が廃止されます。何を探すべきか、そしてそれらを修正する方法は次のとおりです。
ページ参照 → コンテンツ参照
拡張機能が使用している場合 ページ参照に置き換えてください コンテンツリファレンス:
// Before
PageReference pageRef = new PageReference(123);
// After
ContentReference contentRef = new ContentReference(123);
PageData.PageLink → ContentLink
// Before
var link = pageData.PageLink;
// After
var link = pageData.ContentLink;
IContentTypeRepository 汎用パラメータ
ジェネリック引数はから削除されました IContentTypeRepository:
// Before
IContentTypeRepository _pageTypeRepository;
// After
IContentTypeRepository _contentTypeRepository;
サービス拠点の変更
サービスの場所 InitializationEngine.Locate そして context.Locate.Advanced.GetInstance
// Before (obsolete)
var myService = context.Locate.Advanced.GetInstance();
// After (preferred)
public class MyClass
{
private readonly IMyService _myService;
public MyClass(IServiceProvider serviceProvider)
{
_myService = serviceProvider.GetRequiredService();
}
}
ヒント: IDE でコンパイラ警告を確認してください。コードベースでの非推奨の API の使用方法がすべて案内されます。
ステップ 5: スタートアップ構成を更新する
CMS 13 では、いくつかの追加構成が必要です。 スタートアップ.cs:
訪問者グループのサポートの追加
services.AddCmsAspNetIdentity()
.AddCms()
.AddAdminUserRegistration(x => x.Behavior = RegisterAdminUserBehaviors.Enabled | RegisterAdminUserBehaviors.LocalRequestsOnly)
.AddVisitorGroups() // Required in CMS 13
.AddEmbeddedLocalization();
データベース互換性の構成
services.Configure(options =>
{
options.UpdateDatabaseCompatibilityLevel = true;
});
ステップ 6: Blazor コンポーネントの変更を処理する (.NET 10)
拡張機能が Blazor コンポーネントを使用する場合 (OptiGraphExtensions のように)、使用するプロジェクトのプロパティにこのプロパティを追加する必要がある場合があります。 .csproj:
true
これにより、参照される Razor クラス ライブラリの静的 Web アセットが適切に含まれるようになります。
ステップ 7: 新しいシェル UI タグ ヘルパーを使用して管理レイアウト ページを更新する
CMS 13 では、タグ ヘルパーを使用して管理ページを Optimizely Shell ナビゲーションと統合する新しい方法が導入されています。拡張機能にカスタム管理ページがある場合は、レイアウト ファイルを更新する必要があります。
EPiServer.Shell.UI タグ ヘルパーを追加する
管理レイアウト ファイル (例: _LayoutBlazorAdminPage.cshtml)、新しいタグ ヘルパー参照を追加します。
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, EPiServer.Shell.UI
の EPiServer.Shell.UI タグ ヘルパー ライブラリは、CMS シェルと統合するための新しいカスタム要素を提供します。
ナビゲーション ヘルパー メソッドをプラットフォーム ナビゲーション要素に置き換える
以前 (CMS 12):
@Html.CreatePlatformNavigationMenu()
@RenderBody()
後 (CMS 13):
@RenderBody()
新しい
- 固定位置 –
要素はページの上部に固定ナビゲーション バーを作成します - コンテンツオフセットが必要です – 追加する必要があります パディングトップ: 56px コンテンツ ラッパー (または同様のもの) をコンテンツ ラッパーに追加して、コンテンツ ラッパーが固定ナビゲーションの背後に隠れないようにします。
- スクロールの修正 – シェル CSS が設定する場合があります オーバーフロー: 非表示 ボディにあるため、これをオーバーライドする必要がある場合があります。
html, body {
overflow: auto !important;
height: auto !important;
}
完全なレイアウトの例
CMS 13 と互換性のある管理レイアウトの完全な例を次に示します。
@using EPiServer.Framework.Web.Resources
@using EPiServer.Shell.Navigation
@using EPiServer.Shell.UI.Helpers.Internal
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
@addTagHelper *, EPiServer.Shell.UI
My Extension
@ClientResources.RenderResources("ShellCore")
@ClientResources.RenderResources("ShellCoreLightTheme")
@Html.AntiForgeryToken()
@RenderBody()
ステップ 8: アプリケーション モデルを更新する (サイト構成)
CMS 13 に置き換わる サイト定義 新しいもので アプリケーションモデル。アップグレード後、再構成するまでサイトは 404 エラーを返します。
- に移動します 設定 → アプリケーション CMS管理者で
- デフォルトの「ヘッドレス」アプリケーションを削除します(存在する場合)。
- 新しい「処理中」アプリケーションを作成する
- 開始ページの参照を設定する
- ホストエントリを追加します (例: ローカルホスト:5000)
SiteDefinition のコード変更
拡張機能がプログラムでサイト構成にアクセスする場合:
// Before
var rootPage = SiteDefinition.Current.RootPage;
// After
private readonly IApplicationResolver _applicationResolver;
public async Task GetRootPageAsync(CancellationToken cancellationToken)
{
var app = await _applicationResolver.GetByContextAsync(cancellationToken);
// Or use ContentReference.RootPage for the global root
return ContentReference.RootPage;
}
ステップ 9: 徹底的にテストする
すべての変更を加えた後:
- ソリューションを構築する - 古い API に関する残りのコンパイラ警告を修正
- 単体テストを実行する - 新しいフレームワークですべてのテストが合格することを確認する
- 管理インターフェイスをテストする - 拡張機能の UI が正しく動作することを確認します。
- すべての機能をテストする - 各機能を手動で確認します
# Build the solution
dotnet build src/OptiGraphExtensions.sln
# Run tests
dotnet test src/OptiGraphExtensions.Tests/OptiGraphExtensions.Tests.csproj
# Run the sample site
cd Sample/SampleCms
dotnet run
変える必要がなかったこと
移行で変更されていない点に注目してください。
- Entity Framework モデルと DbContext - パッケージのバージョンを更新したばかり
- MVC コントローラーと API エンドポイント - ルーティングやコントローラーの構造に変更はありません
- ブレザーコンポーネント - コンポーネントコードは同じまま
- コンテンツビュー - ページ テンプレートとブロック テンプレートは同じように機能します
- モジュール構成 - モジュール.config フォーマットは変更されていません
- 認可ポリシー - 同じアプローチが CMS 13 でも機能します
変更の概要
| エリア | 変更が必要です |
|---|---|
| ターゲットフレームワーク | ネット8.0 → ネット10.0 |
| EPiServer パッケージ | 12.x → 13.0.0-プレビュー2 |
| エンティティフレームワーク | 8.0.x → 10.0.x |
| ページ参照 | と置き換えます コンテンツ参照 |
| サイト定義 | 使用 IApplicationResolver |
| サービス拠点 | コンストラクターインジェクションを使用する |
| スタートアップ.cs | 追加 AddVisitorGroups() そして データベース互換性レベルの更新 |
| Blazor (消費プロジェクト) | 追加 必須AspNetWebAssets 財産 |
| 管理者のレイアウト | 追加 @addTagHelper *、EPiServer.Shell.UI そして使用します |
| シェルナビゲーション | 交換する @Html.CreatePlatformNavigationMenu() と |
結論
Optimizely CMS 拡張機能をバージョン 12 から 13 に移行することは、以前のメジャー バージョン アップグレードに比べて比較的簡単です。主な作業には、パッケージのバージョンの更新、非推奨の API を最新の同等の API に置き換え、徹底的なテストが含まれます。
OptiGraphExtensions の場合、拡張機能のクリーンなアーキテクチャ (全体を通して依存関係の挿入を使用し、サービスの場所を回避) により、コードのほとんどはまったく変更する必要がありませんでした。これは、アップグレード時期が来たときに、最新の .NET パターンに従うことが利益をもたらす理由を思い出させてくれます。
リソース
注: このガイドは、CMS 13 プレビュー リリースに基づいています。最終リリース前に一部の詳細が変更される可能性があります。最新情報については、常に Optimizely の公式ドキュメントを参照してください。
2026 年 1 月 26 日
#Optimizely #OMVP #の #日 #Optimizely #の移行