1727738588
2024-09-25 14:34:05
Web サイトは、最新のオファー、業務メッセージ、有益なアラートなど、重要な情報を顧客に迅速に通知するのに最適な手段です。
顧客はこれらのメッセージが Web ページの上部に表示されることに慣れており、企業はこれが Web サイト訪問者とコミュニケーションをとるための非常に貴重な方法であると考えています。
私が働いている会社である Animal Friends Insurance では、サイトに基本的な通知機能がすでにありました。私たちは、これらのメッセージを赤、黄色、緑に分類し、オーダーメイドの通知管理ページを構築して CMS で管理することで、さらに一歩進めたいと考えました。 ここで編集者は通知の編集と期限切れを管理し、さらに通知の公開ステータスを確認できます。
この要件にどのように取り組むかを決定する際、私は早い段階で、CMS によってすでに提供されているブロックとページの組み込みスケジュール、公開、および有効期限を使用する通知ブロックを作成するのが最も効率的な方法であると決定しました。
これらのブロックは管理ページで正しい状態で表示され、編集者に簡単な概要を提供します。
まず、必要なすべての属性を備えた通知ブロックを作成しました。 十分シンプルです!

次に、CMS バックエンドの[設定]タブからアクセスできるカスタム ページを作成しました。 このページは次のセクションに分かれていました。
- 発行済み
- まだ公開されていません
- 予定されている
- 期限切れ

Optimizely の公開フローを利用して、ページ上の正しい場所に通知を表示しました。
発行済み
テスト通知を作成して公開したら、IVersionable を使用して公開日を取得しました。これは、この通知を通知管理ページのセクション内のどこに配置するかを決定するのにも役立ちました。
public DateTime? GetStartPublishDateTime(ContentReference content)
{
var notificationBlock = _contentRepository.Get(content);
var startPublishDate = (notificationBlock as IVersionable).StartPublish;
return startPublishDate;
}

ウェブサイトの上部に表示されるとおりです。

まだ公開されていません
コンテンツが公開される予定かどうかを判断できる特定の属性はありませんが、そうでないものによって推定できます。 私のロジックは次のようになりました…
通知がそうでない場合:
- 削除されました
- 発行済み
- 以前に出版されたもの
- 刊行予定
その場合は非公開にする必要があります。
「削除」状態を除いて、この情報を見つけるためにバージョン ステータスを使用しました。たとえば、「以前に公開された」場合、コードは次のようになります。
public static bool HasBeenPreviouslyPublished(ContentReference content)
{
if (content != null)
{
var contentVersion = ContentVersionRep.Load(content);
if (contentVersion != null)
{
if (contentVersion.Status == VersionStatus.PreviouslyPublished)
{
return true;
}
};
}
return false;
}

予定されている
通知の発行がスケジュールされているかどうかを確認するために、DelayPublishUntil 属性を使用しました。
public static DateTime? GetDelayPublishUntil(ContentReference content)
{
DateTime? delayPublishUntil = null;
if (content != null)
{
var contentVersion = ContentVersionRep.Load(content);
if (contentVersion != null)
{
delayPublishUntil = contentVersion.DelayPublishUntil;
}
}
return delayPublishUntil;
}

期限切れ/削除されました
通知を期限切れにするには、まず通知のクローンを作成し、次に IVersionable クラスの stopPublish 関数を使用してクローンを期限切れにする必要がありました。
コンテンツ リポジトリから元のブロックを期限切れにすることはできないことに注意することが重要です。クローンを作成し、新しい期限切れの状態でクローン バージョンを保存して公開する必要があります。
public void ExpireNotification(string contentRef)
{
var notificationBlock = _contentRepository.Get(ContentReference.Parse(contentRef));
var notificationToExpire = notificationBlock.CreateWritableClone() as NotificationBlock;
(notificationToExpire as IVersionable).StopPublish = DateTime.Now;
_contentRepository.Save(notificationToExpire as IContent, SaveAction.Publish, AccessLevel.NoAccess);
}

最後のタスクは、通知管理ページを CMS メニュー構造に追加することでした。 これは、メニュー セクションを拡張することで実現されました。 [MenuProvider] デコレーター。これを行う方法の詳細はここで見つけることができます – メニュー項目の追加と構成 (optimizely.com) 以下のコードのようになります。
public IEnumerable
何か注意点はありますか?
サマータイム!この作業は春に時計が進む前に完了したため、「公開」フィールドと「期限切れ」フィールドのタイムスタンプは正しい時間を示していました。 しかし、洞察力のある CMS 管理者の 1 人は、Web サイトをホストするサーバーが UTC を使用しているため、新しい通知のタイムスタンプが 1 時間ずれていることに夏に気づきました。
もちろん、私のローカル バージョンの CMS では、通知ページには正しい時刻が表示されました。これは、夏時間に対応する Microsoft の発明である「GMT 標準時」を使用する Windows を実行しているためです。 ただし、CMS をバージョン 12 にアップグレードして以来、DXP サーバーは「GMT 標準時」を認識しない Linux 上で実行されています。 そこで、正しい時間を表示するために、次のチェックを追加しました。
var timeZone = TimeZoneInfo.FindSystemTimeZoneById("Europe/London");
DateTime dt = dateTime.Value;
var isDaylightSaving = timeZone.IsDaylightSavingTime(dt);
if (isDaylightSaving)
{
dateTime = dt.AddHours(1);
}
これで、CMS を活用した完全に機能する通知管理システムが完成しました。
2024 年 9 月 25 日
#オーダーメイドの通知管理システムを作成する方法