トラブルシューティングの最適化のショートカット：PageshortCutlinkが投げた理由

Optimizelyと協力している開発者として、私たちはしばしば、プラットフォームの深さを探求するように私たちを押し進める独自の課題に遭遇します。最近、コンテンツの移行と外部リンクを含む魅力的なタスクに取り組みました。これにより、財産管理のウサギの穴、そして最終的にははるかにスムーズなソリューションになりました。特に同様のハードルに遭遇する可能性のある他の人のために、私の旅を共有したかったのです。

シナリオ：2社の物語

当社は最近子会社を販売し、移行の一環として、Optimizelyサイトの古いコンテンツから別のOptimizelyインスタンスの新しい家へのスムーズなリダイレクトを促進する必要がありました。コアタスクは、サイトの既存のページを外部ショートカットに変換し、新しい会社のWebサイトで対応するURLを指していました。

2つの列を含むExcelファイルが提供されました。 Firsturl （当サイトの既存のURL）および Secondurl （新会社のサイトのターゲットURL）。私の目標は、このプロセスを自動化し、何百もの内部ページを外部リンクに変えるカスタムアドオンを作成することでした。

最初のアプローチ：プロパティと困惑

私の最初の本能と、最適化のページデータを操作するときの一般的なアプローチは、プロパティコレクションを活用することでした。 Optimizelyページには、ショートカットを管理するためにPagesHortCuttypeやPagesHortCutlinkなどのプロパティがあることを知っていました。それで、私はこれから始めました：

writablePage.Property["PageShortcutType"].Value = PageShortcutType.External;
writablePage.Property["PageShortcutLink"].Value = importResponse[index].SecondUrl;

最初の行は、PagesHortCuttypeをPagesHortCuttype.Externalに設定し、完全に機能しました。これにより、ページは外部ショートカットとして正しくフラグを立てました。ただし、ExcelファイルからSecondurlを使用してPagesHortCutlinkを設定しようとした2行目は、かなり不可解な例外を投げました。

{"ContentReference: Input string was not in a correct format."}

これは不可解でした。 Secondurlは、有効な絶対URL文字列でした。私はフォーマットを再確認し、先頭/末尾のスペースがないことを確認し、URLエンコードを試したことさえありました。何も機能しないようです。 GoogleおよびさまざまなOptimizelyフォーラムでの長い検索では、プロパティコレクションを介してDirect URL文字列をPagesHortCutlinkに割り当てる際に、この特定のエラーに対する明確なソリューションは得られませんでした。

テクニカルディープダイブ：なぜエラーがあるのですか？

この例外「ContentReference：入力文字列は正しい形式ではありませんでした」は、PageshortCutlinkのOptimizelyの内部メカニズム（プロパティ経由でアクセスした場合）を強く示唆しています。[“PageShortcutLink”]）PageshortCuttypeが外部に設定されていても、RAW URL文字列ではなく、コンテンツレフェンスオブジェクトを期待しています。

これが技術的な内訳です：

• PagesHortCutlinkの内部期待： 論理的には外部URLを保存することが期待されるかもしれませんが、汎用プロパティコレクションを介してPageshortCutlinkと対話すると、Optimizelyの基礎となる型変換または検証がコンテンツを期待するように見えます。これは、コンテンツ管理システム内で一貫性を維持するための設計選択であり、将来の強化またはより厳格な検証を可能にする可能性があります。
• ContentReference Nuance： コンテンツは、システム内のコンテンツ（ページ、ブロック、メディアファイルなど）を一意に識別する最適化の方法です。任意の外部URLを保持するようには設計されていません。例外は、私の文字列が有効なコンテンツに解析されていないという明確な指標でした。

これは、最適化の開発の重要な側面を強調しています。特に、内部コンテンツと外部URLの両方にリンクできるプロパティの場合、一般的なプロパティアクセサがすぐには明らかではない根本的な期待を持っている場合があります。

「aha！」瞬間：救助への直接的な財産

欲求不満だが、私は同じ結果を達成するための代替方法を探し始めました。そして、それは私を襲った。ページを表すOptimizelyのPagedataオブジェクトは、ショートカットを管理するためのプロパティを直接公開しています！

writablePage.LinkType = PageShortcutType.External;
writablePage.LinkURL = importResponse[index].SecondUrl;

私はこれらの直接的なプロパティのために私の問題のあるプロパティの割り当てを交換しました、そして、私の計り知れない救済のために、それは完璧に機能しました！例外も、コンテンツの参照と格闘することも、クリーンで簡単な割り当てだけではありません。

最終的なソリューション：堅牢で信頼性

タスクを成功裏に達成した完全なコードスニペットは次のとおりです。

for (int index = 0; index
{
    try
    {
        // Resolve the existing page using the FirstUrl
        var content =  _urlResolver.Route(new EPiServer.UrlBuilder(excelData[index].FirstUrl)) as PageData;

        // Ensure we found a page
        if (content != null)
        {
            // Create a writable clone to modify the page
            PageData writablePage = content.CreateWritableClone();

            // Set the LinkType to External
            writablePage.LinkType = PageShortcutType.External;

            // Assign the external URL directly
            writablePage.LinkURL = excelData[index].SecondUrl;

            // Save the modified page
            _contentRepository.Save(writablePage, SaveAction.Patch, AccessLevel.NoAccess);
        }
        else
        {
            // Handle cases where the URL doesn't resolve to a page
            viewModel.ImportResponse[index].Errors.Add(new ValidationResult($"Record for '{excelData[index].FirstUrl}' couldn't be found or resolved."));
        }
    }
    catch (Exception ex)
    {
        // Log the exception for debugging
        // _logger.LogError(ex, "Error processing record for URL: {Url}", excelData[index].FirstUrl); 
        viewModel.ImportResponse[index].Errors.Add(new ValidationResult("Record couldn't be updated. Please validate the data again. " + ex.Message));
    }
}

最終コードへの技術的追加：

• エラー処理とロギング： _urlresolver.routeメソッドがページを見つけられない場合、より具体的なエラーメッセージを追加しました。これは、実際のシナリオにとって重要です。また、例外を記録するためのプレースホルダー（_logger.logerror）にコメントしました。これは、生産環境でのデバッグと監視のためのベストプラクティスです。
• コンテンツのnullチェック： _urlresolver.routeが実際にPagedataオブジェクトを返すかどうかを確認することが重要です。 Firsturlが既存のページに対応していない場合、コンテンツはnullになり、nullReferenceExceptionになります。

学んだ教訓

この経験は、私にとっていくつかの重要な教訓を強化しました：

1. 利用可能な場合は直接プロパティを好みます： プロパティコレクションは動的またはカスタムプロパティに強力ですが、一般的な機能については、Pagedata（またはcontentData）オブジェクトに直接プロパティがあるかどうかを常に確認してください。これらの直接プロパティは、多くの場合、正しい基礎となるロジックとタイプ処理をカプセル化します。
2. Optimizelyの内部期待を理解する： 「ContentReference」エラーは、たとえ私の文字列であっても、Optimizelyが特定のタイプを念頭に置いているという強いヒントでした 見た 必要なもののように。これらの特定のエラーメッセージをデバッグすると、多くの場合、OptimizelyのAPIが内部的に設計されていることを示しています。
3. コミュニティとドキュメントが重要です（ただし、常に網羅的ではありません）： 私は当初、特定のエラーの正確なソリューションを見つけるのに苦労していましたが、ドキュメントやフォーラムを調べる旅は、最終的に私は代替アプローチを検討するようになりました。

このタスクは、表面上は一見単純に見えますが、Optimizelyのコンテンツモデルとプロパティ管理の理解を深める貴重な機会を提供しました。これらの種類の課題が、私たちが最適化の開発者として成長するのに本当に役立ちます！

2025年7月9日