Optimizely CMS 13 でのアプリケーションの操作

💡注記： 以下のコンテンツは Optimizely CMS 13 Preview 2 に基づいて書かれており、最終リリース バージョンを正確に反映していない可能性があります。

Stott Security および Stott Robots Handler for PaaS CMS 13 の準備の一環として、サイト定義を使用するアドオンの主要な機能を再検討する必要がありました。これらのアドオンを使用すると、ユーザーはグローバル、サイトごと、ホスト定義ごとに robots.txt、llms.txt、security.txt 構成を定義できます。そのため、さまざまなサイト構成に関するデータを読み取れる必要があります。

サイト/アプリケーション定義へのアクセス

CMS 13 が SaaS から先導し、より構成可能なアーキテクチャについて考えるようになったことで、「サイト」について考えることから「アプリケーション」について考えるようになりました。また、2 つの異なるアプリケーション構成を使用するよう移行しています。伝統的なものがあります 「進行中」 に代表されるCMSアプリケーション Webサイト クラスがあり、 「首なし」 に代表されるアプリケーション リモートウェブサイト クラス。これら 2 つのアプリケーションは両方とも、 応用 クラス。

既存の ISiteDefinitionリポジトリ は現在非推奨ですが、現時点では機能し、戻り値のみを返します 仕掛品 アプリケーション。両方の種類のアプリケーションにアクセスするには、次の新しいインターフェイスを使用する必要があります。 IApplicationRepository。この新しいリポジトリは、アプリケーションをリストするための次のメソッドを公開します。

// In-process applications
var data = await applicationRepository.ListAsync();

// Headless applications
var data = await applicationRepository.ListAsync();

// All applications
var data = await applicationRepository.ListAsync();
var data = await applicationRepository.ListAsync();

ここでのもう 1 つの重要な変更点は、GUID Id フィールドが廃止されたことです。 ISiteDefinitionリポジトリ 引き続き機能する場合、互換性を確保するために ID には空の GUID が設定されます。新しいオブジェクトは 名前 代わりにプロパティが作成され、作成時に指定された表示名のサニタイズされた小文字バージョンとして生成され、不変のプロパティになります。

もう一つの歓迎すべき変化は、 IApplicationRepository 非同期 API への移行です。これにより、特に高スループットのシナリオで、ノンブロッキングでスケーラブルなコードを簡単に作成できるようになります。

⚠️ 移行の警告: 以前に SiteDefinition.Id によって構成をキー指定していた場合は、従来の GUID を Application.Name にマップするための移行戦略が必要になります。 1 対 1 の置き換えはなく、新しい名前は一度作成されると変更できません。

現在のアプリケーションの解決

現在の Web サイトの現在のページを過去に取得するには、次のようにアクセスします。 SiteDefinition.Current。これはもう利用できないため、代わりに使用する必要があります IApplicationResolver その代わり。これにより、次のメソッドにアクセスできるようになります。

// Retrieve the application based on a host name 
var result = applicationResolver.GetByHostname(hostName, fallbackToDefault);
var result = await applicationResolver.GetByHostnameAsync(hostName, fallbackToDefault, cancellationToken);

// Retrieve the application based on a given content reference
var app = applicationResolver.GetByContent(contentReference, fallbackToDefault);
var app = await applicationResolver.GetByContentAsync(contentReference, fallbackToDefault, cancellationToken);

// Retrieve the application based on the current HTTP Context
var app = GetByContext();
var app = await GetByContextAsync(cancellationToken);

逆コンパイル デフォルトアプリケーションリゾルバー わかります。 GetByContext メソッドは実際にはラップするだけです GetByContent そして GetByHostName メソッドを使用し、最初にコンテンツによってこれを実行しようとします。機能がコンテンツ ルートの外で動作する必要がある場合は、ホスト名でアプリケーションを直接取得する方が良い場合があります。これにより返されることに注意してください。 アプリケーションホスト解像度 ではなく 応用。

public async ValueTask GetByContextAsync(CancellationToken cancellationToken = default(CancellationToken))
{
    Application application = null;
    ContentReference routedContentLink = _routedContentLinkResolver.RoutedContentLink;
    if (!ContentReference.IsNullOrEmpty(routedContentLink))
    {
        application = await GetByContentAsync(routedContentLink, fallbackToDefault: true, cancellationToken).ConfigureAwait(continueOnCapturedContext: false);
    }

    if (application == null)
    {
        string hostName = _requestHostResolver.HostName;
        (application, _) = await GetByHostnameAsync(hostName, fallbackToDefault: true, cancellationToken).ConfigureAwait(continueOnCapturedContext: false);
    }

    return application;
}

まとめ

CMS 13 は、従来のサイトの概念をアプリケーションに置き換え、インプロセス モデルとヘッドレス モデルの両方をサポートします。レガシー サイト API は互換性のためにまだ存在していますが、新しい開発では IApplicationRepository と IApplicationResolver を使用する必要があります。

GUID ベースのサイト ID から不変のアプリケーション名への移行は最も重要な変更であり、構成の保存と移行に大きな影響を与えます。これには多少の調整が必要ですが、新しいアプリケーション モデルは、最新の CMS アーキテクチャにクリーンでより柔軟な基盤を提供します。

私は OMVP であり、 ストットセキュリティ そして ストットロボットハンドラー Optimizely CMS 12 の場合。私のコンテンツはすべて次の場所にまとめてあります。 https://www.stott.pro/

2026 年 1 月 30 日