WordPress 4.9.1はJavaScript fileを渡す前に更新と利用者権限を分けて確認する
公開日: 執筆:佐藤
WordPress 4.9.1はsecurity and maintenance releaseです。更新を後回しにせず、適用後にはJavaScript fileを扱う利用者権限と、公開pageで使う機能を分けて確認します。fileをuploadできないことは、単に不便になったという話ではありません。誰がsiteへ実行されるfileを置けるかという条件です。更新のbuttonを押す作業と、委託先や社内担当へ渡す権限を決める作業は別にします。
WordPress.orgは11月29日、4.9.1を3.7以降に対するsecurity and maintenance releaseとして公開し、直ちにupdateするよう案内しました。4.9以前には四つのsecurity issueがあり、4.9.1ではunfiltered_html capabilityを持たない利用者がJavaScript fileをuploadできないようにしています。これを、すべてのJavaScriptが危険だという意味にはしません。必要なscriptを誰が確認し、どこへ置き、更新後に何を試すかを決めるきっかけにします。
fileを置く権限と記事を書く権限を混ぜない
記事を編集する人が、必ずsiteのscriptを追加する必要はありません。記事本文、画像、問い合わせ先を更新する権限と、themeやpluginに関わるfileを扱う権限は、同じ範囲にしません。日常の更新を止めないためにも、必要な人へ必要な範囲だけを渡します。
仮に、外部の制作者が計測用scriptを追加し、社内の担当者が記事を公開するsiteを考えます。制作者には、変更するfile、目的、確認するURLを渡します。社内担当者には、記事、画像、連絡先を更新するaccountを用意します。どちらもWordPressへ入れるからといって、同じ権限を渡しません。これは実在siteの権限構成ではなく、作業と責任を分けるための仮例です。
| 分ける対象 | 確認すること | 混ぜた場合の問題 |
|---|---|---|
| 日常の更新 | 記事、画像、固定pageの担当 | file管理まで不用意に広がる |
| scriptの追加 | fileの置き場所と目的 | 何が公開pageを動かすか追えない |
| 更新の適用 | WordPressのversionと確認者 | 不具合が出ても変更箇所を分けられない |
| 公開確認 | 読者が使うpageとform | 管理画面だけを見て完了にする |
unfiltered_htmlという名前だけで個別accountの可否を判断しません。siteの設定、利用者のrole、plugin、hosting serviceの扱いによって、実際にできる操作は変わります。必要な作業ができない場合も、安易に強い権限を全員へ渡しません。どのfileが必要か、誰が確認するか、代わりにthemeやpluginの管理者が作業するのかを先に決めます。
更新後は止められない操作から確認する
4.9.1にはsecurity fixのほか、theme template fileのcache、MediaElementのJavaScript error、Windows serverでthemeやplugin fileを編集できない問題などの修正も含まれます。すべてのsiteで同じ問題が起きるとは限りません。しかし、使っていない機能だけを理由にupdateを延ばしません。まずversionを確認し、そのsiteで止められない操作を選びます。
会社siteなら、top page、主なservice page、問い合わせformを開きます。記事を更新するsiteなら、下書きを保存し、公開画面で画像とlinkを見ます。音声や動画を置くsiteなら、再生できるかを確認します。scriptを追加しているsiteなら、表示、form、計測の入口など、そのscriptが関わる画面を確認します。すべての設定画面を順に開くより、読者と担当者が日常的に使う操作を先に見ます。
不具合が出たときは、WordPressのupdateだけを原因と決めません。どのURLで、どのaccountが、どの操作をしたときに起きるかを残します。同じ日にtheme、plugin、script、server設定を替えていれば、それぞれを分けます。制作会社へ頼むときも、画面の状態、直前に替えたもの、困っている操作を渡します。復旧を任せても、domain、server、WordPress管理者accountの所在まで分からなくしてよいわけではありません。
更新前後の差を確認するときは、管理画面だけを見比べません。公開pageを別のbrowserでも開き、menu、画像、form、外部scriptを使う部分を確認します。閲覧者の画面で起きる問題と、管理者だけの作業で起きる問題は、直す担当も優先順位も違います。問題がないことを確認したURLも記録すれば、次の更新で同じ画面から確認できます。
scriptのfile名だけを一覧にするのではなく、何のために読み込むかも残します。計測、地図、予約form、表示の補助のように目的を書けば、不要になったfileを見分けやすくなります。使う理由が分からないscriptを、念のために残すことは安全策になりません。削除や変更が必要なら、公開pageへの影響を確認してから判断します。
権限を戻す判断も記録する
一時的に外部の制作者へ作業を頼む場合は、終わったあとにaccountと権限を確認します。残す理由がないaccount、使わない強い権限、目的の分からないscriptを放置しません。ただし、作業が終わったからといって、記録なしにaccountを消すことも避けます。誰が何を追加し、どのpageで確認し、今後誰が更新するかを残します。
最初の一手は、4.9.1を適用する人、公開画面を確認する人、scriptを扱える人を別々に書くことです。WordPressのsecurity updateは、管理画面のversion表示を替えるだけで終わりません。必要な権限を保ち、不要な権限を渡さず、読者が使うpageを確認して完了します。
関連記事

