2022年1月29日土曜日

[福井] Fukui WordPress Meetup #15 - サイトの表示速度改善 & 壊して戻そうバックアップと復帰の手順 の会 に参加して #wpfukui #wordpress

 

プログラム:https://www.meetup.com/ja-JP/Fukui-WordPress-Meetup/events/283042791/

今回は、仕事で利用しているさくらインターネットのレンタルサーバーを扱うということで、参加しました。筆者は、サーバー管理者をしていることもあり、皆さん、サーバーのバックアップや復元をどのようにされているのか、考えているのかも知りたいところですね!

WordPress 5.9(フルサイトエディティング機能が実装、これは昨年参加した Kansai WordPress Meetup で体験した)がリリースされたばかりの模様(2022年1月26日)。これについて Meetup が開始されるまで雑談されてました。

以下、各セッションについては筆者が聞いて理解・体験した内容の備忘録です。

「壊して戻そうハンズオン」前半 … サイトのバックアップと破壊編


バックアップ方法は下記のようにいくつか方法がある。しかし重要なのは、「いかに簡単に復元できるか」ということ。

  1. FTP/phpMyAdmin等で手動
  2. プラグイン
    1. All-in-One WP Migration(有償版にしないと使いづらい / uploadの容量制限等がある)
    2. UpdraftPlus今回これでハンズオンにつかう / ドメインを変更する場合には有償版が必要)
    3. BackWPup(バックアップに特化、復元作業は煩雑)
  3. ホスティング業者のバックアップサービス

UpdraftPlusを使ったバックアップとサイトを壊すハンズオン


下記のように、UpdraftPlus プラグインをインストールして、有効化

設定 > UpdraftPlusバックアップを選択

「今すぐバックアップ」ボタンを押してバックアップ
*WordPress フォルダ内にバックアップされる

バックアップができると、「既存のバックアップ」の項目にある5つのボタン「データベース」「プラグイン」「テーマ」「アップロード」「その他」をそれぞれクリックします。

すると下図のようにダウンロードできるようなウィンドウができるので、ダウンロードボタンを押して端末にバックアップデータをダウンロードします。

そして下記のように5つのバックアップが存在することを確認します。

壊す前のサイトトップ画面


そして WordPress を壊します。
まずはさくらインターネットのクイックインストールを使った場合、下図のパッケージに表示されているのでアンインストールします。

次にデータベースも削除します。



これで完全に消えたということになります。

表示速度改善のヒント


サーバー自体のレスポンスが遅く表示が遅い場合には、サーバーのプラン変更やサーバー変更などをするのは大前提。

Google の PageSpeed Insights は、LCP(First Contentful Pain) やCLS(Largest Contentful Paint)、画像フォーマット(次世代フォーマット(webp)で配信しているか等)など最新の評価項目がでているため、評価情報がガラリと変わっている。JQueryは重い。また読み込み時にレイアウトが崩れていると評価が低くなる。

単にサイト表示が速いだけでは高得点にはならない。
表示速度が早くても画像の軽量化をしていない場合などは、点数が伸びない。

また読み込みを遅延する、Native Lazyload(WordPress 5.5から標準サポート)を導入する。head にいれたものを footer に持ってくるとか(jQuery系には影響がでるので、そのあたりは対応が必要)。

WebP への変換(WebPはかなり圧縮率が良い。ただしアイコンなどの場合には逆に増えてしまうこともあるので注意)
Google:https://squoosh.app/
TinyPNG: https://tinypng.com/
WebP Converter for Mediaプラグインを使う。

いろいろ対応すると 95%を超えることもできる。

WebP Converter for Mediaプラグイン:

https://ja.wordpress.org/plugins/webp-converter-for-media/ を使えばメディア画像を WebPに変換できる。
こちらで重要なのは、利用している Webサーバの仕組みが、 Apache(.htaccessが使えること)かそれ以外(NGINX)によって、設定変更が必要だということ。デフォルトは、Apache(.htaccess)が利用できる(さくらインターネットのレンタルサーバ含む)設定となっている。


プラグインインストール後、設定の末尾にある 「Regenerate All」ボタンをクリックして変換をする。

私の持つサイトの一つのケースでは下記のようにそれなりに圧縮できた感じ。

実際の Chromeの要素の検証(Develoer Tools)で png 画像が webpとして読み込まれていることを確認

元を図り忘れてしまったこと、もともと重いサイトだったことを加味すると、まぁそれなりの効果はでているかもしれない。

質疑応答
  • 画像の Alt を設定していないとどうなるか
    • アクセシビリティが悪くなるので、かなり評価が下がる。ChromeのLighthouse 拡張機能を使えば、ユーザ補助の項目がアクセシビリティとなる。
  • 外部画像の読み込みが遅い点はどうしたらよいか(アフィリエイターの視点)
その他の質問応答
  • テーマのテスト環境用のローカル環境は wp-env がおすすめ

「壊して戻そうハンズオン」後半 … サイトの新規作成とバックアップからの復帰編

インストールしたフォルダと同じところに復元する必要がある。
これがわからなくなった場合、先程バックアップしたファイルのうち、 gzip圧縮されたものを展開してファイルをテキストエディタで開くと情報が書かれている

クイックインストールを開始

インストールURLは、壊したサイトのものを選べばよい(まだ残しているなら)。ドメインごと消してしまっているなら、ドメインを新規作成して以前と同じフォルダを指定。データベース作成ボタンから、データベースは新規作成する。こちらは新しい名前でも構わない。

これで WordPressにログインできるようになったはずなので、再び UpdraftPlus プラグインをインストールし、有効化する。



「既存のバックアップ」項目から「バックアップファイルをアップロード」リンクをクリックして、以前バックアップした5つのファイルをアップロードしましょう。



アップロードが終わるとその下に、「復元」ボタンでてきます。これをクリックします。

すると復元する項目がでてくるので、すべてチェックして「次」のボタンをクリックします。

うまくいけば、下記のように Restore successful! という成功のメッセージがでてきます。
その後、「UpdraftPlus 設定に戻る」ボタンをクリックします。

サイトが完全に復元データに置き換わっているので、つまりはユーザー情報も新しくなっていますので、ログインを求めてきます。そのためバックアップする前のユーザーでログインしてください。


うまくいけば、下図のようにもとに戻っていることが確認できるでしょう。
実際には他にもメディアや投稿、固定ページ等いくつか確認するとよいと思います。


質疑応答

筆者は、サイトリニューアルを依頼するときに、以前はMAMPのサイトクローンをいれてデザイナーの人に渡してました(MacなどMAMPごと圧縮して手渡していた)が、いまはもうクローン用のデモサイトを立ち上げて使ってもらってます。

なお筆者はサーバー管理者でもあるので、CUIツールである WP-CLIを組み合わせて自動バックアップ、WordPress更新をしてます。

2022年1月29日 @kimipooh

2021年12月18日土曜日

【オンライン開催】@神戸 #029 &大阪 #6 &京都#2 「サイトまるごと編集が可能になる、Full Site Editingを体験しよう!」・・・ #wpmeetup #WMKOBE #WPMeetupOsaka #WPMeetupKyoto

 今回は、もうすぐリリースされる WordPress 5.9 に実装される、Full Site Editing についてどういうものか先行体験しようとおもって、Kansai WordPress Meetup 参加しました。まだ Gutenberg に非対応な WordPress もある中で、何がどう変わったのかこのあたりで知っておこうということですね。



事前準備(前日)

プログラム

によると、ローカル開発環境として Local を使うということだったので、これをインストール。前日となる 2021年12月17日に、WordPress のデモサイトを1つ立ち上げておきました。

デフォルトでは、PHPバージョンが 7.3系で、WordPress 5.9ベータ版のヘルスチェックで警告がでるので、 PHP7.4系にしておきました。またログイン後の言語を日本語に変更し、タイムゾーンも Asia/Tokyoに変更にしておきました。

 


WordPress Beta Tester プラグインをインストールし、ツール > ベータテストより、下記のように、最前線、ナイトリーに設定変更。

あとは更新メニューから、5.9 ナイトリービルドへ更新します。
2021年12月17日時点では、5.9-beta3-52383 でした。日々更新されるバージョンのため、本番では若干バージョンアップしているかもしれません。

この時点ではテーマが、Twenty Twenty-One となっているので、外観より Twenty Twenty-Two に変更します。

そうすると、従来の外観テーマメニュー(左図)から、新しいテーマメニュー(右図)になります。



これが新しい編集機能の一つになりますね。とりあえずこれで準備は整ったと言えるでしょう、たぶん。

以下、筆者が理解したことのメモを残します。

当日



今年度の初雪であり、さらに積もりました。これをZoomの背景にして参加しました。
冒頭、軽く皆で雑談したあと、始まりました。
参加者数は登録サイトをみると 48名、始まった当初は28名でした。途中 36名になっていました。

冒頭今回の Meetup 開催側で注意事項や WordPress, WordCampの紹介がされた。
その中で気になったものをメモ。

  • 参加したホスティングサーバー側で WordPressのテストを定期的に行って、WordPress がホスティングサーバーで問題なく動くかどうかチェックするプロジェクトとのこと。

自己紹介はブレイクアウトルームにて


最初の4名は、全員知ってるメンバーだったので自己紹介せずに雑談をしていた。
2度目は、過去に新聞記者をされていた方がいた。いまは会社を起こして最近はWeb制作部門を作ったとのこと。話していると時間が足りない。一回5分だそうだ。それを知らずにダラダラと話してしまった。
最後の3度目は7分になった。出版社のインハウスデザイナーが参加された。知り合いもいたので時間が足りないですね。
いずれにしても、話足りないほど楽しかったですね!

その後10分休憩。その間に Local 環境を構築していない人は構築してね!というノリですね。

Full Site Editingをみんなで触ってみよう!


Full Site Editing(フルサイト編集)とは、設定、スタイルからテンプレートやテーマまで、サイトのあらゆるパーツにブロックの操作性と拡張性を導入するもの。
これを実現するためには、WordPress コア(5.9以降)とテーマ(現行は Twenty-Twenty Two)となる。

まずは前日インストールした WordPress 5.9のナイトリービルドを更新(5.9-beta3-52384)。

コンテンツを試すのは、テーマユニットテストデータ日本語版が活用できるよ!
https://github.com/jawordpressorg/theme-test-data-jaから、ZIPダウンロードする。
利用するのは、wordpress-theme-test-data-ja.xml
これを WordPress にインポートするには WordPress Importer プラグインをインストールして有効化する。
するとツール > インポートより、WordPress のインポートが増える。


WordPress のインポーターの実行のリンクをクリック


ファイルを選択ボタンをクリックして、先程の wordpress-theme-test-data-ja.xml を選択。そして、ファイルをアップロードしてインポートボタンを押した上で、出てくる画面の一番下にある「添付ファイルのインポート」をチェックしておきます。


これで実行ボタンを押して待つと、投稿、固定ページ、メディアにサンプルデータがいろいろ入ります。

投稿ページ

固定ページ

メディア


クエリループブロック


  • 投稿一覧を表示するなどをすることができる。

上記のようにクエリループブロックを追加して、「選択」ボタンを押すと、ブロックの設定ができるようになる。ソートもできるようだ。


プレビューという機能が実質なくなっている


編集画面自体がプレビューという考えに対して、様々な意見が飛び交っていた。

自前でフロントページを指定したい場合には、別途フロントページ(テンプレートで作成できるのか)を作って指定してあげる必要あり。フロントページを作ってしまうと、それが優先されてしまうようだ。テンプレートのフロントページを削除したら、ホームのテンプレートがベースになっている模様。

画面上からは page-◯◯.php は作成できない。直接作成(FTP等)で作成できるようだ。ただしテーマに対応している必要あり。子テーマを作ってやる感じ? 

外観を消すなどユーザーが誤操作しないようなツールはあるのか。以前、外観のカスタマイズメニューを削除する方法についてはネットで載っていたので、そこを参考にやってみた。

管理者も含めて、外観のサブメニューの Editor を非表示にする


利用側も管理者権限を有する場合は結構ある。となると、テーマの functions.php に下記のコードをいれておけば、Editorを非表示にできますね。
// のコメントした部分で権限によって除外できたりするようだ。

function remove_menus() {
//  if (!current_user_can('administrator')) {
    remove_submenu_page('themes.php', 'site-editor.php'); // 外観->Editorを非表示  
//  }
}
add_action('admin_menu', 'remove_menus');

従来のテーマエディタを開くためには


  • wp-admin/theme-editor.php
に直接アクセスすると利用できる。


theme.json とかあるけど?


上記をみると、テーマのスタイル変更が JSON によってできる(それまで CSS/PHP でガリガリしなくてよくなるようだ)そうだ。

WordPress のデフォルトテーマはレスポンシブWebデザイン対応しているのか


そういうやり取りがあったので、調べてみた。


をみると、Twnty Twelve の項目のところに
--
The 2012 theme for WordPress is a fully responsive theme that looks great on any device.
--
とあるので、このときからレスポンシブに対応したものと思う。

スクラッチでテーマを作る場合、ブロックも一つずつ作らないといけないのか


ブロックデータがいろいろはいっているプラグインを活用するのもよし。

誰かが作ったデザインを使って、それをテーマとしてカスタマイズする必要がある場合にはどうしたらいいのか


そういう場合には、フルサイト編集はそぐわないケースが多そう。結局は CSS のことを考慮してデザインしてくれないと難しい(非効率でお金がかかる)。

以上、いろいろ議論が活発に続いているところで時間となりました。
今回は知らなかったことをいろいろ聞けてよかったと思います。

その後、オンライン懇親会に突入。22名。
特にフルサイト編集を案件として取り扱う場合にどうすればいいのか、どういう問題があるのか、支払いや見積もりをどうしてる?などの雑談が熱かったですね。19時付近は、パソコン教室のような雑談が続いていました。Windows11の使用感、外部ディスクを接続するとどこにディスクが出てくるのか等。

筆者も家族と夕食を食べたりしていたのでミュートにしながらも、雑談されているのを楽しく聞いておりました。

その他チャット等で出てきた情報メモ



2021年12月18日 @kimipooh

2021年10月31日日曜日

Kansai WordPress Meetup@京都に参加して・・・ #wpmeetup #wpmeetupkyoto

今回のテーマは「WordPressサイトのセキュリティを見直す」とのこと。

大学で運用している WordPress サイトのサーバーは、すべて外部の Web ホスティングサービスへ移行(ほとんどは大学が契約している外部ホスティングサービス)して、もうすぐ1年が経とうとしています。セキュリティ周りについてもいろいろ見直してきましたが、そうしたセキュリティ関連の話を聞けるということで楽しみにしていました。

プログラム:https://www.meetup.com/ja-JP/Kansai-WordPress-Meetup/events/281036210/

おお!?外国人が入ってきて、「日本語でしかやっていないの?」という質問がありました。カフェからの参加でしょうか、英語でのやり取りが見えるので海外からの参加のようです。最初にアンケート(日本語)があったのですが、そちらに回答しない?というやり取りを主催者として、アンケートをされていました。これはオンラインならではのやり取りで面白かったです。

以下、筆者が理解した内容を文字にして書き出しています。そのため、実際の講師の方が意図した内容ではない可能性があることをご留意ください。

WordPress セキュリティガイド 〜うんねい可能なセキュリティを始まるために〜

Yoshinori Matsumoto氏 (Twitter: @ym405nm), WordCamp Kanai 2016で登壇

WordPress 危ないから使わないという話があるが、CMSを変更しても問題は解決しない。必要なことはどのように安全につかうのかということ。

WordPressのログインを守る

wp-login.php (XML RPC含む) が狙われやすく、IPアドレス制限のような負荷をかけることができるのか。あるいは 2要素認証、アカウントロックの機能を入れるという代替もありである。このあたりは、ユーザーがどのように使うのかを考えるということとなる。

パスワードポリシーについて

簡単なものを使われないようにする。Jetpackプラグインに、サイト保護、ホワイトリスト等保護機能を備わっているのでそうしたものを利用できる。

ログイン大丈夫?

WordPress よりも権限の強い、SSH、FTPやサーバーのログインが不正アクセスされると危ない。そのため、WordPress だけを考えるのではなく、そうしたところも考える必要がある。

wp-login.php をIPアドレスをブロックしているが効果はあるのか?

効果はないだろう。IPアドレスはその都度変更されるため。

筆者補足: IPアドレスの範囲(Apacheならホストを使える場合あり)が固定できるなら有用だろうと思う。

BASIC認証をログイン画面にいれるのは?

面倒にしてまでのメリットはない。特にデメリットが大きい。

筆者補足: BackWPUPなど、BASIC認証が有効な場合にはバックアップが拒否されるケースがある。このプラグインではBASIC認証をしていた場合の設定があるので、それをすればいいが、そのあたりを運営側がわかっている必要がある。組織的に管理するなら検討の余地はあると思う。

脆弱性情報を確認する


脆弱性への対応としては、WordPress 3.7 から導入されたオートアップデートを使うことが。これはメジャーバージョンアップはできない。5.7だと 5.7.1 は可能だが、5.8へのオートアップデートはできないということ。WordPress は最新バージョンしかサポートしないことの注意が必要

JPCERT/CCの注意喚起、ホスティング会社の情報はチェックするとよい。

注意事項としては、「認証なし」「外部から」「コード実行」などのキーワードが入ると、特に注意をするとよい。またオートアップデートが動いているかのチェック。

PHPのバージョンが古すぎないか、Webサーバーのバージョンが古すぎないか、Firewallなどサーバーのセキュリティ状況などを調べておくのも大事。

プラグインとテーマを選ぶ


プラグインは、脆弱性を悪用され任意コードが実行されるものが含まれている場合があり(開発者が放置しているプラグインだと危ない)、そこも注意する必要がある。

WebShell 系を仕込まれている場合もあるので注意。

バックアップは大事。無料でバックアップできても、リストアが有料だというプラグインもあるので注意。

WordPressの関数を使う

WordPress が提供するセキュリティ関連の関数はあるので、そうしたものを確認しよう!

事故現場でよくみられるパターン

ファイルアップロードを自前で作ったが、アップロード認証をミスってだれでもアップロードできるようになってしまった。SQLをデータベースに送って処理するプログラムに不備があって、脆弱性になってしまった。

事故はおこってしまう

起こるときには起こってしまう。

50万円ぐらいで構築したサイトが事故ったら・・・初期調査だけで25万円ぐらい掛かってしまった事例もあった。またお金をかけて調査をしても原因が特定できない場合もある(詳細ログを記録していなかった等)。そのため、作り直したほうが速いということになってしまう。あるいは事故が起こった時が明らかで、それ以前のバックアップがあるなら、そこからリストアするということも選択肢としてありえる。また事故ると様々なところに報告が必要になり、膨大な時間と費用がかかってしまう。

質疑応答

以下、質疑応答で興味があった部分の端書きメモ的なもの。

管理者以外 SSO(Googleとか)を使ってログインに使っていることもある。JetPackだと wordpress.com のアカウントにおけるSSO認証ログインが使える。

パスワードに加えて、足し算をして正解しないと管理画面に入れないようにしているが、効果はあるか?

  • 現在の汎用的な総攻撃的なログインは、パスワードが安易すぎるので効果はある。しかし、本当にサイトをピンポイントで狙われると効果が発揮できるかはわからない。
  • 上記リンク先の足し算については、たとえば Google DriveのOCR機能にかけたら正しく文字起こし出来てしまうので、効果そのものはあるが、そうした攻撃をされてしまう恐れはある。
reCAPTCHAは視覚障害者が使えない
  • そのとおり。なかなか難しい
PHPMailerの脆弱性問題があって WordPress のバージョンアップに追われたが皆さんどうしているのか
  • メジャーバージョンアップだと辛いので、細かくバージョンアップするか。そのアップデートを外注するなどするのがよい。
duplicatorプラグインの脆弱性の件で、バックアッププラグインは共通で狙われるのか
  • セキュリティレベルについては、無料か有料かはあまり関係ないとは思う。
OWASP 脆弱診断結果として、どこまで対応したらいいのか
  • レベルだけみても判断できないので、出来ることが限られてしまう場合がある。

座談会


*まったりと始まったが、基本的には講師、司会者以外はチャットでのやり取りとなっていた。

攻撃は海外からきているので、パスワードをローマ字打ちにするというのも効果がある。それが世界的に有名なキャラクター名だと駄目だろうと思う。oを0に置き換えるなどは破られているように思うので注意。

マルチサイトだと、SiteGuard WP が使えないので、All in One WP Security、XO Security などを使ったことがある。

WAFは除外設定しないと駄目なケースがある。除外設定ができない場合には、辛し。

utf8mb4 の文字コードでバックアップしていなくて、ラテン文字のいくつかが文字化けしたことがあった(レストアしたとき)

MovableTypeは日本語ファイル名を英数字に変えてくれる
WordPressでは、 WP Multibyte Patch をいれることで、日本語ファイル名をアップロードすると、変換してくれる。

2021年10月31日 @kimipooh

2021年6月28日月曜日

WordCamp Japan 2021 Online に参加して #wcjpn21 #WordCamp #WordPress

スタッフとして担当以外、実際にガッツリ参加したのは、Day 1 と Day2 でした。

最終日の Day 7 は少し体調を崩していたこともあって、アフターパーティのインフォメーション担当を終えたあたりから眠気がおそってきたこともあり、そこで離脱してしまいました >_<; 金曜日のもくもく翻訳会も参加できなくて残念!

聞き逃したセッションは、下記の WordCamp Japan 2021 の YouTube チャンネルで視聴可能です。

Twitter 上での皆の感想が温かい!


開催中、開催後も Twitter をチェックしてましたが、皆いいコメントばかり!
ブログでも、「実行委員の案内がよかった」「oVice という空間はとてもよかった」などの投稿も結構ありました。
上記公式サイトのブログまとめや、副実行委員である Naokoさんのブログをみると、世界中から 1380名もの参加登録があったとのこと。ものすごい人数ですね!

Day 7 の雰囲気


最終日のセッションを視聴している人は結構多かったと思います。


閉会式では、実行委員長からの謝辞が述べられました。スタッフは 筆者も含めて70名以上参加しており、それらの規模をうまくまとめた実行委員長、副実行委員長、各班長の皆様ご苦労さまでした!


アフターパーティが開催したのち、実行委員から想いなどを語る座談会のようなものが催され、結構な人数が視聴できる範囲へと集まっていました。oVice では視覚的にどの程度あつまって視聴しているかを感じやすいのでよかったです!


スポンサーブースツアーもアフターパーティの最中に開催されましたが、大盛りあがりでした!もはやどこに自分がいるのか分からないカオス的な状況に!


このあたりの途中で、筆者はダウンしてしまったのでした...

次回の WordCamp がオンラインになるのか、対面式あるいはハイブリットのような形になるのかわかりませんが、何某かの形で参加したいと思います!

2021年6月28日 @kimipooh