2020年1月27日月曜日

コマンドツールで MAMP を SSL 対応しよう! - macOS Catalina (10.15) 編 -

基本的なところは
の通りです。Safari、Chromeでは確認済み。Firefoxは警告(警告: 潜在的なセキュリティリスクあり)がでますが、これは前から。まぁ自前でオレオレ証明書を作って、自分で承認する確信犯(テスト環境のため)ですから、それを検知してくれるのはいいんですけど、アクセスはできることと、SafariとChromeでは警告はでないので、Firefoxの警告を消す努力はもういいやって感じです。

さて、これまではうまくいっていたのにだめになった理由は次の通りでした。
にあるように、2019年1月1日以降の証明書については、2つのルールが追加されており、これに対応する必要があったのでした。
  1. ExtendedKeyUsage (EKU) extension にて serverAuth に対応すること
  2. サーバー証明書の有効期限は、825日以下にすること
です。これを探すまで超苦労したのでメモしておきます。なおそれ以外としては
  • 証明書は、RSA 2048bit 以上、TLS であること
  • SHA-2(SHA-256)を使うこと(SHA-1は駄目よ)
  • Subject Alternative name extension を設定すること
は従来どおりになります。

mamp-enable-ssl.csh (GitHUB)

において、configファイルで
  1. ExtendedKeyUsage (EKU) extension にて serverAuth に対応すること
  2. サーバー証明書の有効期限は、825日以下にすること
  3. 証明書は、RSA 2048bit 以上、TLS であること
  4. SHA-2(SHA-256)を使うこと(SHA-1は駄目よ)
  5. Subject Alternative name extension を設定すること
に対応しています。

  1. [user_cert] と [v3_req]において、下記を追加
     extendedKeyUsage = serverAuth
  2. [CA_default]において、有効期限を 700日の設定を追加
     default_days = 700
  3. [req] において、
     default_bits = 2048
  4. [CA_default]において、SHA-2 (256)の設定を追加
    default_md = 256
  5. [usr_cert] と [v3_req] において、subjectAltName = @alt_names を追加
    [alt_names] において
    DNS.1 = localhost
    を追加。
DNS.1 = localhost というのは、実際にサイトでつかうDNS名
[alt_names]
DNS.1 = localhost
DNS.2 = *.test

など複数の指定が可能になる。
逆にここでちゃんといれておかないと駄目ってことになります。

上記対応を1つでもしていないと、もれなくChrome君が



といってきます。すべて対応すれば表示されなくなり



のように安全だといってくれますね!
macOS 10.15 になって一番苦労したのはこれかもしれない...

参考



2020年1月27日 @kimipooh




2020年1月11日土曜日

#33 WP ZoomUP 新年座談会 & WordCamp Asia 情報交換会 に参加して #wordpress #WPZoomUP

WordCamp Asia 2020 に参加することになって、それ関連で WP ZoomUp というオンラインの WordPresss 勉強会・情報交換会を知りました。ちょうど WordCamp Asia 2020 がテーマになっていたので初参加してみました!

Photo by @WP ZoomUP (twitter)
プログラム
WP ZoomUPをささえる会
WP ZoomUP公式報告

WordCamp Asia 2020 はアジア初開催のフラッグシップ WordCamp!



Photo by @WP ZoomUP (twitter)
ということで、私も早い段階から参加申し込みをして楽しみにしています。ちょうど2019年9月にバンコク(タイ)にいく用事があったので、実際に会場となる ICON SIAMにいってきて、どうやっていくのかを
でまとめたりしています。

Photo by @WP ZoomUP (twitter)

WordCamp Asia 2020 ではグッズ販売をしているらしいですが、これは Swag Store での事前注文だそう。現地で直接買えるのはわぷーグッズぐらいみたいですね。

ブレイクアウトセッション


Zoom の機能「ブレイクアウトルーム」を使って4-5名に分かれて自己紹介をしたり、今年の抱負を話し合ったりと少人数グループでディスカッションできたのはよかったです! Zoom は何度か使っていましたが、この機能を体験したのは初めてでした。これいいですね!

タイ語講座


何度かタイにいっていますが、基本的に英語+ジェスチャーでやってなんとかなっているので、一般的なやり取りはなんとかなると思います。でもやっぱりタイ語がわかっていると楽しいだろうなと思いますね。

*カー(女性)、クラップ(男性)が最後につける(プはほぼ発音しない)

こんにちは! = サワディー カー(クラップ)

って感じですが、こちらはサーバーのホスト名に東南アジアのこんにちは(タイ語なら sawasdee)をいくつかつけていたこともあって馴染み深いものです。

マイ = Not 
パイ = Go

ぐらいはわかってましたが、それ以外は知らないので楽しく聞いてました!
私がメモしたのは次の通り、男性なので最後にクラップをつけていますが、女性ならこれを全部「カー」に置き換えてください。
  • ありがとう! / Thank you!
    • コープン(マー / very)クラップ
  • いくらですか? / How much?
    • カオライ クラップ
  • (タクシーにて) ICON SIAM まで行ってください。 / (In taxi) Please go to ICON SIAM.
    • パイ ICON SIAM クラップ
  •  (レストランなどにて) 辛くしないでください。/ (At restaurants) Please don’t make it hot/spicy.
    • マイ ペッ クラップ(マイ(Not)とマー(Very)は意味が真逆なので発音注意だそうだ)
  •  (レストランなどで) お勘定、お願いします / (At restaurants) Check, please.
    • チェック ビン(でいいんじゃない、他の言い方は難しくて)
  • トイレはどこですか? / Where is the rest room?
    • ホン(部屋) ナム(水) ユー(ある) ナイ(どこ) クラップ
  • 辛くないのはどれですか / Which not spicy?
    • アンナイ マイ ペッ クラップ(ペッ マイ クラップ?でOK)
    • ペッ マー(very):とても辛いのーになるので注意
  • 美味しい
    • アロイ
  • Yes / No
    • チャイ(sure)  / マイ チャイ(not sure)的な感じ (受け答えに使うのか)
    • クラップ / マイ クラップ(純粋な Yes / No)のようなものもあるけど、あまりそういうのは使わないようだ。
  • ちょっとまってください
    • ロウ(待て) ベッ ヌン クラップ
とまぁそんな感じかなー。

タイでやってはいけないボディランゲージ


タイでは王室不敬罪というのがあり、これが一番やってはいけないこと。ようはタイ王室に関して批判的なことをいってはいけないってこと。王室不敬罪で禁錮28年 国連がタイ政府に法改正要請(BBC News Japan)にあるように罪が極めて重くなるんですよね。

それはともかくこの会議では
  • 中指を立てる行為
  • 頭を触る行為
は駄目なことで
  • ハグ
はあまり良くない(初対面とかよく知らない人)
  • 握手
あまりしない

ってことのようです。

助け合いのコミュニティ


参加者でチャットのリンクをクリックをうまくできない人がいて、その人に対してみんながフレンドリーにどうしたら解決できるかというのをやっていたのが非常に印象的でした。オンラインチャットというその人の端末環境が見づらい環境にも関わらず、画面共有の機能を駆使したり、いろいろなところにうまくリンクできるように書き込んだりなど、工夫を凝らしていました。こういうのが WordPress コミュニティなんですよね!

では WordCamp Asia 2020 に参加される皆様、あと1ヶ月ちょっとあとにお会いしましょう!

2020年1月11日 @kimipooh

2019年12月8日日曜日

WordCamp Osaka 2019 セッションデイ(2日目)に参加して #wcosaka2019 #WordCamp

 (photo by @wordcamposaka)

筆者は実行委員の広報チームで翻訳を担当してきて、当日はPR班として Twitterでのツイートを頑張っておりました。当日は大勢の人たちが来て、そしてスポンサーブース、セミナー、懇親会もとても盛況で活気が伝わってきてよかったです!


 (photo by @wordcamposaka)

懇親会最後に実行委員有志から実行委員長のお二人にサプライズプレゼントをしました!「大感謝 名前」のラベルが入ったお酒と有志からの寄せ書きです。いずれのデザインも実行委員の手によって作られました!これには実行委員長も最初は驚き、そして写真にあるように満面の笑みを浮かべ、それからしばらくして号泣。まわりも釣られて何名かが号泣!という感じになりました!感動やこれまでの苦労、達成感が後から押し寄せたのでしょうか。こういうのいいですよね!

さて「ブログを描くまでが WordCamp」と言われています。そう、WordCamp で体験したことをブログを通じてより広めて、より多くの人に知ってもらいたいという思いもあるんじゃないかなと思っています。すでに一日目はブログを公開していました。

WordCamp Osaka 2019 コントリビューターデイ(1日目)に参加して #wcosaka2019 #WordCamp

以下は、二日目になります。


 (photo by @wordcamposaka).

メインセッションは、ライブ中継(https://www.youtube.com/watch?v=47qD2o3S3Aw)されてました!これらのセッションについては、WordPress tv(https://wordpress.tv/)に後日掲載されます。
二日目であるセッションデイは、Twitter 班として張り付いていたため、ガッツリとセッションは見てませんでした。


  (photo by @wordcamposaka).

いくつかみたセッションは盛況でしたね!

今回会場の都合でわぷーカフェとして飲食物を提供している部屋のみ、イベント側が用意した飲食物のみ飲食可能ということでした。筆者も PRチームとしてこの部屋にスタンバって Tweet を頑張ってましたよ!


 (photo by @wordcamposaka)


またレジン工作は子供の楽しんでましたね!



 (photo by @wordcamposaka)

セッション:Google検索最新情報 2020





毎年聞いていて、これは聞いておきたい!ということで遅めの昼食をささっと食べて参加しました。個人的にも雑談でき、いろいろ興味深い話が聞けてよかったですね。

PHP バージョンをあげる手順(ハンズオン)



 (photo by @wordcamposaka)


参加したわけではなく、この部屋に PR班として常駐していたため話を聞けた!という感じです。いくつかのレンタルサーバーの担当者が参加しているので、とても実践的だったなと思います。各レンタルサーバーの担当者が、そのレンタルサーバを使っている参加者にはりついて直接サポートするという豪華なハンズオンです!すごいですね!知り合いは、まさに PHP7 へのアップデートを相談されていたということで、とてもタイムリーで貴重な情報を得ることができたと感動していました!また来年も来る!っていってました。これこそまさにイベントをして良かったなと思う瞬間ですね!

昼飯






大阪工業大学梅田キャンパスの21階にある菜の花食堂で食べました!
美味しかったのですね!ただ14時ぐらいに食べたことと、わぷーカフェでお菓子を食べすぎてちょっと胃もたれ気味です (T_T;

懇親会




 (photo by @wordcamposaka)

とにかくものすごい人数が参加して熱気や活気あふれる懇親会だったなと思います!

また来年もいきたいですね!その前に、WordCamp Asia 2020 が来年2月にバンコク(タイ)であります。どうやら日本から70名ほど参加されるようで、全体として1000人を超える規模になるとか!ものすごい規模になりそうです!筆者も参加予定でワクワクしますね!筆者は10月にバンコクにいく用事があったので、会場となる ICONSIAM に行ってきました!そのことは、WordCamp Asia 2020 の会場に行ってみよう!で紹介しています!英語ができないけどとりあえず申し込んだっていう人もいますし、とにかくいろいろな経験や体験をしたいのなら参加してみてはどうかなと思います!

2019年12月8日 @kimipooh

2019年12月7日土曜日

WordCamp Osaka 2019 コントリビューターデイ(1日目)に参加して #wcosaka2019 #WordCamp

通勤ラッシュに巻き込まれつつ、8時半ごろに会場入り。
クリスマスの時期ですよねぇ。

2日 目のセッションデイについてのブログはこちら






実行委員(スタッフ)のユニフォームは、パーカーでした!



朝から多くの実行委員が集まってきました。実行委員長も健在です!
会場のWi-fi ありますが、ちょっと遅い感じはしますね。

さて今日はコントリビューターデイ。日本の WordCamp で初めてコントリビューターデイをしたのが、WordCamp Osaka の前身になる WordCamp Kansai の 2014年にあたり WordCamp Kansao 2014でした(「日本のWordCampで初めての試み!コントリビューターデイってなんだ?」参照)。このコントリビューターデイとは、WordPress の何かに貢献しようっていう催しです。WordPress について歓談やディスカッション、相談するだけでも、誰かの刺激になったり、何らかのヒントで新しいものが生み出される可能性もあります。

挨拶&チーム分け



今回始めてコントリビューターデイにきたって人がかなりいたことに驚きました!いいですね!いくつかのチームに分かれて作業するということで、チームメンターの紹介とそれぞれのチームでどのようなことをするのかの紹介がありました。

  • 全体のメンター:Mike Schroder 氏(WordPress 5.3 のリードをされていた、Core やメディアコンポーネンツについてになるけど、でも何でも聞いてもいいよって感じ)
  • Core チームメンター:Kite 氏(WordPress 本体のメンテナンス、Gutenberg 含む)
  • WP-CLI チームメンター:Sumida Ippei 氏(WP-CLI コマンドのメンテナンス)
  • Help Hub チームメンター:Tachibana 氏(WordPress のマニュアル移行・翻訳)
     参考:日本語版CodexからHelpHubへの移行ボランティアを募集中
  • Polyglots チームメンター:高野氏(翻訳)
  • WordPress.tv チームメンター:Hayashi 氏(WordCamp セッションの動画編集やアップロード、字幕をつける)
  • Theme Review メンター:Shiva Shanker Bhatta 氏, Ganga Kafle 氏(テーマレビューのリードをしている、インドのネパールから来訪。すでに公式リポジトリへ申請しているテーマの審査をやってみる)
  • Community チームメンター:額賀氏、GOUTEN 氏(WordPress Meetup の申し込みやオリエンテーション、 ダイバーシティースピーカートレーニングの翻訳、WordPressの記事)
  • JP WordPress Hosts Community チームメンター:Taniguchi 氏(WordPress のホスティング。PHP5.3使っているけれど、どのサーバーがいいだろうとか)

筆者は、筆者開発のプラグイン改良でもしようかなーと漠然的な感じでしたが、プラグインチームがなかったので、よくお世話になっている WP-CLI について貢献できるようになっておこうかなと思い立ちました。

WP-CLI チーム


公式マニュアル:https://make.wordpress.org/cli/handbook/contributing/

記事:https://make.wordpress.org/cli/2018/07/14/contributing-to-wp-cli/

GitHub: https://github.com/wp-cli/


事前準備


  1. WordPress.org のアカウントを作る
  2. WordSlack のアカウントを作る
  3. WordSlack にログインして、#cli チャネルを追加する
  4. GitHub アカウントを作る
  5. https://github.com/wp-cli/ の good-first-issue ラベル を探してみる
     これは初めてやる人用で、初めてでなければ rejectされる
  6. composer のインストール
  7. hub のインストール(brew install hub)*こちらは必要ならという感じ
  8. 何をするか決まったら WordSlack の #cli でつぶやいて、リポジトリを Fork する
  9. Forkしたものをローカルにクローンする
  10. クローンしたディレクトリで、composer install --prefer-source を実行する
     参考:https://make.wordpress.org/cli/handbook/pull-requests/#setting-up


    1. Script ./utils/git-setup-pre-commit-hook handling the post-install-cmd event returned with error code 1 とでてインストールが失敗する
    2. 一度クローンしたディレクトリを消して入れ直しても同じエラー
    3. ここの情報「.git/hooks/pre-commit を作れ」と、ここの情報「git clone https://github.com/mautic/mautic.git にある ./build/hook/pre-commit を使え」を参考に、https://github.com/mautic/mautic.git の ./build/hook を .git/hooks にコピーした。 
    4. すると警告はでるもののインストールできた。

      うーん、何故だかスッキリしない!昼食を食べた後にもう少し検証
    5. 検証結果
       git clone URL : OK
       Sourcetree (3.0 (200) でも4.0 (232)でも)最新ので Clone すると、上記エラーがでてしまうことが判明。Soucetree 内蔵の git が少し古い(2.20.1)のが原因なのかなぁ。システムのほうは 2.21.0 だし。
  11. クローンしたディレクトリの bin/wp を wp コマンドとして実行できるようにする
     cd クローンしたディレクトリ
     alias wp="`pwd`/bin/wp"
  12. branch を切る


ちなみに参加者はエンジニアばかりだった(バックエンドエンジニアが多い)。まぁそうですよね。

https://github.com/wp-cli/wp-cli/issues/4874 にチャレンジ


STEP 1. コーディング

Remove `WP_CLI\Utils\is_bundled_command( $command )` again #4874
ということなので、is_bundled_command を探すと、

php/utils.php
    function is_bundled_command( $command ) {

tests/test-bundled-commands.php 
$result = Utils\is_bundled_command( $command );

の2つがヒットしました。

1. tests/test-bundled-commands.php  は削除
2. php/utils.php
     function is_bundled_command( $command ) {
はコメントも含む関数ごと削除

STEP 2. コードテスト


1. Code style sniffers

composer phpcs

で問題なければ次へ

2. Function tests

mysqlデータベースが必要。もし準備が出来ていなければ
env: mysql: No such file or directory
Script run-behat-tests handling the behat event returned with error code 127
Script @behat was called via test
のようなエラーがでる。

筆者の macOS はちょっと前にクリーンインストールしてしまったので、mysqlは入っていない。Homebrew はインストールしていたので、「Macでmysqlを扱う方法
を参考に、

brew install mysql
にてインストール
brew services start mysql 
にて MySQL データベースを起動
mysql -uroot
で mysql データベースにログインできることを確認
なおこのデータベースはパスワードなしで特権ログイン(root)できる。まぁ一時的なインストールだからいいでしょう。
mysql> create user 'wp_cli_test'@localhost identified by 'password1';
にて、wp_cli_test ユーザーを作成(パスワードは password1)
mysql> create database wp_cli_test;
にて、wp_cli_test データベースを作成
mysql> GRANT ALL PRIVILEGES ON wp_cli_test.* TO "wp_cli_test"@"localhost" IDENTIFIED BY "password1";
wp_cli_testユーザーに wp_cli_test データベースに権限を付与するコマンドでエラー
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by "password1"' at line 1
によれば、mySQL 8 からコマンド構文がかわったとのこと。
mysql> GRANT ALL PRIVILEGES ON wp_cli_test.* TO "wp_cli_test"@"localhost";

かな。

composer behat

かなり時間がかかります。

    Error: Error establishing a database connection. This either means that the username and password information in your `wp-config.php` file is incorrect or we can’t contact the database server at `127.0.0.1`. This could mean your host’s database server is down.

とエラー。
をよく見ると、mySQL 8の場合の注意事項がありました。

mysql> ALTER USER 'wp_cli_test'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password1';

を追加したらいいのか。

composer behat

...
.F-------............................................................. 1260
...

(::) 失敗したステップ (::)

01. $ wp db query 'UPDATE wp_blogs SET domain = NULL'
    
    ERROR 1048 (23000) at line 1: Column 'domain' cannot be null
    cwd: /var/folders/t7/3x5g378s45s246158trdylvm0000gn/T/wp-cli-test-run-framework.feature.313-5de9f542b305c0.53752291/
    run time: 0.43459987640381
    exit status: 1
    In step `And I run `wp db query 'UPDATE wp_blogs SET domain = NULL'`'.         # vendor/wp-cli/wp-cli-tests/features/steps/when.php:29
    From scenario `Display a more helpful error message when site can't be found'. # features/framework.feature:313
    Of feature `Load WP-CLI'.                                                      # features/framework.feature

197 個のシナリオ (196 個成功, 1 個失敗)
2139 個のステップ (2131 個成功, 7 個スキップ, 1 個失敗)
15m33.818s

うーん、もうちょいか。しかしテストに15分かかるのね・・・。

> run-behat-tests
/***/wp-cli/vendor/bin/run-behat-tests: line 12: jq: command not found
(23) Failed writing body

と最初に jq コマンドがないというのが気になりますね。
によれば、 brew install jq でインストールしてみた。

composer behat

jq エラーはなくなったものの、同じところでエラー出ますねー。

*エラー出たところだけ再テストは
composer behat-rerun
で出来る。

しかしこれは、mySQL 8 ではまだうまくいかないのですかねぇ。
https://qiita.com/sato11/items/ba887a5655217f60f2a2
を参考に、mySQL8 を消して 5.7をいれてみる。

brew services stop mysql
brew remove mysql
brew cleanup

https://qiita.com/sato11/items/ba887a5655217f60f2a2 をみて削除
/usr/local/etc/my.cnf も削除

brew install mysql@5.7
brew services start mysql@5.7
/usr/local/opt/mysql@5.7/bin/mysql -uroot
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

sudo touch /tmp/mysql.sock
brew services restart mysql@5.7

でも駄目だなぁ。まぁこれはやめて mysql 8 の環境に差し戻し。

あらためて

composer behat

ここで時間切れ(16時30分)。


3. Units test

composer phpunit

こちらは 2 の functions test の前にやってみたが問題なく通過した。

上記すべてのテストを一括でやる場合には

composer test

とのこと。

pull request までいけなかったのは残念ですが、テスト環境の構築やそのためのエラー解決方法については体験できてよかったと思います。

筆者は過去のコントリビューターデイで何をしていた?


間近の 2年(2017年以降)だと、プラグイン開発、プラグインのマニュアル作成、翻訳をおもにやってました。






昼食





かっぱ横丁にある古潭老麺(古潭ラーメン)で食べました。


閉会

以下筆者が聞いて覚えている内容。そのため発表が正確に反映されていないことに注意。

Core チーム発表

Core については subversion を使わずにできるようになっているということ
git で出来るとのこと

WP-CLI チーム

good first issue から貢献できそうなものを探してやってみという形態だった
pull requests が 1件できて、作業中が2件あった。

Help Hub チーム

古い Wikiページ から新しいシステム(Help Hub)へ移行するというものだった。
皆で文体などのルールを読んでもらった上でやってもらった。
26文章が更新されていた。


Polyglots チーム

かなり進んだ。

WordPress.tv チーム

WordPressを知っていますか?(15分動画)に日本語字幕をつけた。
1人1分担当し完成して公開したよ!
その他にもやった。

Theme Review チーム

レビューは言語とコーディングの壁があって大変だった。
けれども、全くレビューをしたことがなかった方を 3名迎えることができたことが非常に大きいとのこと。

Community チーム

いろいろ出来た模様

JP WordPress Hosts Community チーム

本当に PHPバージョンアップすると生きて帰れない(トラブって大変なことに)人もいるので、PHP のバージョンアップのライフサイクルなどのノウハウの共有を行った。そしてどのようにユーザーが利用しているサーバー上で WordPress を快適に使えるかについてディスカッションし、その結果をまたフィードバックしたいということ。

実行委員長より

明日のセッションデイの紹介

懇親会(スピーカー&実行委員)





WordCamp ではおなじみのスピーカーとの懇親会。いろいろ歓談できて楽しかったです!

日時が変わって本日はセッションデイ!
いろいろおもしろい話がきけることを楽しみにしています!

2019年12月7日 @kimipooh

2019年11月16日土曜日

[大阪] Kansai WordPress Meetup Osaka #4 に参加して #wordpress #wpmeetuposaka

my_theme_setup WordPress Meetup が日本で始まってから、なかなか都合がつかなくてずいぶんご無沙汰になっていました。
前回は1年ほど前に参加した


でしたね。今後はもっと参加していかねば!



夜はイルミネーションが綺麗でしたよ!

会場




今回の会場は本町にある「本町オープンソースラボ
ステーツ本町の 8F にありました。
私は初めて訪れた場所でした。方向音痴な私ですが、スマホも新しいものに変更し、以前マグネット式ケースを使っていたためにスマホの電子コンパスが動かなかった問題も解消して無事迷わず参加することができました!

冒頭、GOUTEN さんによる WordPress、Kansai WordPress MeetupWordPress Camp Osaka 2019 などの説明があった。20名ぐらいが参加していたなという感じです。人数が少ないということで、次に自己紹介ありました。海外から来られている人、世界中を旅するバックパッカーなど多彩な人たちも参加してましたよ!



最後に、WordPress Camp Osaka 2019 の紹介が、実行委員長からありました!



筆者も広報チームとして翻訳作業を主にしてまーす!みんな気軽に参加してね!

セッション「ブロックエディタの話をしよう!」



Gutenberg がでたときには、HTMLソースコードが崩れてしまうなど多数ある既存 WordPress サイトを移行し、各担当者にそれを教えるのが大変だったこともあって、 Gutenberg を無効にして先延ばし対応してました。そろそろ本腰をいれて、Gutenberg について詳しくならないとなーと思って参加しました。

実際に聞いた印象として、内容がブロックでデザイン・レイアウトのコーディングをしたことがある中級者レベルのように思いました。React や PHP コードも理解していないとわからなさそうかなぁという感じでですね。WordPress のプラグインは開発していますので PHP コードはわかりますが、React や デザイン・レイアウトは全く分かっていない筆者には理解できず。まぁとりあえずかなり面倒だけど、ブロックをカスタマイズすると利用者にとってはかなり便利そうだなという印象をうけました。

筆者としてはテーマは構築や更新も含めて全部外注等誰かにまかせているので(何十とある管理運用サイトがあるなかで、下手にいじるとおかしくなったり、以後メンテナンスをやらないといけなくなるのは物理的に無理なので)、どういう任せ方をしたらよいのかが理解できたらいいかなと思ってます。

以下、筆者がメモった発表内容です。
筆者はプラグイン開発者ではありますが、テーマについては素人(デザインやレイアウトの中身はわからず、ファイル構造ぐらいしかわからない。React は名前しか知らんぞ!って感じ)ので、その筆者が興味のあったところのみしか紹介していません。また聞きながらメモったので、筆者が理解した内容になります。そのため、実際に発表内容と場合によっては異なってしまっている可能性があります。

ブロックエディタのカスタマイズ


editor-styles は必ず設定するようにしましょう。

function my_theme_setup(){
   add_theme_support('editor-styles');
   add_editor_stype('style-editor.css');
}
add_action('after_setup_theme', 'my_theme_setup');

https://wpdocs.osdn.jp/Editor_Style をみたら、 add_theme_support は必要なさそうかなぁとおもったが、さてどうだろう。

既存のブロックの拡張


つまり class 属性を付与して、CSS でデザインをカスタマイズができないかということ。


wp.blocks.registerBlockStyle で、スタイルの設定を記述する。

const { registerBlockStyle } = wp.blocks;
registerBlockStyle ('core/quote', {
   name: 'hoge',
   label: 'ほげ',
});

とかするといいらしい。
# registerBlockStyleでブロックに独自のスタイルを追加する(Capital P)をみて追加してみたが、うまくいっているように見えない。まぁ筆者がちゃんと分かっていないだけでしょう。一応メモしておく。
テーマの functions.php に

add_action( 'enqueue_block_editor_assets', function() {
wp_enqueue_script( 'my-style-selector', get_template_directory_uri() + '/editor-helper.js', [ 'wp-blocks' ] );
} );
を追加して、wp-content/themes/twentytwenty/editor-helper.js に、
const { registerBlockStyle } = wp.blocks;
registerBlockStyle ('core/quote', {
   name: 'hoge',
   label: 'ほげ',
});

を追加したのだが、追加されていないなーという感じ。まぁ現時点で正しく理解できていないだけでしょう。

ブロックを作るための準備


  1. https://github.com/torounit/my-first-block をダウンロードし、展開(解答)する。展開したフォルダを「my-first-block」とする
  2. プラグインフォルダ(wp-content/plugins)に「my-first-block」を移動する
  3. WordPress 管理画面のプラグインに出てきた「my-first-block」を有効化する

ただしこの使い方は説明なかったので分かりませんでした。

ブロックを作ってみよう


本体側(register_block_type)、JS側(registerBlockType)でブロックの登録が必要。


# とはいえプラグインを有効しても使えない。
コードをみただけでは理解できず、これは初心者向けのハンズオンあたりに参加するなどしないと駄目かなぁ。

とはいえ、とにかくブロックを追加してみたい!ってことで、ネット検索している


を見つけた。おお、WP-CLIでできるのか!これはやってみなければということでやってみました。

wp scaffold plugin guten-blocks --skip-tests --activate

として、 wp-content/plugins/guten-blocks を作成した上で、

wp scaffold block first-block --category=formatting --title="hello custom"  --plugin=guten-blocks

をすると、wp-content/plugins/guten-blocks/blocks が作成される

wp-content/plugins/guten-blocks/guten-blocks.php の末尾に

require_once( plugin_dir_path( __FILE__ ) . 'blocks/first-block.php' );

を入れる
するとブロックの「フォーマット」に「hello custom」ブロックが追加されていますね!


ふむふむ、これなら私でもブロックを追加することぐらいはできますね。


管理画面でブロックが簡単に使えるよっていうプラグインのデメリット


  • プラグインを無効にすると、消えてしまう
  • 仕様変更でプラグインが対応しない場合、動かなくなるかも
  • DBに入っていないので、検索なども聞かない

とはいえ、プラグインによる実装は便利ではあるので、ブロック1つごとにプラグインを作ってリリースするなど、影響範囲を限定する方式もあるよ。


まず、React と仲良くなる


ということのようです。

# 確かにその通りだよなぁと思いました。

Block Editor Handbook



あたりに少し和訳しているサイトがありましたね。お!ここをみると


を使うのが便利だということですね、ふむ...


ブロックごとの仕様を定義する必要がある


更新するユーザーが使いやすいか、ユーザーが意図しない動作をしないか、そういうことを考えておく必要がある。

可能な限りカスタマイザーを使わず、全てブロックエディタ上で完結したほうが、ユーザーとしては、ブロックエディタとカスタマイザーの行き来をしなくてよく混乱が避けられるのではないか。

カスタムブロックを大量につくっても、ユーザーは使いこなせないだろう。


質疑応答&ディスカッション


特に結論があるわけではありません。聞いた話で頭に残ったものをメモしているって感じです。


  • 何故プラグイン化するのですか(テーマに埋め込むのは何故ダメなのか)
    • テーマにいれてしまうと、テーマが消えたり変更したら使えなくなるのはまずいのではないかというコンセプト
  • 移行はどうしたらいいのか(クラシックエディタからの変更)
    • 担当者がウェブの知識がまったくない、入れ替わりもある中で、どうやって教えるのか。いつかは変えないといけないが。なかなか難しいテーマ。
  • Classic Paragraph と クラシックブロックの2つが出てしまう
  • 新規サイトで Classic エディタを使うのは問題か
    • いろいろなブログをみて、まだ 使いたいテーマなどが Gutenberg に対応していなかったりする場合もある。すでに1年前に新エディタはリリースしているわけで、新しく立ち上げるなら新しいほうがいいのでは。でも修正が初学者には難しくなってきている。

その他メモ





昼食



- 口コミ(TripAdvisor)

本町オープンソースラボにいく道すがらあったカフェ。どうやらオープンしてまだ間もないようですね!おしゃれな感じの店内で、食べたカルボナーラも美味しかったです!

懇親会




- 口コミ(TripAdvisor)

いろいろ歓談していたら、いつのまにか3時間たっていました。さすがに終電が近いので2次会はパスでそのまま帰りました。みんなの熱い会話を聞きながら、やっぱりこういう雰囲気っていいし、自分なりのモチベーションが上がってくるのを感じるので、定期的にいかないとなーと思ったのでした。

2019年11月16日 @kimipooh
 











2019年11月1日金曜日

WordPress のプラグインバージョンアップ中にブラウザを閉じたらどうなる?

WordPress のプラグイン更新方法は、WP-CLIなどコマンドラインからも可能です。それは脇において、WebブラウザからWordPressにログインし、「更新」よりプラグインを更新している途中に、ブラウザを閉じたらどうなるでしょうか。

のようなブログをみると、メンテナンスモードのままになるよって書いてあります。そのとおりなんでしょうが、こういったものは実際にテスト環境で体験してみるのが一番いいなと思ったのでやってみました。

ブラウザを閉じた時点で強制処理が終了する


実際にローカル環境にいれたマルチサイト環境のWordPress で試してみました。
するとサイトがメンテナンスモードになったままログインできない事態に・・・


この段階でブラウザを閉じてみると


のようにメンテナンスモードが解除されずにサイトにアクセスできなくなりました(運が良ければメンテナンスモードにならない)しました。こちらは、WordPress本体にできたロックファイル「.maintenance」を削除することでメンテナンスモードは解除できます。FTPなどでサーバーにログインする必要がでてきます。

このメンテナンスモード用ファイルを削除してプラグインを見てみると、更新中だった Loco Translate までは更新できていて、あとは残っている感じですね。


基本的に WP-CLI のコマンドラインでサーバー上で自動アップデートしているので気にしていませんでしたが、ブラウザ上でやるのってネットが不安定だと問題が発生するんだなぁと思った瞬間でした。。。(ネット不安定な海外からやっちゃうと危ないってことか)。場合によってはプラグインが壊れて、壊れたプラグインを探し出して一旦削除しないと駄目なんて事態になるかもしれません。なんでも試して見るものですね。

2019年11月1日 @kimipooh