シングスブログ

中小企業のマーケティングやブランディングのコンサルティング。事業開発 (ビジネスモデルの開発)、デジタルマーケティングやウェブサイト改善など事業の持続的・長期的な成長・発展に貢献できるサービスを提供しています。

ウェブサイトパフォーマンス向上のためのWordPressプラグイン「Better Website Performance」を作りました

公開日: 更新日: 投稿者: thingsym

ウェブサイトのパフォーマンス向上のための WordPressプラグイン「Better Website Performance」を作りました。

最近のウェブサイトは、ウェブページの読み込みや表示速度 (PageSpeed) などパフォーマンス面も検索エンジン対策 (SEO) において検索順位を決める重要な要素の一つとなっています。そのため、個々のウェブサイトで適切なパフォーマンスを発揮し維持するためにサイト最適化が求められています。

WordPressプラグイン「Better Website Performance」の主な機能は、以下のとおりです。

HTML ヘッダー最適化

WordPress によるメタタグや rel=link 出力を最適化します。

絵文字

WordPress に実装されている絵文字リソースを最適化

レスポンシブ画像 (image srcset）

WordPress に実装されているレスポンシブ画像 (image srcset) を最適化

非同期 JavaScript

非同期 JavaScript を管理します

jQuery

jQuery の読み込みを管理

CSS の結合やインライン化

スタイルシートファイルの読み込みをインライン化したり、縮小化、または結合します。

追加 CSS

WordPress に実装されている追加 CSSをヘッダーに配置します

Resource Hints

リソースを事前に読み込んでパフォーマンスを向上させます

Preload

リソースを事前に読み込んでパフォーマンスを向上させます

WordPressプラグイン「Better Website Performance」

WordPress開発環境「WP Compose」をつくりました

公開日: 更新日: 投稿者: thingsym

Docker の WordPress開発環境「WP Compose」をつくりました。

Vagrant (VirtualBox) による WordPress開発環境「VAW (Vagrant Ansible WordPress)」を 7,8年開発し続けていましたが、そろそろ開発環境を Mac (Apple chip) に完全に移行したいと思い、開発に着手してみました。

当初、docker-compose.yml ひとつのファイルだけで簡単に WordPressサイトを立ち上げられるので「開発環境はもう必要なさそうだなぁ」と思っていましたが。

やはり開発環境としては、HTTPSをサポートしたり、メールテストが不十分なところがあったり。複数の開発環境 (コンテナ) を立ち上げるには、localhost においてポートの割り振りを考えたり、使い続けるには面倒なところがある。ネット上に幾多ある技術系ブログにある「DockerでWordPressのローカル開発環境を構築する」の類の記事を見ると、ほぼ localhost ベースのローカル環境の初歩的な部分しか解説がないので。

本格的に開発環境として使っていくためには、もう一歩踏み込んだところが必要だなと。Dockerの開発知見を溜めつつ、開発生産性の向上を目指して開発環境を目指してみました。

目指したこと

目指したことは、

  • Mac (Apple chip) に最適化
  • 今までの開発リソースがそのまま使える (ドメインが使える、テストリソースがそのまま使える)
  • テスト環境の整備の手間なくユニットテストができる
  • 設定ファイル (.env) で開発環境のカスタマイズができたり、複数の開発環境の管理を容易にする
  • 開発リソースを開発環境から分離管理

特徴

開発の結果、以下のような WordPress 開発環境になりました。

詳しい「WP Compose」の技術要件や使い方は、GitHub にある README ドキュメントを見てください。

  • localhost でサクッと WordPressサイトが立ち上げられるし、開発が捗るビルド・ユニットテスト用のコンテナも立ち上げられる。
  • コマンドラインツール WP-CLI を使ったり、HTTPS をサポート、MailHog によるメールテスト
  • 面倒なポートの管理をしないで複数の開発環境を立ち上げられるアプローチに Local Loopback Address で開発用 IPアドレスを決めるだけ。hosts でポート指定の必要なくドメイン名でアクセスできるように。

成果

実際に Docker開発環境にしてみて。

  • Intel chip Mac 上での Vagrant (VirtualBox) 開発環境から Docker開発環境へスムーズな完全移行 (データベースデータの変更をすることなくドメイン名も引き継ぎ)
  • いままで開発しているテーマやプラグインのリソースを開発環境のリソースと一体化していた状態から分離管理した (ディレクトリレイアウトが明確に、誤って削除を避けられる)
  • 開発用IPアドレスを複数の開発環境に振り分けて整備が容易になった
  • ユニットテスト用のコンテナで開発しているテーマやプラグインをビルドしたり、ユニットテストを今までのテストリソースを手直しなく、損なうことなく実施

今後を見据えて

WordPress のテーマやプラグインを開発するに際して最適な開発環境がなかなか見つからない。どのような開発環境を選べばいいのか。開発生産性を高めたい。など悩みも多いものです。

最近の WordPress開発は、開発言語が PHP から React (JavaScript) に比重が移りつつあり、スキルの再構築 (学び直し) や WordPress自体どんどん変わっています。その変化についていけなくなり、テーマやプラグインを積極的に開発する開発者も少なくなっている感があります。

そのような中、開発環境や基盤整備にリソースを割けることが難しいことが障害になっていることも多いと思います。WordPress開発環境「WP Compose」が、少しでも開発生産性に寄与でき、お役に立てれば幸いです。

ぜひ、WordPress開発環境「WP Compose」を試してみてください。

ブロックエディタを拡張するWordPressプラグイン「Editor Bridge」をリリースしました

公開日: 更新日: 投稿者: thingsym

WordPressプラグイン「Editor Bridge (エディタブリッジ) 」は、デフォルトのブロックエディタを拡張するプラグインです。

デフォルトブロックの機能を拡張したり、フォーマットやスタイルを追加してみました。どのようなことができるかを確認できるサンプルページを作りましたので、そちらをざっくり見てみてください。

WordPressプラグイン「Editor Bridge」で、できることは大きく3つ。

1つ目は、デフォルトブロックの機能を横断的に拡張します。 デフォルトブロックに背景画像や枠線 (ボーダー) を付けたり、マージンやパディングなど余白 (スペース) を設定できます。またボタンのサイズや幅など各種設定ができるように設定パネルに追加しています。

対応しているブロックは以下の通り。

  • Background image (背景画像)
    • core/heading
    • core/paragraph
    • core/column
    • core/columns
    • core/group
  • Border (æž ç·š)
    • core/heading
    • core/paragraph
    • core/group
  • Button size and width (ボタンの大きさと幅サイズ)
    • core/button
  • Space, Margin (upper margin as default) and Padding (スペース)
    • core/heading
    • core/paragraph
    • core/image
    • core/button (only Margin)
    • core/buttons
    • core/media-text (only Margin)
    • core/gallery (only Margin)
    • core/list (only Margin)
    • core/table (only Margin)
    • core/columns
    • core/column (only Padding)
    • core/group
    • core/cover

2つ目は、見出しや段落など文字を入力するところに使われる RichText Component にフォーマットを追加。文字の大きさや太さを変えたり、文字を装飾する強調やバッジが使えます。

バッジはちょっとしたアクセント用のテキスト装飾に、強調は文章の一部を強調できます。ブロックにスタイルがあるように、フォーマットにもスタイルが選べるようにしてみました。

  • Badge (バッジ)
    • Default (デフォルト)
    • Round Corner (角丸)
    • Round (円形)
    • Outline (アウトライン)
    • Status (ステイタス)
    • Perfect Circle (正円)
  • Font size (フォントのサイズ)
  • Font weight (フォントの太さ)
  • Highlight (強調)
    • Highlight (強調)
    • Marker (マーカー)
    • Underline (アンダーライン)

3つ目は、ブロックにスタイルを追加。

よく使うブロック5つほどにスタイルを追加しています。応用的な活用方法として、まずスタイルを設定して、次に拡張機能のパディングで余白バランスを整えたり。ブロックの拡張機能を組み合わせてスタイルに柔軟性をもたせることができます。

  • Button block (ボタン)
    • Triangle Icon (三角アイコン)
    • Blur (ぼかし)
    • Shadow (シャドウ)
    • Expansion (膨張)
    • Emboss (エンボス)
  • Heading block (見出し)
    • Underline (アンダーライン)
    • Thick Underline (太めのアンダーライン)
    • Two Color Underline (2色アンダーライン)
    • Up Down Line (上下線)
    • Accent Line (強調線)
    • Kebab Line (横串線)
    • Single Box (囲み線)
    • Double Box (2重囲み線)
    • Left Accent Line (左ラインアクセント)
    • Gradation Line (グラデーション
    • Stripe Line (ストライプ)
    • Cross Box (交わり囲み線)
    • Brackets (カッコ)
    • Japanese quotation marks (日本語の引用符)
  • Image block (画像)
    • Round Corner (角丸)
    • Frame (フレーム)
    • Shadow (シャドウ)
  • Separator block (区切り線)
    • Thick line (太線)
    • Dotted (点線)
    • Shadow (シャドウ)
    • Circle Mark (円マーク)
  • Table block (テーブル)
    • No Style (スタイルなし)
    • Underline (アンダーライン)
    • Dashed (ç ´ç·š)
    • Round Corner (角丸)

プラグイン命名に悩む

今回WordPressプラグイン「Editor Bridge」を公式ディレクトリに登録するにあたり直前にプラグイン名を変更しました。

理由は、プロジェクト名「gutenberg」がプラグイン名に含まれていることについてです。 含まれていると表示名 (後で変えられる) とパーマリンク (後で変えられない) にも含まれるからです。プラグインの登録申請すると、一旦確認のメールが届きます。

そのメール内容には、上記の理由とリスクが書いてあり、正式エディタは、WordPressエディタとクラシックエディタなので、「gutenberg」プロジェクト名は時間が経てば忘れ去られる。コードネーム的な扱いですね。

そのときにそのまま登録を進めていいのか。パーマリンクを変更するなど何か対応する必要があるのか決めて返信するとレビューが開始されます。つまりワンステップ追加した形でプラグインのレビューが進められます。

もともとは「Guten Plus」というプラグイン名でしたが、その前にも「Guten Bridge」と付けていましたので、実は2回めのプラグイン名を変更でした。

「Guten Bridge」のときは、開発している途中に他に同名のプロジェクトが出てきたので、「Guten Plus」に変えたのですが。。。

今後は、とりあえずコードネーム的に名前をつけて開発を進めたほうがいいかもしれないなぁと思いつつ。いつもプラグイン命名に頭を悩まされています。

2転3転して何度も心を折られた開発

今回の開発したWordPressプラグイン「Editor Bridge」はだいぶ難航しました。

プラグインの構想自体は、WordPressバージョン 5.0 リリース直前にちょこちょこブロックの作り方を学びつつ進めてきました。

その中でいちばん実現したかったことは、スペースの設定。ブロックにマージン (margin) とパディング (padding) をいい感じにつけれたらいイイなぁと。レイアウトに変化をもたらすものになればなぁと。

しかしそれは容易なことではありませんでした。特にフロント部分とエディタ部分の整合性を調整するところ。

ブロックエディタは、2018年12月6日にWordPress (v 5.0) の標準エディタとして搭載されてからブロックエディタ自体がまだまだ発展途上で機能追加されるし、改良もされます。そのたびに仕様が変更されてしまいます。

初期の頃のブロックエディタは、とにかくエディタ部分のDOM (Document Object Model) 構造が複雑すぎて。作ってもCSSセレクタが入れ子の連続だったり、設定次第でレイヤーが一つ増えたりしてDOM構造が動的に変わります。ありとあらゆることに対応するには複雑になりすぎて整合性が全く取れませんでした。変更容易性も保守性も確保できなくなるのが目に見えて挫折。。。

アップデートのたびに大幅にDOM構造が変わるところもあり、なかなか安定しません。バージョン5.4 あたりからようやくDOM構造が素直になりつつある感が出てきました。フロント部分とエディタ部分の整合性がとれるような感触を掴んだので。形にしてもいいのではないかと。そしてリリースにこぎつけました。

今後の展望

WordPressプラグイン「Editor Bridge」は特定のテーマに依存する形ではなく、なるべくブロックエディタに対応するいろんなテーマで使えるようにしたいなぁと考えています。

一番の課題は、テーマそれぞれにマージンやパディングの余白のとり方が違うと思うので。またマージンの付け方も上部または下部とあるでしょう。そこをどのように埋められるか。

すでに少し考えていて、今回裏ではCSSカスタムプロパティを仕込んでいていろんなテーマにフィットするように開発者向けの仕組みをつくることを視野に入れていたりします。

ブロックエディタは、まだまだ改良が続くと思います。 WordPressプラグイン「Editor Bridge」もまだまだ改良や調整をしながらいいプラグインにしていきたいと思います。

話はそれてしまいましたが、ブロックエディタでWordPressプラグイン「Editor Bridge」をぜひ活用してみてくださいね。

チャットワークの使い始めはまずこれだけ覚えよう「グループチャットでのお作法」

公開日: 更新日: 投稿者: thingsym

新型コロナウイルス感染症の影響によって働き方が変化しています。新しい生活様式を日常生活に取り入れ、毎日通勤出社する生活から在宅勤務へ移行。特にデスクワークなどどこでもできる仕事に携わっている方は、極力出社を控え、ウェブ会議やチャットを導入して働き方のスタイルがテレワークに急速に変わりつつあります。

マネジメント層の方々のなかには、新型コロナウイルスを契機に、場の共有の大切さやリモートでも対応可能なところなど、いままでの働き方では分からなかった業務メリットを認識した方も多くいるでしょう。仮に収束しても、オフィスを半減したり解約をしたり、業務改革の推進計画を立案したり、働き方が元に戻らず、在宅勤務が定着する兆しもあります。

シングスで行う制作開発や保守管理サービスでも、以前からチャットツールを使ってクライアントと業務を円滑に進めてきたため、業務に影響はほとんどなく進められました。とくに保守管理サービスでは、事業継続計画として機能し障害対応や復旧対応をあらかじめ立案しているため影響を最小限にとどめています。

周りを見渡すと、多くの企業で急遽在宅勤務の環境を整備するところがたくさんありました。PCやネット環境を整えたり、ウェブ会議にチャットに対応したり、慣れないことばかり。

今回チャットツール「チャットワーク」を取り上げて、グループチャットでのお作法としてこれだけ押さえれば、スムーズに参加できてコミュニケーションが取りやすくなるポイントを 3 つ紹介したいと思います。もちろん他のチャットツールでも通用する基本的なことですので応用してみてください。

はじめてグループチャットに参加してみたけどやり取りはどうすれば、いいのか分からないこともあるでしょう。使い続けて慣れてくれば徐々にわかってきますが、はじめの一歩として参考になれば幸いです。

なぜ「チャットワーク」を使うの？

チャットツールは、チャットワーク他、Slack や Microsoft Teams、LINE WORKS などビジネス用途だけでもたくさんあります。その中で「チャットワーク」をメインで使っているいちばんの理由は、フラットな関係性をつくりたいから。

チャットツールを使うだけでも拒否感を持ったり、他ツールと違ってエンジニア優位に見えなさそうなところから。チャットルーム毎の対象は、ブロガーなど個人の方、小規模から中小中堅の企業と多彩なため対応しやすい。グループチャットに参加する方は、直接の担当者はじめ、社長、総務など管理部門の方など様々な関係者が複数の方が入っています。コミュニケーションの取りやすさと双方向的に情報共有ができる環境を作って、チャットツールを初めて使う方やITに疎い方にも使えるように心がけています。

場をオープンに共有する意識の会話に慣れよう

グループチャットでは、通常のダイレクトな 1対1 のチャットや閉じられた中での数人の限られた人との会話と違い、参加者すべての方と一緒にチャットルームの場をオープンに共有する意識を持つことが大切です。

お互い持っている問題意識や課題を共有し、今何が問題なのか現状を多角的に把握しやすくなります。問題解決のアイデアもたくさん出やすい。履歴が残るので、進捗も随時把握できる。引き継ぎ業務も容易になります。次第に先を見越した取り組みを行うことができるようになり、業務遂行も早まります。

グループチャットに初めて参加する方には、テキストでの会話に慣れることが大切です。

まずは「メッセージを入力」欄でメッセージを送信してみましょう。チャットワークには、あらかじめ自分だけのチャットができる「マイチャット」があります。そこでメッセージ投稿の練習をしてもいいでしょう。

メッセージを入力する

また慣れないときは、一行ごとにメッセージを複数回送信してしまう方をたまに見受けられます。「メッセージを入力」欄は複数行の入力をして送信できます。メッセージを受け取る側はメッセージが来るたびに通知音がなったり、バイブレーションが発動するので、複数のメッセージを送るときは、話題で切り分けるなど適切な長さのメッセージを送る配慮を心がけましょう。

誰に向かって会話をしているか分かるようにしよう

グループチャットは、参加者全員で会話すべてを共有する場になります。その場である特定の人や複数人の人だけにメッセージを送りたいときがあります。複数の人が参加するグループチャットでは、会話の流れを見える化する上でも相手を呼びかけ明確にすることは大切です。

よく見られるのは、メールの使い方を引きずっている方です。使い続けていくうちにチャットに慣れてくれば次第になくなりますが、メッセージの冒頭に挨拶文を付けたり、〇〇様と宛先を付けたり。

全員に共有する場合、そのままメッセージを送るといいのです。しかし、そのメッセージが誰に対して発言している場合は、誰かがわからないので、誰に向かって会話しているか分かるようにしたほうがいいでしょう。

チャットツールには誰に呼びかけるか参加者を指名できる機能があります。チャットワークでは「TO機能」です。

「TO」アイコンをタップすると、グループチャットの参加者一覧が表示されます。そこから参加者をタップして選んで (複数人も可) メッセージを送るだけです。

メッセージの相手を指名する:TO機能

メッセージには、誰に向かっての発言かがわかるので、返事ももらいやすく、グループチャットでは会話の流れが把握しやすくする配慮を心がけましょう。

会話が続くように返信をしよう

メッセージには、できる限り返信しましょう。メッセージに対して返信メッセージが送れるので、返事を返して疑問に思うところを遠慮なく聞いてみたり、意思の疎通を図って相互理解を深めましょう。グループチャットは、そのやり取りの回数を重ねることが、自分だけでなく周りの参加者にも共通認識が深まり、信頼感の醸成に繋がります。

メッセージを返信する

また報告や連絡に対していちいち返事を返すのが正直面倒なところもあります。特に定時または定型的なメッセージの場合。その場合は、絵文字でリアクションだけでも返すようにしましょう。円滑なコミュニケーションにとってメッセージに対して何も反応しないよりましになるかと思います。

メッセージにリアクションする

以上を心がけるだけでも参加者全員で会話の流れが把握しやすく、コミュニケーションの取りやすさと情報共有に役立つグループチャットの場になるかと思います。是非参考にしてみてください。

WordPressプラグイン「WP Auto Updater」に通知機能が付きました

公開日: 更新日: 投稿者: thingsym

WordPressの本体 (コア)、テーマ、プラグイン、翻訳を自動更新するプラグイン「WP Auto Updater」には、今まで更新したテーマやプラグインなどのアップデート履歴を記録し、管理画面上で確認できますが、今回バージョン 1.4.0 へアップデートに伴い、新たに更新完了時にメールで更新内容を通知する機能を実装しました。

通知を有効にしていると、こんな感じのメールが届きます。

タイトル:
[シングス] プラグインは自動的に更新されました

本文:

次のプラグインは正常に更新されました:
WP Auto Updater v1.4.0 (upgraded from v1.3.0)


アップデート履歴を見る
https://http://example.com/wp-admin/index.php?page=wp-auto-updater-history

通知メールは、本体・テーマ・プラグイン・翻訳毎に受け取りたい通知を有効/無効ができます。
またメールの宛先、送信先も管理者権限グループを持っているユーザーを受取人に選択できます。
管理画面からいろいろ設定できますので、運用に合わせて活用できます。

管理画面はこんな感じ。

WordPressプラグイン「WP Auto Updater」の管理画面

是非試してみてください。

最近の投稿

カテゴリー

アーカイブ

検索

Copyright © 2002 - 2025 シングス All rights reserved.