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