• WordPress 4.9.1はJavaScript fileを渡す前に更新と利用者権限を分けて確認する

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を確認して完了します。

戻る