はてなブックマーク

2024年10月12日付けで発表されたWordPress公式ニュースによると、Advanced Custom FieldsがSecure Custom Fieldsに変更となった。所有者がWordPress.orgとなっているが、これは単純なフォークではなく、スラッグがそのままなので、既存のACFユーザーがWordPress管理画面からアップデートした場合、今後はこのSCFが使われることになる。 こうしたハイジャックと呼んでもよい手法について、WordPress公式ニュース（書いたのはマット・マレンウェグだが）は以下のように説明している。 WordPress セキュリティチームを代表して、プラグインディレクトリのガイドライン第18項を適用し、「Advanced Custom Fields (ACF)」をフォークして新しいプラグイン「Secure Custom Fields (SCF)」を公

WordPress共同創業者のマット・マレンウェグは10月3日づけで “Automattic Alignment” と題したブログ記事を公開、それによると159名がAutomatticを退職したようだ。これは現在WP Engineとの争いが発端で、マットの方針に同意しなかった職員が辞職したようである。この人数はAutomatticの全従業員の8.4%にあたる。 そして、日本人WordPressユーザーとしてややショッキングなのは、長年にわたって日本のWordPressコミュニティの発展に寄与してきた高野直子氏もその1名に含まれていたということである！ 辞める理由ですが、簡潔に言うとすれば「最近の WP Engineとの対立の中でマット (Automattic CEO・WordPressプロジェクトリード) が下した戦略的決定に賛同できないため」です。 Naoko Takano 「Autom

2024年9月17日から20日にかけてオレゴン州ポートランドで WordCamp US 2024 が開催された。毎年おなじみの質問コーナーではWordPress共同創業者であるマット・マレンウェグが大手ホスティング会社であるWP Engineについて突如批判を開始した。 批判の趣旨としては概ね次のとおり。 WPEngineはWordPressにあまり貢献していない。 WordPressを「ハックして」金儲けしている。 マットはイベント開催中もブログ記事 “WP Engine is not WordPress” を投稿（しかもWordPress.orgドメインで！）したり、Xで「次のWordCampにWPEngineを呼ぶべきか？」とアンケートをとっている。 Just wanted to do a community vibes check: If you saw my #wcus pres

WordPress.comを運営するAutomatticから新たなWordPress用ローカル開発環境としてStudioが発表された。現在、Mac版しか存在せず、Windows版は準備中のようだ。 どこか（wordpress.org）で見たような左ペインのデザイン……同じ人がデザインしてる？ ダッシュボード。ボタンを押すとブラウザが立ち上がる。 WordPress Playgroundをベースにしているので、サイトが爆速で立ち上がる。サイトを開いてみると、管理バーの右に「SQLite」と書いてあるので、やはりPlaygroundで動いていることがわかる。 管理バーにはSQLite このサイトでもすでに取り上げたLocal by Flywheelがスタンダードとなりつつある気配だったが、ここに来て新たなツールが加わった。Localと比較すると…… たしかにStudioは早いが、別にLocal

ここ数週間、WordPressチームやWordPress Securityチームを語るフィッシングメールが流行していると注意喚起されている。このメールには「WordPressに脆弱性が見つかったので、いますぐセキュリティパッチプラグインをインストール！」という内容が記載されている。慌てた受信者がメールの支持通りにダウンロードリンクへ移動すると、そこにはWordPressプラグインディレクトリにそっくりなサイトが用意されていて、バックドアをしかけるプラグインが待ち構えているというわけだ。 詳細はpatchstackの記事 “Fake CVE Phishing Campaign Tricks WordPress Users Into Installing Malware” に詳しいので画像を参照してほしいのだが、かなりよくできている。また、ご丁寧にプラグインのレビューや開発者メンバー（Word

2023年7月18日に企業によるWordPressコントリビュート成功事例: スキルアップとグローバル参加の機会が開催された。主催はAutomatticの高野直子氏。参加者は日本のコントリビューターのほか、同じくAutomatticからAngela JinとHari Shankerらが参加。両名の仕事は色々あるが、その一部に”Contributor Experience”を高める、というものがある。つまり、WordPressの開発で主導的な地位を占めるAutomatticでは、コントリビューターを増やすための仕事が存在しており、このイベントもその一環だということだろう。 Five for the Futureとは？ さて、イベントの本題に入るために、Five for the Future（5ftFと略される）について説明しておこう。「未来のために5%の時間だけWordPressに貢献しよう

2016年から始まったGutenberg計画もいよいよフェイズ3に到達した。ブロックエディターやフルサイト編集などの機能が予定通り実装され、残る大きな課題はリアルタイムコラボレーション（Googleドキュメントのような同時編集）、非同期コラボレーションと公開フロー（Edit Flowのような承認機能）、リビジョン機能の改善など、コンテンツ管理にまつわる機能改善が多く予定されている。なかでも最も大きな変化は管理画面のリニューアルだ。 WordPressの管理画面は、見栄え上の細かな改善はあっても、基本的にレガシーなスタイルなままだということは、多くのユーザーが同意することだろう。特に、新しい機能（例・リアルタイムコラボレーション）をとってみても、エディターや投稿一覧で「いまこの投稿を編集しているユーザー」が表示されている必要がある。それこそ、Googleドキュメントやスプレッドシートのように

PHPにはcomposerという高度なパッケージ管理ツールが存在しており、WordPressでもcomposerを利用した開発がさかんに行われている。しかし、ついにコンフリクトが発生するようになったため、その解決方法と知見を共有したい。本記事の対象読者は以下の通り。 プラグインを作成している。 テーマを開発しているがプラグインで問題が起きた。Uncaught Error: Call to undefined method GuzzleHttp\Utils::chooseHandler() と言われた。 開発者ではないユーザーにとっては、「そういうプラグインを使わない」という解決策しかないので、ご了承いただきたい。では、本題に入ろう。 なぜコンフリクトが発生するか composerは基本的に「プロジェクト単位で1つ」という暗黙の前提が存在するツールである。たとえばPHPのフレームワークLar

WordPressがSQLiteをサポートし、その後PHP WASM（PHPのWebAssembly実装）を利用したWordPress Playgroundが誕生、ブラウザでWordPressが動作するようになった。ではこれを何に使ったらよいのかと不思議に思っていた方も多いだろうが、さっそくその実例であるwp-now が誕生した。WordPress Playgroundリポジトリの中にあるので、派生プロジェクトの一つだろう。例によってnodeプログラムである。 コントリビューターであるAutomatticのブログによると、wp-nowはブロックテーマの開発に最適化されているようで、テーマディレクトリ内で実行するとWordPressが実行できる。 実行するためのコードは以下の通り。なお、nodeは18系で行った。 # wp-nowをインストール npm i -g @wp-now/wp-now

イーロン・マスクの買収劇以降、twitterの度重なる仕様変更がテックニュースを賑わせる情景が続いてきたが、利用者の多いJetpackのtwitter共有がついに削除されることとなった。運営元のJetpackはtwitter（X社？）と協議を重ねてきたが、月次の利用料がユーザーにとても転嫁できないほど高額だということになり、twitter共有を廃止する決断に至ったようだ。この経緯はAutomatticのブログ “Why Twitter Auto-Sharing Is Coming to an End” に綴られている。 twitterは最近APIの利用規約を大幅に変更し、その価格体系が「あまりに高額だ」として話題になった。もっとも高額なプランは月間21万ドル、つまり年間で日本円にして3億5千万近い費用になる。Jetpackもおそらくこのレンジで、水面下で交渉を続けたものの、決裂となったよう

公開から一週間で100万ユーザーを突破したChatGPT は対話型でAIチャットツールだ。その会話の精度の高さからシンギュラリティ——技術的特異点——の到来も予感させるほどだ。つい先日、Stack OverflowがChatGPTで生成した解答を禁止したこともニュースになった。「ChatGPTにプログラミングに関する質問をして解答をもらった」というSNS上の投稿を見かけた方も多いだろう。 さて、そんな実験の最中、ChatGPTを「調教」して実際に動くプラグインを生成した”Ｐ”が現れたとWP TAVERNが報じている。 Open AI's ChatGPT can generate an entire WordPress plugin based on a simple description. Watch it work: pic.twitter.com/LZQbxFq0aP — Johna

2022年6月30日に公正取引員会が発表した資料「株式会社サイネックス及び株式会社スマートバリューから申請があった確約計画の認定等について」によると、二社は市町村のCMS導入に際し「オープンソースはセキュリティ的に危険であるから、オープンソースではないCMSを導入すること」を必須要件として仕様に盛り込むよう働きかけたとして、公正取引員会は確約手続きに付したとのことだ。該当する違反行為は独占禁止法第１９条（不公正な取引方法第１４項（競争者に対する取引妨害））とのこと。 確約手続きとは、「独占禁止法に軽微な違反が認められたので速やかに修正することでお目こぼしをする」という司法取引であり、厳重注意的な行政処分にあたる。スマートバリュー社はSMART L-Govなどの自社CMSを持っているようなので、その売り込みで「オープンソースはセキュリティ的に危険」という営業行為を行っていたのだろうか。これに

SNSプラットフォームtwitterがいわゆるブログのような長文記事を作成可能にする機能Notesを準備中だとTech Crunchが報じている。この機能は現在一部のユーザー（アプリリサーチャーなど）に提供されており、当初はTwitter Articlesという名前だったが、Notesに名称変更されたようだ。一般公開の時期は明言されていないが、”Soon” （まもなく）と目されているようだ。 The Twitter Article Composer now comes with a “Focus Mode” (that button on the top-right) that expands the composer to the full screen, hides away the side bars pic.twitter.com/oOhyM1IIWs — jane (@wongm

人気SEOプラグインYoastの創業者であるJoost de Valkが自身のブログ記事 “WordPress’ market share is shrinking” で「2022年4月からWordPressのシェアが減少を始めた」と報告している。2022年2月までは順調に伸び続け、43.3%のシェアを取るにいたったWordPressのシェアは同年4月より減少を始めた。 WordPressが減少したということは、他のものが伸びているということであり、それがなにかというとWixとSquarespaceである。このシェア減少の原因をJoostは以下のように分析している。 SEOとサイトパフォーマンスのスコアが悪い。WixとSquarespaceは改善点を全ユーザーに適用できるが、WordPressはサイト所有者が個別にがんばらないといけないため、全体として見ると大きな差が開く。フルサイト編集な

1月25日にWordPress 5.9がリリースされた。フルサイト編集（FSE）が搭載された新バージョンはFSE対応の「ブロックテーマ」Twenty Twenty-Twoを同梱しており、まったく新しい編集体験を提供している。対応テーマも開発のための情報もまだまだ少ないが、今後はホスティング事業者やサービス事業者を中心にフルサイト編集に力を入れるプレイヤーが増えてくることだろう。 フルサイト編集という、Gutenberg プロジェクトの悲願であるPhase 2がリリースされたわけだが、今年は6.0（5月終わり）と6.1（10月半）のリリースが予定されている。これらのロードマップはどうなっているだろう。 先日投稿されたmakeブログの”Preliminary Roadmap for 6.0 (Gutenberg Phase 2)“によると、ブロック、エディター、パターン、レイアウト、デザインに

makeブログにおいて、WordPress開発へのTypeScript導入の提案が提出されており、なにもなければWordPress本体で新しく追加されるJavaScriptコードはTypeScriptが使われることになりそうだ。 実はGutenbergプロジェクトですでにTypeScriptは導入されているので、それがWordPress本体にも導入される形になる。ここ最近のWordPressコア開発のトレンド通りだ。 TypeScriptの長所の一つとして厳密な型指定とそれに伴うドキュメンテーションの改善である。WordPressプロジェクトではドキュメントの自動生成が行われており、GitHub上のREADMEファイルからリファレンスを作ったり、関数リファレンスもコードの静的解析からドキュメンテーションされている。TypeScriptを導入することでドキュメンテーションおよびコード補完に改

Core Web Vitalに関する連載の最終回ではこれまで紹介してきた内容をチェックリスト形式で紹介しよう。 基礎知識 LCP, FID, CLSなどの指標を理解する。 リソースの配信 画像の次世代配信（webp）ブラウザキャッシュ、GZip圧縮の適用CDNを利用する サーバーの処理速度向上 ページキャッシュの利用キャッシュを利用できない場合のTTFB改善 リソースの読み込み CSSの遅延読み込み（rel=preload）JavasScriptの遅延読み込み（defer/async）srcsetおよびpictureによる画像のサイズ最適化サードパーティーリソースの削除および改善loading=lazyによる画像・iframeの遅延読み込みリソースヒント（preload / preconnect / prefetch / dns-prefetch） 最後に宣伝なのだが、連載で紹介した内容の

フルサイト編集機能が搭載された初のバージョンであるWordPress 5.8がリリースされてからそろそろ一週間になる。変更点の多いこのテーマだが、中でもとりわけインパクトの大きい変更がブロックウィジェットだろう。フルサイト編集はテーマ側で対応していなければ使われることはないが、ウィジェットは否応なしにブロックウィジェットに変わってしまうからである。 WP TAVERNでも「すべてのテーマでは動かない」と言われているが、iframeでウィジェットをレンダリングしているので、それに付随している問題が多く出てしまう。以下、筆者のブログで5.8にしてみた場合のウィジェット画面だ。 筆者の個人ブログで5.8のウィジェットを表示した様子。 パッとみた感じで以下のような問題点が散見される。 Contact Form 7の出力するreCAPTCHAが全部のウィジェットで出ている。ページ下部に出力するティッ

Core Web Vitalの連載第8回では、JSおよびCSSの最適化について説明しよう。配信の最適化（Gzip圧縮、CDN、ブラウザキャッシュ）についてはすでに第1回「リソース配信の最適化」で説明したのでそちらを参照して欲しい。今回最適化するのは次の項目である。 不要な読み込みをなくす（特にプラグイン）CSS・JS自体を分割し、必要な時だけ読み込む。 この作業はかなり面倒くさく、サイトごとにチューニングが必要になる作業なので、運用歴の長い既存サイトで導入するのはかなり骨が折れるだろう。だが、最終的にはこの作業をやらないと「使用していないCSS / JavaScriptの削減」という項目をなくすことができない。 なにより、ユーザーに余計なデータをダウンロードさせないことは、ユーザー体験の向上につながるだろう。 不要なJS/CSSの読み込みを停止 まずは不要なCSSとJSの読み込みを停止する

Core Web Vital の連載6回目では、画像周りの処理を上げる。これはテーマに関わることであり、多くの場合テーマ本体の修正を必要とするだろう。今後テーマを新たに開発するケースがある場合は参考にして欲しい。LCPおよびCLSに関わる改善点だ。 Page Speed Insightsでの指摘 基本的には次の対処を行う必要がある。 widthとheightの指定ファーストビューに入らない画像の遅延読み込みpicureタグまたはsrcsetによる最適化された画像の出力 それでは、一つ一つ紹介していこう。 widthとheightの指定 画像にはwidthおよびheightを指定する必要がある。なぜかというと、その指定があれば、ブラウザは実際の画像を読み込む前にその画像のサイズがわかるからである。CSSで画像の表示サイズを変更するとしても、画像のサイズは必ず記載するようにしよう。Core W

Core Web Vitalに関する連載の第5回はCSSとJSの遅延読み込みについて説明する。この2点は主に「レンダリングを妨げるリソースの除外」という項目でPage Speed Insightsに表示される。 WordPressプラグインのおすすめまでしてくれる。 プラグインで対応する方法もあるのでプラグインを導入して済めばそれでよし。本稿では原理の説明とコードによる解決を紹介する。テーマ本体に手を入れなくてもよいソリューションなので、ぜひ取り組んでほしい。筆者の開発したテーマSide Businessでもほぼ似たようなことをやっている。 CSSの遅延読み込み CSSは通常headタグ内に挿入される。ブラウザは <link> タグを見つけるたびにCSSをダウンロードし、その内容を解析してスタイルコンテキストツリーを構築する。この間はHTMLのパース（DOMモデル構築）やJavaScrip

オブジェクトキャッシュのデータストアと対応環境 まず、ファイルシステムへの保存だが、これはあまりお勧めしない。うっかりキャッシュデータを公開可能な領域においてしまうと、情報漏洩が懸念されるからだ。共有レンタルサーバーだとPHP拡張のAPCuぐらいしか選択肢がない（e.g. さくらのレンタルサーバー）ので、その場合は WP LCache を使おう。ただし、あまり熱心にはメンテされていない様子だが……。 VPSあるいはクラウドホスティングの場合は、MemcachedあるいはRedisを利用できる。AWSならElasticacheのようなサービスを使うとサーバーのお守りが楽だ。また、キャッシュサーバーを用意することにより、複数台構成のWordPressでもデータの一貫性が保たれる——というより、複数台構成の場合は必ずキャッシュサーバーを用意しなければならない。 複数台構成の場合、キャッシュサーバ

GoogleはCore Web Vitalと呼ばれる指標を2021年6月中旬から検索エンジンのランキング評価項目として採用することを発表している。この記事を書いている時点で段階的に採用が始まっているはずだ。コンテンツの中身だけではなく、速度もまたユーザーにとって重要な指標だというわけだ。 これにともない、現在WordPress高速化の需要は増えていることだろう。もっと単純化すると、顧客から「Page Speed Insightsで高得点を出せるようにして欲しい」という要望を受けるWordPressコンサルタントも増えているはずだ。本連載ではこうした人たちに向けてWordPressにおけるCore Web Vital対応の基本から応用までを紹介する予定だ。 なお、本連載で紹介する内容は筆者が開発したプレミアムテーマ Side Business をベースにしている。さくらインターネットのレンタ

Capital Pでも何度か取り上げてきたWixだが、このたびWordPressへのネガティブキャンペーン”You Deserve Better“を展開しているようだ。要するに「WordPressよりWixの方がいいよ！」というメッセージを広めるためのもので、たとえば以下に紹介する動画では「WordPress（例によっておじさん）がアップデートを進めるのだが本人はバグっている」という内容だ。筆者は昔のMacのCMを思い出した。 YouTubeで”You Deserve Better”と検索すると出てくる。 これにあわせ、WordPressコミュニティのインフルエンサー、有名開発者などにBoseのノイズキャンセリングヘッドフォンを送りつけたらしい。メッセージにはシークレットビデオのURLが貼られていたようだ。なお、筆者のもとにBoseヘッドフォンは届いていない。 このページのURLがヘッドフ

WordPressの環境構築用パッケージとして以前紹介したwp-envだが、かなり進化が進んでいるので、便利な利用法を紹介する。 wp-envのドキュメント Gutenbergリポジトリ内 @wordpress/env で開発がガシガシ進められているが、日本語チームの努力もあり、日本語ドキュメントもかなり整備されてきた。リリース直後から取り入れられた点は次の通り。 xdebugの採用。起動時に wp-env start --xdebug と指定することでxdebugが有効になる。IDEの連携を利用すればステップデバッグ（ソースコードで処理を止めながらデバッグすること）も可能だ。更新。.wp-env.jsonで定数を一時的に変更するなどした場合は wp-env start --update とすることで更新が反映される。PHPバージョンの指定。5.6と7系のチェックなど、前よりも簡単に行える