Optimizely CMS でより適切なリンク検証レポートを構築する

組み込まれた壊れたリンクのレポートは、 最適化 編集者にとっては扱いにくい場合があり、壊れたリンクは維持するのが困難なことがよくあります。リンク切れは訪問者をイライラさせ、SEO にダメージを与えます。未公開ページをリストから削除するオプションを何年も待った後、代わりにそのための独自のツールを作成することにしました。この投稿では、カスタム置換を作成した理由、それが内部でどのように機能するか、そしてそれが編集者にとって日常的に何を意味するかについて説明します。

組み込みのリンク検証レポート

Optimizely CMS 12 には、と呼ばれるスケジュールされたジョブが含まれています。 リンクバリデーター に保存されているすべてのリンクを定期的にチェックします。 tblContentSoftLink データベーステーブル。それは、 HTTP GET 各 URL に対するリクエストを実行し、応答ステータスを記録し、結果を リンク検証レポート で見つかりました /EPiServer/CMS/reports#/LinkStatus。

組み込みレポートは、壊れたリンクを明らかにする適切な機能を果たします。それは以下を示します:

• 壊れたリンクが属しているページ
• 壊れた URL
• HTTP ステータス コード (404、301、403 など) または接続エラー
• リンクが最後にチェックされたとき

多くのサイトではこれで十分ですが、多くのソリューションでは、ページ/ブロックが公開されているかどうか、またはブロックが使用中かどうかを確認できると便利です。内部の壊れたリンクも少しわかりにくく表示されます。

延長が難しい理由

CMS 12 のリンク検証レポートは、Optimizely のシェル UI の一部であり、 道場 モジュールシステム。私は自分の道場のスキルに十分な自信がないので、最初にクロードに、既存のレポートの私の希望に合わせて道場を修正するのを手伝ってくれるよう頼もうとしました。それはあまり成功しませんでしたし、少し危険でもありました。組み込みレポートの列を追加または変更するには、シェル モジュール (経由で登録された別の JavaScript モジュール) を作成する必要があるように見えました。 module.config CMS UI フレームワークにフックします。実際には、これは次のことを意味します。

• Dojo モジュール システムと AMD 依存関係の読み込みとの戦い
• モジュール フォルダー名が ASP.NET Core の MVC 領域検出と競合する場合、CMS シェル UI が破損するリスク
• 既存のレポート グリッドに列を追加するための公式の拡張ポイントはありません
• すべての Optimizely アップデートで壊れる可能性のある変更

Dojo と格闘して、更新後にバージョンが壊れる危険を冒すよりも、標準の CMS エディター ポリシーで保護された、通常の ASP.NET Core コントローラーと Razor ビューとしてスタンドアロン レポートを構築するほうが簡単なアプローチだと判断しました。これにより、フレームワークの制約がなく、通常の C# と HTML を完全に制御できるようになりました。

カスタムレポートで追加されるもの

組み込みレポートと同じ基礎となるデータ ソースに基づいて構築されるカスタム レポートを作成しました。 ILinkRepository インターフェース — しかし、私にとって必要な情報で各結果を充実させます。

編集者向け

ページは公開されていますか? これは、組み込みレポートに欠けている最も実用的な情報です。未公開の下書き/アーカイブ ページ上の壊れたリンクは、公開中のページ上のリンクよりも優先度を大幅に低くする必要があります。レポートには、すべてのページ/ブロックに明確な「公開済み」または「未公開」バッジが表示されます。また、公開済みアイテムのみを表示するフィルターをリストに追加しました。そのため、編集者の焦点は、現時点での訪問者の感情にあります。

内部の壊れたリンクのラベルを改善 組み込みレポートには、次のような生のパーマリンク URL が表示されます。 ~/link/9f5c29c8abee4ad1b8c17a4630831778.aspx 壊れた内部コンテンツ参照の場合、編集者にとっては何の意味もありません。これらの GUID の背後にあるコンテンツを特定しようとしました。次のような人間が判読できるラベルを表示します。

• 削除されたコンテンツへの内部リンク
• 未公開ページへの内部リンク：アニュアルレポート2019
• メディアがありません: Hero_image_autumn_campaign.png

    try
    {
        var map = _permanentLinkMapper.Find(guid);
        if (map == null)
            return "Internal link to deleted content";

        var content = _contentLoader.Get(map.ContentReference);
        return content is MediaData
            ? $"Missing media: {content.Name}"
            : $"Internal link to inaccessible page: {content.Name}";
    }
    catch (ContentNotFoundException)
    {
        return "Internal link to deleted content";
    }
    catch
    {
        return "Internal link (unresolvable)";
    }

ブロック認識 リンク切れのあるコンテンツ ブロックは、「ブロック」バッジで識別されます。ブロックは一度に多くのページに配置できるため、レポートには、ページ ID をリストするツールチップとともに青い「X ページで使用」バッジも表示されます。これは、ブロックが未使用かどうかを編集者が確認できるようにするための意図的なものであったため、壊れたリンクを修正することの優先順位は低かったのです。しかし、ブロックが多くのページで使用されている場合、多くのページが影響を受けるため、壊れたリンクを優先的に修正する必要があるという逆の方法でも役立つ可能性があります。

技術概要

レポートで使用されているのは、 ILinkRepository.GetBrokenLinks(ContentReference.RootPage, skipCount, takeCount) システム内のすべての壊れたリンクをページ移動します。それぞれ SoftLink オブジェクトには、壊れた URL、所有者のコンテンツ参照、HTTP ステータス コード、最初と最後にチェックした日付が含まれています。

壊れたリンクごとに、サービスは次のことを行います。

1. 所有するコンテンツをロードします。 IContentLoader その名前を得るために
2. 公開ステータスを確認します。 IPublishedStateAssessor.IsPublished()
3. パーマネント リンク GUID を解決します。 IPermanentLinkMapper 人間が読めるラベルを作成する
4. コンテンツが BlockData インスタンス、および呼び出した場合 IContentRepository.GetReferencesToContent() ブロックを使用してすべてのページを検索するには
5. 壊れた URL 文字列のコンテンツ プロパティをスキャンして、所有プロパティを特定します。

ここには改善できる点がたくさんありますが、私にとっては、古いリンク検証レポートの代わりに非常に便利なツールです。組み込みのレポートよりもコードをより細かく制御できるのは良いことであり、各ソリューションの必要に応じて新しい機能を簡単に追加/削除できます。

ここでできることはたくさんありますが、私にとって、このソリューションは、組み込みのレポートで苦労するよりも優れた代替手段です。

ソースコード