WordPressは4.4からREST APIを導入しており、「WordPressのデータを外部から操作する」ということが本質的には可能になっているが、認証方法がCookieしかデフォルトで提供されていなかった。ところがフィーチャープラグインとして開発されていたApplication Passwordが5.6からコアにマージされるため、あらたな認証方法が追加されることとなった。 Cookie認証以外のREST APIは何があるのか？ まず、WordPressのREST APIが現在サポートしている認証方法であるCookieについて説明しておこう。 そもそもWordPressはCookieをログインに利用している。ブラウザからアクセスする場合はこのCookieを読み取ることで「ログイン済みのユーザーかどうか」を判定している。REST APIではリクエストにnonce（24時間に限り有効な認証

makeブログにE2Eテスト導入のプロポーザルが発表された。これまでWordPressコアはJestによるテストのサンプルコードしか持たなかったが、本格的なE2Eテストの導入に向けて動き出すようだ。採用されるのはGutenbergプロジェクトで生まれたJest+Puppeteerベースの@wordpress/e2e-test-utilsだと思われる。 E2E（エンド・トゥー・エンド）テストとは？ コードのテストには色々あるが、WordPressではPHPUnitによる自動テストが導入されてきた。テストは結構な量に及び、Ajaxでの動作を確認するための結合テストもPHPUnitを拡張する形で大量に書かれている。 このユニットテスト（および結合テスト）は低レベルでのコードの信頼性を高めるのには役立つが、昨今のJSフレームワークゴリゴリの管理画面で発生する問題には対処しづらい。そこで、E2Eテス

二ヶ月ほど前に WordPressによる公式Dockerコンテナである wp-env がリリースされたが、現在は日本語ドキュメントの整備も進み、かなり成熟してきたようだ。 wp-envの特徴 さて、wp-envはDockerのnpmラッパーといった趣で、次のような .wp-env.json をリポジトリに用意しておくことで、開発環境がまるっと用意できる。 { "core": null, "plugins": [ "." ] } Dockerを利用したWordPress開発環境はいくつかあるが、利点は下記の通り。 公式でサポートされている。たとえば Docker がリリースしているWordPressイメージなどはファイルパーミッションなどがやや微妙だった。DockerとNode（v12以上）がインストールされていれば、環境を再現できる。追加ソフトウェアのインストールは不要（というより、npm

WordPress関連の市場としてもっとも大きいのがホスティング市場であることは何度かお伝えしているが、その中でもトッププレイヤーであるWP Engineが大型の買収を行なった。対象となった企業はこれまた同じくWordPressマネージドホスティング企業であるFlywheel。日本ではCapital Pでも紹介したローカル開発環境管理ツールLocal by Flywheelの開発元として有名だろうが、元々はホスティング企業である。 今回の買収額は「WordPress産業における最大の買収」という点以外は不明だが、おそらく以前お伝えした2億5,000万ドルの資金調達も大きく絡んでいる。今後も買収による事業拡大は続いていくだろう。 WP Engineは自らのサービスを単なるホスティング業者ではなく、デジタル・エクスペリエンス・プラットフォームと位置付けている。Capital Pがこれまで報じて

Googleによる新しいプラグイン、サイトキットの画面 サーチコンソール、アナリティクス、アドセンス、ページスピードインサイトを一括で表示する Googleは昨年末に開催されたWordCamp US 2018で発表していた、Site Kitの開発者版ベータを公開した。今すぐダウンロードして試すことができるが、本番環境ではまだ利用しないほうが無難だ。 Site Kitは、Googleによる公式プロジェクト。WordPressの管理画面内でGoogleが提供している各種ツールの情報を一括してみることができる。ベータ版では、サーチコンソール、アナリティクス、アドセンス、ページスピードインサイトの情報が表示され、ひとつひとつにログインしなくても、あるいは、各種サービスにアカウントがないユーザーであっても、Sitekitを通じて諸々の情報を確認することができる。 かなり強力そう また、以下の機能も含

WordPressのmakeブログでは定期的にWordPressのシェアを報告しているが、ついに33.3%を超え、世界のトップ10,000,000サイトの3分の1がWordPressを利用しているという状況になったようだ。 Web制作業界で仕事をしていると、「WordPressはオワコン！」というまとめブログのような感想を見ることもあるだろうが、国内でも国外でもシェアは微増を続けているのがここ2年ほどのトレンドだ。このCapital Pでもたまにシェアを報告しているが、今年で3年目のCapital Pでも4%ぐらいの変遷を見ている。50年後には100%を超えているのではないだろうか。 冗談はさておき、Webの1/3というのはなかなかなインパクトだ。Googleのような企業がパートナーシップを結ぼうとするのもわからないでもない。これからしばらくGoogleのようなビッグネームによる参入が相次

本日、WordPressの共同創業者であるMatt Mullenwegが発表した内容によると、WordPressプロジェクトに新たに2人のリードが誕生した。これは以前から存在していた職種——という表現が適切かはわからないが——ではなく、新設のものである。 1人はJosepha Hadenで、エグゼクティブ・ディレクターを務める。これはすべてのコントリビューターチーム（コア、メタ、ポリグロッツなど）のメンターのような立場になるらしい。1つ1つのチームがコンビニの店舗だとすると、エリアマネージャーのような存在だろうか。筆者はWordCamp Europeでこの人に会ったことがあるような気がするのだが、もしその記憶が確かなら、アジア地域の事情に詳しかった気がする。ちなみにa8n（Automattician = Automatticの社員）である。 もう1人、Joost de Valkはマーケティ

WordCamp US 2018を終えたばかりのMatt Mallenwegがmakeブログに発表したところによると、2019年は以下の9つを主要なプロジェクトとするらしい。 ナビゲーションメニューにブロックを適用する。 すべてのウィジェットをブロックにする。 「外観 > ウィジェット」のページとカスタマイザーがブロックに対応するように。 テーマにコンテンツを追加できるエリアを用意し、そこがGutenbergで表示されるように。 サイトヘルスチェック機能をマージする。現在はプラグイン。 テーマ・プラグインの自動アップデートをオプトインで提供する。 コアのメジャーリリース自動アップデートをオプトイで行えるようにする。 ブロックディレクトリをWordPress.orgに用意する。プラグインリポジトリとは別？ 6500個の未消化チケットを片付ける。 これらをまとめると、次のように解釈できるのでは

予告通り、WordPress 5.0（コードネーム Bebo）が12/6リリースされた。日本時間では12/7の深夜3時半頃だったろうか。今回のバージョンは次の対応が行われている。 新エディターGutenbergの採用。名前はBlock Editorに変わっている。 PHP 7.3以降の対応。 筆者も何度かパッチを送ったが、ほとんどがパント（先送り）されたので、今回はGutenbergがもっとも大きな変更点になるだろう。 ポイント 以下、ポイントを箇条書きにする。 5.0.1が1〜2週間以内に出ることが確定している。不安な方はそちらを待っても良いだろう。 Gutenbergへの対応がまだの方は、Classic Editorを有効化しておこう。 エディタ以外にほとんど変更点がないため、それ以外はあまり意識する必要はない。 今回のバージョンから日本語版も自動リリースされるようになった。これまでは

先日RC1がリリースされ、いよいよWordPress 5.0のリリースが近づいてきた。といっても、まだリリース日が確定していないのだが……。今回はプラグインやテーマ作者にとって気になる、互換性の保ちかたについてちょっとしたティップスを紹介しよう。 筆者はいくつかのプラグインをリリースしているのだが、そのうちの一つにHamazonというものがある。これはAmazon, DMM, PHG(itunes)のアフィリエイトコードを差し込むものだ。実装はショートコードだが、Shorcakeに対応しているので、ビジュアルエディタでも使うことができる。 ビジュアルエディターにも対応している。Shorcakeを入れていない場合はただのショートコードを挿入。 さて、これをGutenbergに対応させたいのだが、Gutenbergでショートコードをビジュアルとして表示する手段は提供されていないので、ブロックを

10月6日、Matt Mallenwegはmakeブログに”Gutenberg Phase 2 Leads“と題する短い記事を投稿した。それによると、GutenbergはPhase1でエディターを中心とする編集体験(editing experience)を提供することに注力していた。Phase2では、事前に発表されていた通り、そのブロックの概念をサイト全体（ウィジェット、カスタマイザーなどのすべて）に適応していくフェイズである。 問題は新しいリードとして発表された2人がWordPressコミュニティにとってあまり馴染みがない人だったことである。 まず1人目はAlexis Lloydで、彼女のWebサイトによれば、現在はAutomatticに勤務しており、以前はNew York TimesやAxiosなどのメディア企業でデザイン／UXのリーダーを勤めていたようだ。Automatticにジョイ

Makeに投稿された5.0のリリースリードMatt Mallenwegによる記事 “A Plan for 5.0“で次のことが大々的に発表された。 チーム体制の刷新 これまではリリースリード+サポート数人が中心となってリリースチームを形成していたが、大規模なチームとなったようだ。目新しいものとしては、TriageとDesignチームがあること。これはAutomatticにジョインしたジョン・マエダによる指導が大きいのではないだろうか。今年のWordCamp Tokyo 2018でもトリアージを行なっていた。 ちなみに、トリアージとはフランス発祥の医学用語で、災害時などに医療を施すべき優先順位づけをする識別医療行為を指す。黒だったら助かる見込みなし、赤なら急いで治療、緑は待機といった具合だ。 リリース日の予告 ブログ記事の末尾でさらっと触れられていたのだが、約一ヶ月でリリース候補となるようだ

WordPressプラグインやテーマは国際化対応を行うことができる。potファイルやpoファイルを含める方法を利用している開発者も多いだろう。しかしながら、実はWordPressで翻訳対象となるのはプラグインまたはテーマに同梱されるファイルだけではなく、WordPress.orgの公式リポジトリ上に表示されるreadme.txtもまた翻訳対象になるのだ。 readmeを翻訳するためには、WordPressの翻訳プラットフォームGlotPressから行う。GlotPressがどのようなものか知らない方は、翻訳の始め方を読むといいだろう。 プラグインページの「開発」からGlotPressの翻訳ページへ移動できる。 Development Readmeをクリックすると翻訳開始 され、これで翻訳を行うことはできるのだが、有名プラグイン・テーマでない限り、この翻訳はなかなか承認されない。筆者はプラグ

WordPressには、WordPress本体、プラグイン、テーマ、翻訳ファイルをブラウザからアップデートする仕組みがあります。 今回はアップデートに関する一般的な話題に付け加えて、みなさんがたぶんお気づきではないであろう細かいことについても解説してみたいと思います。 とにかくすべてが最新である必要がある WordPressを安全に使用する場合、コアだけではなくプラグインやテーマも含めて最新版である必要があります。（必然的に翻訳ファイルも最新である必要がある。） たとえばよく聞くのはWordPressのメジャーアップデートはスキップして、マイナーアップデートが出てからアップデートするという話を聞きますが、これは後述する理由によりプラグインやテーマの脆弱性がアップデートされずに残り続けるというリスクがあります。 自分が使ってるすべてのプラグインの脆弱性とかアップデート情報を完璧にトラッキング

さて、すでにGDPRが施行されたわけだが、「なにをしたらいいかさっぱりわからん」という方も多いのではないだろうか。 通常のWordPress利用だとユーザー情報を保存するケースは少なく、デフォルトではコメントフォームぐらいだ。こちらはプラグインなどで対応されているはずなので、特に問題ないだろう……と思いきや、Capital Pで利用しているJetpackコメントには同意ボタンがないようだ。Akismetの注意書き（外部サービスがどのようにデータを利用するか）が日本語訳されないまま表示されている。 同意のチェックボックスとかなくていいのか…… まあ、ここら辺はおいおい改善されていくだろう。 それよりも今回取り上げたいのは、海外のWordPressブログでも雨後の筍のごとくチュートリアル記事が湧いている「フォームのGDPR対応」である。 フォームに必要な同意チェックボックス どんなWebサイト

2017年にぶちあげられたGutenberg構想により、「WordPress5.0はGutenbergが完成するまで出ない」ということが明言された。2018年の5月にはリリースされる予定だったような気もするが、すでに延長している。 ところで、WordPressはバージョンポリシーを次のように定義していることをご存知だろうか。 4.9がメジャーバージョンとなる 3.9と4.0の違いは、4.0と4.1の違いと変わりない。これは現在のオープンソースソフトウェア開発で標準になりつつあるsemverと異なる。 semverではメジャー、マイナー、パッチとわかれる 上記2つの違いをざっくり説明すると以下の通り。 WordPressはメジャー、マイナーのみ。semverはメジャー、マイナー、パッチの3種類。 semverにおけるメジャーリリースは後方互換制のない変更だが、WordPressでは後方互換制

すごい小ネタですが。笑 WordPressのプラグインで画像をリサイズするには以下のような感じ。 $editor = wp_get_image_editor( dirname( __FILE__ ) . '/test.jpg' ); $editor->set_quality( 60 ); $editor->resize( 1000, 1000 ); $editor->save( 'saved-60.jpg' ); wp_get_image_editor() という関数を使用すると WP_Image_Editor というクラスのインスタンスが帰ってくるのでそのメソッドを使用してゴニョゴニョする感じ。 なんてこともないのですが、またやる機会があったときのためにということで。 こういう小ネタをちょちょっと試すときのTips たとえば特定の WordPress の関数でも PHP の関数でもなんで

たとえば特定のクライアント向けにWordPressのプラグインを開発したあとで、たまたま同じ名前のプラグインが公式ディレクトリに登録されると、そっちのほうがバージョン番号が新しいときにうっかりアップデートしてしまうことがありえます。 （実際に10分前にやらかした。笑） 同じ名前というのは、そのプラグインのディレクトリ名が同じという意味で、このユニークな名前のことをスラッグと呼びます。 わかりやすくするつもりで一般的な名前を使うとすでに公式ディレクトリに同じ名前のものがあったり、今はなくても忘れた頃に他の誰かが登録してうっかりアップデートしてしまって慌てるわけですね。 そんなトラブルを防ぐために、特定の顧客向けを想定したプラグインには以下のコードを入れておくと安心です。 add_filter( 'site_transient_update_plugins', function( $value

WordPress5.0から採用されるGutenbergだが、決定的に新しい概念として、「ブロック」というものがある。ブロックの正体は <!--wp:xxx--><!--/wp:xxx--> というHTMLコメントで囲まれた独自タグのようなものだが、これは独自に追加することができる。ショートコードのようなものだと思ってもらっていい。 このコメント、筆者はあまり好きではない。純粋なHTMLを保存したかった。 これにかなり近い機能として、現時点でも使えるプラグインに Shortcake というものがあり、筆者も便利に使っていたのだが、こちらはBackbone製でおいそれとカスタマイズできるものではないので、公式採用にいたらなかったのだろう。 なにはともあれ、Gutenbergをカスタマイズして使いこなすにあたって避けられられないのがブロックである。今回はReactがなんなのかをよくわからないま

WordPressを作る仕事をしていると、ゼロから作るばかりではなく、いわゆるリプレース、つまり既存のサイトを受け持つケースが多々ある。まったく別のCMSや静的サイトをWordPressにする場合もあれば、すでに稼働しているWordPressサイトをあらたに受け持つケースも多い。 後者の場合、かなりの頻度で遭遇するのが、WordPress-Wayではないやり方である。プログラマではあるが、WordPressははじめて触った人などが作る処理がそのまま残されているというわけだ。今回はそんなケースとしてよくあるバッチ処理の作り方について説明しよう。 そもそもバッチ処理とは？ Wikipediaによると、次のような説明がなされている。 バッチ処理（バッチしょり）とは、コンピュータで1つの流れのプログラム群（ジョブ）を順次に実行すること。あらかじめ定めた処理を一度に行うことを示すコンピュータ用語。反