2019年12月7日土曜日

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

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




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



朝から多くの実行委員が集まってきました。実行委員長も健在です!
会場の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

2019年10月13日日曜日

WordCamp Asia 2020 の会場に行ってみよう!

WordPress の大きなイベント「WordCamp」のアジア地域での開催(WordCamp Asia 2020)が 2020年2月にタイのバンコクである!ということを聞いて、何も考えずにとりあえずチケットを購入したのでした。それから運良く2019年10月にバンコクにくる用事のついでに会場(ICONSIAM)を見てきました!(他の訪れた場所についての旅日記はこちら)

会場にいく方法はいろいろありますが、歩いていくにしても暑い!最寄りのホテル(ヒルトンホテルとか)でないかぎり、交通公共機関やタクシーなどを使うことになるでしょう。筆者はスカイトレイン(BTS)と呼ばれる電車とICONSIAMの無料フェリーを使って行きました。手軽にいけるので会場(ICONSIAM)までのルートを紹介しますね!

電車(BTS)



Siam 駅を中心に2路線しかありません。ここで乗り換えになります。それだけ知っていれば困りません。現金によるチケット購入は硬貨のみで、紙幣から硬貨への両替窓口が必ずあるので心配ありません。駅にはATMは複数ありますし、場所によっては両替屋もあります。

電車(BTS)で Saphan Taksin で下車し、フェリー乗り場からICOMSIAMへ



タークシン橋の手前の駅、Saphan Taksin で下車します。


構内にマップがあります。実際には1番出口から進んだところのフェリー乗り場でしたが、ICONSIAM のアクセス情報には2番出口から出ろと書いてあること筆者はその情報をもとに2番出口から出たこともあり、2番出口からの案内をします。


改札を出ると、船着き場はこちら(To Sathorn Pier)の案内があります。
そのまま進むと2番出口から出ます。


2番出口をでてまっすぐ進みます!

 

どんどん行きましょう!



するとフェリー乗り場につきます。ICONSIAM 行きの無料フェリーは、右側の橋をわたったところでした。上記写真から右手をみると下の写真の感じです。



ちょうどICONSIAM行きの無料フェリーが止まっていました。上部にICONSIAMって書いてあるから一目瞭然ですね!数十分に1度出ているようなので、来ていなければ待つと良いでしょう。



 乗り込みます!



うん、まちがいなく ICONSIAM 行きですね!



船の中はこんな感じ。帰りはライフジャケットなかったので船によっていろいろみたいですね。結構混んでいて立っている人もいます。



濁っている川ではありますが、少し鑑賞していたら、お!見えてきましたね ICOMSIAM。でかいな!8分ぐらいで ICOMSIAMの船着き場につきました。降りる時かなり揺れるので注意〜。



ICONSIAM の船着き場。帰る時はここに並ぶことになります。



ICONSIAMです、でかいっす!高級感バリバリです!
入った第一印象は、高級デパートに迷い込んだかーという場違い感ですが、しかしグランドフロアには庶民的なエリアもあってそちらは安心して楽しめます!



会場となる TRUEICON HALL は7階です。エレベーターは6階までなので、6階にあがってからエスカレーターで 7階にいきましょう!

ICONSIAM内の写真はあえて載せません。それは参加したときに楽しんでもらったほうがよいと思ったからです!あ!でも1枚だけ載せますね。



そう両替です。ICONSIAM のグランドフロア(G)に両替屋があります。レートはまずまずですかね。なおICOMSIAM は G, UG, 1F という感じで、1F の下に2つ階があります。
1F 以上はまさに高級デパートって感じでめっちゃ高いのでお気をつけを〜。

日本からかなりの人数 WordCamp Asia 2020 に参加されるようですね!皆様 2020年2月、現地でお会いしましょう!

2019年10月13日 @kimipooh



2019年9月13日金曜日

Google開発の画像遅延プラグイン「Native Lazyload」を試してみた! #wordpress

試してみよーと思ってすっかり忘れてしまっていた「Native Layload」プラグイン。




をみるとウェブサイトの画像を遅延読み込みすることで全体的な表示速度を向上しようという仕掛けのようです。たしかに最近の画像はスマートフォンが 1000画素を超えるようになってきて数MBは普通に事になってきましたしね!

翻訳


日本語の翻訳はまだ完成していませんでした。ので分かる範囲で翻訳作業をしましたー。1件だけわからないかったので、誰かによろしくーーー

試す!


とりあえず手持ちで管理しているサイトにいれてみました!!
なお、現在この遅延ロードの恩恵を受けられるのは、 Google Chrome のみのようです!
確かに画像の <img>タグに対して、 loading="lazy" 属性は追加されてますね!!

で、速度はどうなの?


Google PageSpeed Insight


プラグインなし


プラグインあり(有効化)


若干向上してますね!

GTmetrix 



プラグインなし





プラグインあり(有効化)


スコアはほぼ変わっていませんが、 Full Loaded Timeがかなり速くなっていると思います。

このテストサイトは画像が少ないのであまり参考にならないかもしれません。
筆者は今週末から海外にいくので、帰ってきたらメインサイトに順次いれてテストしていこうかなーと思ってます!

2019年9月12日 @kimipooh