大学サイトをWordPress（とブロックエディタ）でリニューアルした時に気を付けること
少し前に、「WordPressサイト制作でカスタムフィールド地獄から抜け出してラクをしたい」にWordPressのブロックエディタ制作で気を付けるポイントを書きました。
その後、大学サイトのリニューアルをWordPressのブロックエディタメインで数件おこなったのですが、大学サイトは一般のサイト制作に加えて独自の注意ポイントがあるな〜と思ったので備忘録としてまとめました。
アクセス負荷に対する検討ができているか
まず「WordPressを導入できるかどうか」に関わる大前提の話です。
大学サイト、特に本体サイトの場合は「短時間にものすごい数のアクセスが集中する」というタイミングがあります。
一番わかりやすいのは合格発表日。それ以外にも災害による休講情報をサイト内で発信している場合は当日朝に学生が一斉にサイトにアクセスしますし、オープンキャンパスの申し込み開始日なども、前の２つほどではないにしろアクセスが増えるタイミングです。
いずれの場合もサイトがダウンしてしまうと多くのユーザが不利益を被る可能性があるため、大学サイトのリニューアルにおいては採用するCMSが何であるかに関わらず、アクセス集中についてまず真っ先にリスク要因の検討をおこないます。
CMSでWordPressを導入する場合は、無対策では確実に上記のアクセス集中時にサイトが落ちます。大学サイトのアクセス集中はサーバスペックだけでどうにかなるものでもなく、キャッシュプラグインを入れていてもそれだけではちょっと弱いかもしれません。サーバにアクセスが来る前にそれを分散させる仕組みがないと、経験上かなり厳しいです。
（そもそものアクセス数自体が少ない場合は大丈夫かもしれないですが）
これまでにWordPressを導入した大学サイトでは、必ず以下のどちらかの条件を満たしています。
① CDNが利用できる
CDNを利用できるインフラ構成であれば、アクセス集中によってサーバ側が突然ダウンするというリスクは低くなります。
とはいえ適切に運用するにはCDNの設定をチューニングする必要があるので、情報処理センターかインフラ担当会社との連携が必要です。
②アクセス負荷のかかるコンテンツがサイト外・別サーバにある
キャッシュプラグインやCDNの導入なしで運用できている大学はこちらのパターンです。そもそも負荷が高くなる仕組みを別サーバに切り出しているため、アクセス解析データを見ても年間を通して急なアクセス集中が見られません。アクセス状況が平均的な増減の範囲に収まっている場合はWordPressを導入するハードルはかなり低くなります。
合格発表システムが外部サービスになっている
学生・職員用のイントラサイトが別サーバで運用している
緊急時の学生向け連絡網はメール配信でおこなっている
同一サーバ内に他のリソースを食うCMSやシステムがない（教員検索やシラバス検索など）
ただしこの場合も「予期しない要因による急激なアクセス増加」はサイトダウンのリスクとして残ります。
報道等で急にアクセスが増えることや、オープンキャンパスや大学祭で外部ゲストに著名人を呼ぶケースなどいくつかアクセスを一時的に上昇させるシナリオが想定されるため、こういった事象については事前に可能性の有無やその際の対策についてもヒアリングしておきます。
保守体制が整っているか
WordPressはコアやプラグイン・テーマのアップデートがかなり頻繁に行われます。
自動更新を有効にしていると運用中のサイトに予期しない影響が出ることがあるため、自動更新設定の要否について事前にメリット・デメリット・リスクを踏まえて方針を決定します。自社でWordpressの保守を担当する場合の費用や条件についても、CMS選定の際にきちんと取り決めておかなければなりません。
大学の情報処理センターでサーバやサイトの保守・運用を別会社に委託していることもあるため、その場合は委託先がWordPressの保守・メンテナンスができる体制であるかを確認します。
アップデートはするけどバグったら制作会社に戻しますという場合もあるので、事前検証環境の有無やアップデートのスケジュール、問題発生時のフローについてもこの段階で相互に合意しておきます。
至急即日対応しろって19時に鬼電が来たらしんじゃうからね…
請求書払い以外の支払い手段があるか
意外と落とし穴になるのがこれです。
WordPressでサイトを制作する際には、プラグインやテーマを導入することがほとんどです。特に多機能で便利なプラグインは有償のものが多く、ライセンス形態もさまざまです。
買い切り型や開発者ライセンスで複数サイトに導入できるものであれば初期構築時の制作費に巻き込んでしまえるのですが、サブスクリプション型のものも最近は増えており、継続的に支払いが発生することがあります。
サブスクリプション型で、大学側で継続的に支払いが発生するプラグインを導入する場合、まず導入可否を確認することはもちろんなのですが、支払い方法に請求書払以外が利用できるかも必ず確認します。
大学の場合これができないケースが少なくありません。
カードもNG、PayPalは当然ダメ、請求書対応しかできないことが後で発覚して、年に1回数千円のサブスクを代理購入して請求書を出す…とやや面倒なオペレーションが生まれてしまうことになりかねないので、できれば早めに確認しておきたいポイントです。
そして、ここまできてやっと「WordPress導入してもいいんじゃないかな」というラインに立てました。
ここからは制作・実装に入ってからの気をつけるポイントです。
更新の頻度に合わせてブロックスタイルとパターンを切り分ける
大学サイトは、まあまあページ数が多いです。直近の案件を見てもだいたい1000P前後になります。
大学サイトに限ったことではありませんが、これくらいのサイト規模になると、コンテンツの更新頻度には明確な特徴・偏りが見られます。
運用者が頻繁に記事やページの新規制作をおこなうもの（ニュース記事・インタビュー記事など）
ある程度複雑なデザイン・構造をもち、定期的に更新も行われるが、ひながたさえ作ってしまえば中身を差し替えるだけでよいもの（オープンキャンパス・受験情報など）
ページ固有のデザインや複雑なブロック構造、実装を必要とするが、最初に作成したらほとんど更新がないもの
運用者が頻繁に記事やページの新規制作をおこなうもの（ニュース記事・インタビュー記事など）
運用担当者が新規に作成する必要があるコンテンツは、できるだけ特殊な操作を必要とせず、作成が平易になるように設計します。
ニュース記事などは複雑なブロックを必要とすることはほぼないので、標準のブロックとブロックスタイルの切り替えで対応できるようにワイヤーフレームの段階から設計します。
ブロックスタイルはカスタムすることができます。必要なスタイルを追加するほかにも、標準のスタイルで使わないものは削除しておくなど、不要な項目は整理するのがおすすめです。
ある程度複雑なデザイン・構造をもち、定期的に更新も行われるが、ひながたさえ作ってしまえば中身を差し替えるだけでよいもの（オープンキャンパス・受験情報など）
ニュース記事ほどシンプルではなく、複数のブロックを組み合わせて作られたやや複雑なブロックパーツを持つコンテンツです。
複数カラムのカード型レイアウトやギャラリーなどはブロックプラグインの追加で対応できるものもありますが、例えば「h2見出しとリード文の下に全幅の画像エリアを持つブロック」といったように、独自のレイアウト構造を持ち、かつ複数の場所で使うことを想定されるパーツが必要なことがあります。
例としては、インタビュー記事の末尾にプロフィールエリアを設けるような場合でしょうか。
このようなパーツの場合、運用者が１からブロックを組み合わせて作るのは難易度が高く現実的ではありません。
こういった場合は「ブロックパターン」としてひな型を登録しておき、運用者が選択するだけでOKなようにしておきます。
ブロックパターンはプラグインで追加するのが便利です。2022年9月現在だと「Custom Block Patterns」「VK Block Patterns」がおすすめ。
どちらも使い勝手としてそんなに大きく変わりはなく、定期的にメンテナンスされているので、テストして使いやすい方を選べばOKです。
なお、WordPress標準のパターンもありますが、デザインのトンマナが大きく違ったりするのでそれらを使うことはほとんどありません。うっかり使われるとページの見た目がサイトデザインに合わなくなってしまうことがあるため、標準のパターンは不可視にしてしまいます。
ページ固有のデザインや複雑なブロック構造、実装を必要とするが、最初に作成したらほとんど更新がないもの
サイト内でそのページにしかない、かつ、デザインが固有でブロック構造もめちゃくちゃ複雑なページです。
トップページをはじめ、大学概要やフィロソフィーのページ、受験生トップなど、サイト内でも比較的視覚デザインの重要度が高く、オリジナルデザインを持ち、しかし更新頻度はさほど高くないものが該当します。（ニュースの最新リスト表示などは自動引用で更新されるので除く）
こういったパーツは運用者が再利用することを前提とせず、更新は中のテキストやリンク、画像のみの想定です。サイト内でも「ここでしか使わない」というパーツなので、パターンに登録することはせずページに直接実装していきます。
できるだけ開発中から触ってもらう
ブロックエディタの操作は、直感的ではありますが慣れるまでにやや時間が必要です。
ブロックスタイルの指定やブロックパターンの反映といった基本操作だけでなく、入れ子構造になったブロックで編集したい箇所にフォーカスを当てるのが最初は地味に難しく、パターンを入れた後に中のテキストを更新しようとして違うブロックを触って壊す、なんてこともまあまあ普通に発生します。
なので、実際の運用者には開発途中でもなるべく早い段階で操作をしてもらい、操作のフィードバックを受けるようにします。
全体が大方できてから動作チェックしてもらうとなると、一度に確認する内容が多くなってしまい、細かいところがスルーされがちです。運用開始してから「ここ直して」「あれ直して」とたくさんフィードバックが来る事態にもなりえます。
可能であればあらかじめ「開発中なので色々変わりますが」と断った上で、できたところから実際のページと同じものを作ってみてもらい、問題なく更新していけそうかを確認してもらいます。
例えば、標準ブロックがメインのニュース記事を先に実装し、トップなど複雑だけどほとんど更新しないページの実装順を後ろに回します。
こうすることで運用担当者には操作に早くから習熟してもらいつつ、固有パーツが多いページはギリギリまでデザインと実装の調整をおこなうといった順番の組み替えです。
大学サイトのリニューアルの場合は実装フェーズの中盤から現行サイトのコンテンツ移行も並走するので、そういった意味でもページ数が多いニュース記事系のコンテンツを最序盤に完成させるのがおすすめです。
CMS仕様書はワイヤーFIXと同時に着手してデザインFIX時に大方を完成させる
ブロックエディタ以前の制作フローだと、デザインが完了した後に静的コーディングに入り、静的コーディングでインタラクションなどの挙動を完成させてからWordPressの実装に進んでいました。
CMSの仕様書はデザインフェーズの途中からやんわり着手しつつ、コーディングフェーズ終了までに完成させていたのですが、ブロックエディタになったことで「コーディングせずにデザインFIX後即実装開始」という流れに大きく変わりました。
今まで仕様書作成の時間に当てていたコーディングフェーズがまるっとなくなったため、ブロックエディタでの制作になってからはワイヤーフレームFIXを開始トリガにしてCMS仕様書を作成するようにしました。
全体的な作業期間は短くなったものの、実はブロックエディタ制作になったことで仕様書作成の作業量自体は少なくなっているためあまり大きな影響はありません。
従来のカスタムフィールド（ACF）メインでの制作では、各デザインのフィールド種別や構造をコーディングのタイミングで検討して仕様書に記載していましたが、ブロックエディタメインの制作では実装しながらブロックの構造を決めるので、仕様書にブロック構造を記載できるのは実装が完了するタイミングになります。
加えて、カスタムフィールドの入力タイプと違って運用者が入力画面を想像しづらいため、ブロック構造を細かく書いても運用者との読み合わせ時にあまり理解が深まらなかった…ということもあり、仕様書自体はよりシンプルになっています。
もちろん、カスタムフィールドが全部なくなったわけではないので、カスタムフィールドを持っているテンプレートについてはフィールドの仕様を記載しますし、テンプレート間の情報引用・連携については引き続き仕様書で読み合わせをおこなうために必要です。
新しくカスタムスタイルやブロックパターンの定義を記載するなど増えた要素もありますが、とはいえ全体的に見て仕様書はかなり軽量化されたように思います。
WordPress側のセキュリティ対策
大学サイトに限ったことではないのですが、少なくともこれだけはやっておこうというメモ。
①「SiteGuard WP Plugin」を導入した上で以下の設定を有効にする
管理ページアクセス制限
ログインページ変更
画像認証
ログイン詳細エラーメッセージの無効化
ログインロック
XMLRPC防御（XMLRPC無効化）
ユーザ名漏洩防御（REST API無効化）
REST API無効化はプラグインによっては影響がありますが、最初は無効化しておき、実装中に問題が出たら有効にするかを検討します。
XMLRPCはこれまで使うケースに遭遇したことがないのと、XMLRPCの脆弱性に関しては注意喚起が大学に対して出されていることもあるのでこれも最初から無効にしておきます。画像認証はひらがな一択。
② 上記以外で手動で対応するもの
.htaccess や wp-config.phpを編集して、以下の対応をおこなっておきます。
wp-config.php へのアクセス保護
/wp-content/uploads でのPHP実行の無効化
ダッシュボードからの記事編集無効化
DBのtable接頭辞、SALTのハッシュ値の変更
そのほか
ほぼ自分のためのメモなので、気がついたことが増えたらメモを追記していく予定です。
この記事が気に入ったらサポートをしてみませんか？