blog

Optrion

Introducing Optrion — See Who Reads Your wp_options, Then Clean Up Safely

Every WordPress plugin and theme you’ve ever installed has probably left rows in your wp_options table. Deactivating or deleting the plugin doesn’t
remove them — they just sit there, and many ride along with autoload = yes, quietly inflating every single page load. WordPress gives you no
built-in way to tell which rows are still being used, which plugin or theme created them, or whether any given row is safe to delete.

Optrion is a free, GPL-licensed WordPress plugin that fixes exactly that problem.

Observe, judge, quarantine, delete

Optrion is built around a four-stage workflow designed so you never have to guess:

  1. Observe — Optrion dynamically registers an option_{$name} filter for every row in wp_options. Every time get_option() fires, it walks
    the live PHP backtrace, identifies the calling plugin or theme, and records a last_read_at timestamp. No guesswork, no prefix-only heuristics — the
    real caller on the stack.
  2. Judge — The admin dashboard surfaces the raw signals as individual sortable columns: accessor (with an inactive badge when the owning
    plugin/theme is gone), autoload flag, size, and last-read timestamp. You make the call; Optrion doesn’t hide it behind an opaque score.
  3. Quarantine — Not sure yet? Optrion renames the row (wpseo_titles_optrion_q__wpseo_titles) and installs a pre_option_{name} filter
    that transparently returns the stored value. Your site keeps working exactly as before. Any access during the window is logged; if the option is
    being used, the UI flags it “in use — restore” and auto-expiry is paused.
  4. Delete — Only after the quarantine window passes with no access does the permanent Delete button unlock.

Performance, carefully

Tracking only activates for 10 minutes after an admin visits the dashboard — not on front-end traffic, not always-on. Reads are buffered in memory
and flushed as a single upsert at shutdown. The admin UI displays a persistent reminder to deactivate Optrion once your cleanup round is finished;
the plugin is a tool, not a dependency.

Try it in your browser, right now

Optrion ships with a WordPress Playground blueprint. Click here and a full WordPress
instance boots in your browser with Optrion pre-installed and a demo plugin already active so you have rows to inspect. No server, no commitment.

Source, issues, releases: github.com/mt8/optrion.


Optrion のご紹介 — wp_options を「誰が使っているか」で見える化し、安全に掃除する

WordPress のサイトを長く運用していると、いつの間にか wp_options
テーブルが肥大化していきます。プラグインやテーマは設定値をこのテーブルに書き込みますが、停止・削除してもレコードは残り続け、しかもその多くは
autoload = yes としてすべてのページ読み込みに同乗します。標準の WordPress
には、「どの行がまだ使われているのか」「どのプラグインやテーマが作ったのか」「消して安全か」を判断する手段がありません。

Optrion は、まさにこの問題を解決するための GPL ライセンスの WordPress プラグインです。

観察 → 判断 → 隔離 → 削除

Optrion は、推測に頼らずにクリーンアップできるよう、4段階のワークフローを軸に設計されています。

  1. 観察(Observe)wp_options のすべての行に対して option_{$name} フィルターを動的に登録します。get_option() が呼ばれるたびに PHPのバックトレースを辿り、使用元のプラグインやテーマを特定し、last_read_atを記録します。プレフィックスによる推測ではなく、スタック上の実際の呼び出し元を捉えます。
  2. 判断(Judge) — 管理画面は、アクセサ(使っている主体。無効化されていればバッジを表示)、autoload、サイズ、最終アクセス時刻を、独立したソート可能な列としてそのまま表示します。不透明な「スコア」に丸め込まず、判断はあなたが行います。
  3. 隔離(Quarantine) — まだ削除する決心がつかない? Optrion は対象行を_optrion_q__ プレフィックス付きにリネームし、元の名前に対するpre_option_{name} フィルターで保管された値を透過的に返します。隔離した瞬間にサイトが壊れることはありません。
    観察期間中にアクセスがあれば記録し、UI に「使用中 — 復元してください」のバッジを出して自動失効を停止します。
  4. 削除(Delete) — 隔離期間中に一度もアクセスされなかった場合にのみ、恒久削除ボタンが有効になります。

パフォーマンスへの配慮

トラッキングは、管理者がダッシュボードを開いた時点から 10分間だけ自動的に有効になります。
フロントエンドでは動作せず、常時稼働もしません。
読み取りはメモリにバッファリングされ、shutdown 時に 1 回の upsertでまとめて書き込まれます。
管理画面には「掃除が終わったら Optrion を停止してください」と常時表示されており、常駐するタイプのプラグインではありません。

ブラウザで試せます

Optrion には WordPress Playground 用のブループリントが同梱されています。
こちらをクリックすると、Optrion と確認用プラグインがインストール済みのWordPress がブラウザ内で起動します。
サーバー不要、インストール不要で、すぐに挙動を確認できます。

ソースコード・Issue・リリース: github.com/mt8/optrion

WordCamp Kansai 2025 ふりかえり

2025年11月1日(土)〜2日(日)に開催された WordCamp Kansai 2025 に実行委員として参加しましたので、ふりかえり記事をここに残しておきたいと思います。

私の役割としては、委員長チーム・スポンサーチーム・会場/当日チームを担当しました。
また、自社株式会社Webの相談所はブロンズスポンサーとして参加しました。

今回の WordCamp はイベント全体を通して、関西の WordPress コミュニティらしさを感じられるいい WordCamp だったのではないかと思っています。

その証拠に開催から1週間が経過した今でも、X のハッシュタグ #wckansai2025 に「ふりかえりのブログ記事を投稿した!」というポストがあることは、実行委員としてとてもうれしいことです。(ふりかえりブログ記事一覧は公式サイトにもまとめられています。)

参加者のみなさんにお願いしたアンケートにも快くご回答いただき、満足の声を続々と寄せてもらって、安堵しています。本当にありがとうございます。

私はYouTubeにアップロードされたセッション動画をゆっくりと視聴しながら、停滞している仕事に追われる日々を過ごしています。

アフター・ドラマで日本初開催の WordCamp としてのふりかえり

WordCamp Kansai 2025 は WPDrama が起こった WordCamp US 2024 (2024/09/20)よりも前から企画が進められていました。

運悪く?このタイミングに当たってしまった WordCamp の実行委員としてはこの点にも触れておかないといけないという想い、そして日本国内で開催されるこれからのWordCamp のために私たちが何をしてきたのかを残しておきたいと思います。

この記事にたどり着いた人の中には、通称「WPDrama」をご存知でない人も多いと思うので、その場合は国内で最も信頼できる WordPress メディアの Capital P の記事をどうぞ。

会場予約・予算レビュー

「WordCamp を開催するぞ」という気持ちだけでは、WordCamp Central へ開催予定を掲載することはできず、金額の最も大きい会場の予約やイベント全体の予算計画の審査を経ていくことになりますが、ドラマ直後の最も混乱したタイミングと重なって、とても複雑な気持ちで進めたことをよく覚えています。

WordCamp の予算レビューを担当してくれる Automattic の担当の人には「グローバルスポンサーの費用をあまりあてにせず、ローカルでしっかりスポンサーを集めるように」と言われる中、WordCamp にはドラマの影響で様々な方針変更が加えられてくことになったのでした・・・。

参加者への変更点(2024/12/20あたり)

WordCamp の参加チケットを購入するには WordPress.org へのアカウント登録が必須となりました

この変更は一部の WordCamp 参加者への参加ハードルを引き上げ、主催者としては制限の多いWordCampサイトの中で、せめてもと注意文を掲載する対応を実施しました。

WordCampに参加するためにチケットを購入するにはWordPress.orgへのアカウント登録が必須となったせいでWordCampのチケット購入ページに掲載された注意文。「チケットの購入にはWordPress.orgのアカウントが必須となります。こちらのリンクより事前に作成をお願いします。」と記載されている
WordCampに参加するためにチケットを購入するにはWordPress.orgへのアカウント登録が必須となったせいでWordCampのチケット購入ページに掲載された注意文。

参加者としてチケット購入をしようと思ったら、WordPressのログイン画面が表示された時にどのように感じるでしょうか?

ある人は、ご自身の管理する WordPress のユーザーID・パスワードを入力してエラーになり、またある人は「なんでイベントに参加するためによく分からない WordPress にユーザー登録をしないといけないの?」と思ったことでしょう。
そして、パイナップルをピザに〜云々のチェックボックスの意味が分からずに離脱してしまった人もいるでしょう。

参加者アンケートにもその点について触れる声を寄せて頂いていますが、実行委員としては何も手を討つこともできず、「 WordCamp は変わった・・・」としか言えなかったもどかしさがあります。

※ちなみに、経緯・目的は依然としてすっきりしない感じです

※ WordCamp と同じく、WordPress 公式コミュニティの WordPress Meetup への参加には WordPress.org へのアカウント登録の必要がありません・・・。

スポンサーへの変更点(2025/1/1から)

事前に聞いていたものの、Matt 氏からのお年玉となった、

今後の WordCamp スポンサーは全部俺たち( Matt 氏 & Mary 氏 )が審査するよ宣言

・・・正直なところ、頭を抱えました。

WordCamp の予算レビューを担当してくれる Automattic の担当の人にも「一部の国ではスポンサー集めに苦戦している」ということを聞かされる一方で、ほんのり厳しくなったことを感じさせる予算レビューでは、「やりたいことを全部やるならローカルのスポンサーを集めよ」とのプレッシャーもありました。

例年 WordCamp にスポンサーとして参加してくれる企業さんには、スポンサー申し込みを開始する前から事前に連絡して経緯を説明したり、実行委員内で事前審査をしたりもしました。

いちボランティアが企業の Web サイトをチェックし、 WordPress という単語・ WordPress ロゴの使用状況をチェックし、修正依頼をする・・・。

・・・正直なところ、「これはボランティアでやっていいことなのか?」と何度も思いました。(今でもその思いは変わらず

最終審査は Matt 氏・Mary 氏のどちらかで行われているらしいが、多忙な彼らが世界中の WordCamp スポンサーをくまなく審査する余裕があるはずもなく、実際は Automattic の社員が日本語の Web サイトを翻訳しながら「仮チェック」をしていく運用がおこなわれていました。

その「仮チェック」の結果をそのままスポンサーに伝えるべきか、実行委員内で解釈を汲み取ってから伝えるか、いろいろな悩みがありました。(なんせ相手は機械翻訳で審査して、機械翻訳で変更指示を伝えてくる。)

・・・正直なところ、「これはボランティアでやっていいことなのか?」と何度も思いました。(今でもその思いは変わらず

そんな中でも、WordCamp を支えてくれるためにご対応いただき、参加いただいたスポンサー企業のみなさまには心からの感謝を申し上げたいと思います。本当にありがとうございました。

また、WordPressコミュニティとしては「WordPress に関連するビジネスを展開していない企業の方が審査が通りやすく、スポンサーになりやすい」という事実と向き合う必要があると思っています。

これは、WordPress に関連するビジネスを展開していない企業であれば、100%GPLの宣誓や商標の問題を難なく乗り越えることができてしまうということですが、そのような企業が WordCamp のスポンサーになること自体は何の問題でもなく、結局はその時の実行委員が判断するしかありません。
関連ビジネスを展開していなくても、 WordPress ユーザーとして応援してくださる企業さまもいらっしゃいますしね。

どのような企業が WordCamp へのスポンサーになるのがふさわしいかについては、WordCamp オーガナイザーハンドブックの資金の調達ページに記載されている内容を引用しつつ自分の想いを書き出しておくことにしますので、あなたが判断に迷ったときに思い出してもらえると嬉しいです。

スポンサーの金銭的支援は寄付金であり、イベントを応援するために支払われるものです。資金を提供してくれる方々を「スポンサー(出資者)」と捉えるのではなく、「サポーター(支援者)」と考えましょう。

実行委員内部でも「スポンサー」ではなく「サポーター」と呼ぼうか?という意見はありました。

過去のイベントにおいてこういった企業はスポンサーと呼ばれ、WordCamp 運営チームによって様々な段階のスポンサーシップレベルが設定されていました。貢献する金額のレベルが上がるほど特典(多くはマーケティング向け)が高くなるというケースが一般的でした。しかし、この傾向によって多くの WordCamp が商業的になりすぎるという弊害が生まれました

「商業的になりすぎた WordCamp 」はあまり見たくないと個人的には思っています。

スポンサーになってもらう企業に金銭的支援をしてもらう対価としてイベントの参加者に対してマーケティングや広告をしても良いという考え方はしないでください。こういったことをすると、結果的には WordCamp のスポンサーシップが広告の購入であるという形になり、WordCamp Foundation や WordCamp 運営チームの非営利性が失われることにつながります。

ローカルの WordCamp はビジネスイベントではないので、参加者としてもスポンサーとしても、こういった商業的な目的での参加は Flagship WordCamp と呼ばれる WordCamp への参加をお勧めするのがよさそうです。
WordCamp Asia 2025(フィリピン・マニラ)・WordCamp EU 2025(スイス・バーゼル)・WordCamp US 2025(ポートランド・アメリカ)と2025年に開催されたFlagship WordCamp 全てに参加した者としての意見です。

最後に

「せっかく楽しかったイベントなのに愚痴っぽい」と感じられてしまったら大変申し訳ありませんが、私個人的には今後の日本国内での WordCamp が都市圏だけではなく、以前のように地方でも開催されることを楽しみにしていますし、そのために協力できることがあれば、これからも喜んでお手伝いしたいという前向きな気持ちでいます。

WordPressプラグイン「BASE Item List」をバージョン2にアップデートしました

BASEのAPIを使って商品情報をWordPressに埋め込むことができるプラグイン「BASE Item List」をアップデートしました。

主な変更点としては、検索APIの新規受付を停止したことによるAPI認証方式の変更です。

検索APIはいろいろ問題があったらしく、BASEさんから直接お問い合わせを頂くこともあり、今回のアップデートに至りました。

V2にアップデートするとAPI認証をやり直す必要があります。

プラグイン設定画面に新方式のAPI認証の説明を記載しているので、移行をお願いします。

BASE Item List V2の設定ページのスクリーンショット

ショートコード[BASE_ITEM]はそのまま使えますが、パラメータがAPI仕様にもとづいて変更になったので注意してください。

最後に

本プラグインへのサポートについて。

本プラグインはWordPress.orgに公式プラグインディレクトリにオープンソースとして公開しています。

無償で公開していますが、設置サポート等はすべて有償にて承っております。

設置サポートについては、BASE APIの登録が終わっている状態で、ショートコードを利用した商品リスト表示(デフォルトテンプレート使用)まで一律 33,000円(税込)となります。

上記ご確認頂き、お問い合わせフォームより送信をお願いします。

Simple GA Ranking For Shifter Static

Shifter Advent Calendar 2020の20日目の記事。Simple GA RankingをShifter Static でも使いたい!という検証です。

この記事はShifter Advent Calendar 2020の20日目の記事です。

Shifterって?という方はShifterの中の人の赤塚さんによる1日目の記事を読むとよいでしょう。


Simple GA Ranking ?

Simple GA RankingはWordPressとGoogle Analyticsを連携させて人気記事ランキングを取得するプラグイン。

Google Analyticsからデータを取得するので、記事へのアクセスごとにデータベースに書き込むプラグインと比べて軽量に動作する。

公式サイトにはマニュアル動画も用意されていて、セットアップもこの手順通りにやればだいたい迷わずに設定できる。

Simple GA Ranking の設定マニュアル動画。クセになるBGMだ。

mt8もプラグインメンテナーとしてこのプロジェクトに参加している。(更新ができていないのは追々、、、)

Shifter Static でも使える(、、だが!)

Shifter StaticでもSimple GA Rankingを設定して使用することは可能だ。

ただし、表示されるランキングはShifterでジェネレート(静的書き出し)を行った時点で取得したものとなる。

つまり、ジェネレートを頻繁に行わないサイトの場合だとランキングの表示が次にジェネレートするまで変わらないということになる。

・・・惜しい。これはどうにかしたい。

Shifter Staticで静的化されたWordPressサイトからGoogle Analyticsの最新データが取得できれば人気記事だけではなく、関連記事なども実現できる可能性がある

これはどうにかしたい、、、!


ちなみに

静的化する上で避けられないWordPress運用における動的処理の代表格である「お問い合わせフォーム」・「サイト内検索」・「コメント」については

Shifterが公式ブログで外部サービスとの連携する方法を紹介してくれているので是非確認してほしい。

https://support.getshifter.io/en/collections/1394677-contact-forms

https://support.getshifter.io/en/articles/762156-integrating-algolia-search-with-wordpress

https://support.getshifter.io/en/collections/1394686-wordpress-comments

解決したい内容を整理してみる

「Shifter Staticで人気記事ランキング」を実現させるために必要となる要件を書き出しておく。

  • 静的化されたサイトに人気記事ランキングを埋め込む
  • ランキングデータはGoogle Analyticsと連携する
  • サイトアクセス時の最新のランキングを表示する

以上を実現するために、この記事ではSimple GA Ranking for Shifter Staticができないか実験していく。


Simple GA Ranking for Shifter Static

STEP1:WordPressの設定

Shifterにサインアップ・サイト追加をし、WordPressを立ち上げたらパーマリンク設定を以下にしておいた。

/%post_id%/

これで https://example.com/{記事ID}/ で静的書き出しが行われる。

STEP2:Google Analyticsアカウント

アカウント作成時の注意点としては「プロパティ」をユニバーサルアカウントとして作成すること。

手順は以下

①、「プロパティの設定」で”詳細オプションを表示”する

「プロパティの設定」から、詳細オプションを表示する

②、「ユニバーサルアナリティクス プロパティの作成」にチェックを入れる

「ユニバーサルアナリティクス プロパティの作成」にチェックを入れる

STEP3:カスタムディメンションの設定

記事の詳細ページへのPVのみをランキングデータとするためにGoogle Analyticsのカスタムディメンションを設定しておく。

ここでは次のように設定しておいた。

名前post
範囲ヒット
アクティブチェック(有効化しておく)
カスタムディメンションの設定
カスタムディメンションを定義

この設定をしておくことでGoogle Analyticsに記事詳細ページのPVであることを明示的に送信することができる。

作成したカスタムディメンションの「インデックス」の数値はこのあと使うので覚えておく。(スクショの場合は1)

STEP4:WordPressからGAにPVカウントを送信

以下のコードで、記事詳細へのアクセス時にGoogle AnalyticsにPVカウントを送信した。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-1-php

参考記事:gtag.jsでページビューのときにカスタムディメンション送信

カスタムディメンションが意図した通りに送信されているかは

Google Analtytics > 行動 > サイトコンテンツ > すべてのページ にアクセスし

「セカンダリディメンション」から作成したカスタムディメンションを選択する


もしくは、公式レポートツールのQuery Explorerを使ってもよいだろう。

次のようなパラメータで実際にサイトで取得したいランキングを問い合わせてみる。

idsga:から始まるビューID
start-dateyesterdayPV集計期間From
end-datetodayPV集計期間To
metricsga:pageviewsPVを取得
dimensionsga:pagePath, ga:pageTitleパス, タイトルを取得
sort-ga:pageviewsPVの降順で取得
filtersga:dimension1==postカスタムディメンションはpost

実行してデータが取得できていればカスタムディメンションが計測されていることになる。


Google Analytics APIをどのように実行するか

サイト訪問者がアクセスした時点でのランキングをリアルタイムに表示させたいので、Google Analytics APIはブラウザ側(javascript)から実行させることにする。

しかし、通常API実行のためのアクセストークン取得にはOAuth2認可を行う必要がある。これにはGoogleログインが必要で取得できるトークンには期限がある。

また、javascriptはソースコードが公開されるため、取得したトークンをソースコードで公開するのは問題がある。

そんなときに、GoogleのEmbed APIのページにServer-side Authorizationというページを見つけた。

具体的には以下のような手順となっていた。

  • GCPでサービスアカウントを発行しキーのjsonファイルを取得する
  • GAでサービスアカウント 発行時に作成されたメールアドレスに表示と分析権限を付与する
  • サービスアカウントのキーjsonファイルからサーバーサイドでAPIへのアクセストークンを取得する

※サービスアカウント 取得からAPI実行まではこちらの記事が参考になる:【2019年版】Google Analytics API v4 の使い方(PHP)

この例では取得したトークンをjavascriptソースに記述するようになっており、注釈として以下が添えられていた。

Important!  When you add an access token to the source code of your page, your site’s visitors could use that access token to run any query the service account could run. If your account contains sensitive information, considering adding the service account only to a specific view. You may also want to add a view filter to limit what data the service account can access.

Embed API Server-side Authorization

・・・サーバーサイド?

サーバーレスなShifterを使っているのにサーバーを用意するなんてとんでもない

そこで、今回は以下のようなAPIをserverless frameworkで構築することにした。

  1. サービスアカウントのAPIアクセストークンを取得
  2. アクセストークンを使ってGoogle Analyticsからランキングデータ取得

(このAPIを SGA4SS API と呼ぶことにする。)

SGA4SS APIをserverless frameworkで構築

serverless framework ?

Serverless Advent Calendar 2020の18日目の記事:Serverless Framework はじめの一歩という記事を読んでみるといいだろう。

ここではserverless frameworkの詳しい解説はしないが、ソースコードはGithubに上げておいた。

https://github.com/mt8/sga4ss

※なんでPython?:Embed APIのサーバーサイド認証のサンプルコードがそうだったから

このAPIの注意点

実際にAPIを公開するときにはスロットリングやキャッシュなどをきっちり管理した方がよいと思われる。(APIのURLは公開するので誰でも実行可能)

GA側ではフィルタ機能などを使って、「見られてもいいビュー」を作っておくのがよいと思われる。

***ご利用は自己責任でお願いする***


SGA4SS WordPress Pluginでデータ取得・表示

用意したSGASS APIはWordPress側では [sga4ss] というショートコード でデータを取得してリスト表示することにした。

コードは以下のようなものになる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-2-php

・・・記事ランキングにアイキャッチ画像も付けたい

アイキャッチの取得についてはShifterの場合だと少し工夫が必要だった。

なぜならGoogle Analyticsから取得できるのはページパス(投稿ID)だけで、javascriptからでは投稿IDだけ取得できてもアイキャッチ画像を取得することはできない

Shifterサポートのお兄様たちに相談したところ、以下の方法を教えてもらった。(1時間で解決した)

①、/wp-json/wp/v2/posts/{ID} にアイキャッチ画像のURLを含める

以下のコードで、WP REST APIの/posts/{ID}にアイキャッチ画像のURLを追加することができる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-3-php

②、/wp-json/wp/v2/posts/{ID} も静的書き出し対象に含める

以下のコードでShifterの静的ファイル出力対象にアイキャッチがある投稿については/post/{ID}をjsonファイルとして含めることができる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-5-php
参考:Appending URLs to the artifacts

これでGA APIから取得した投稿IDからアイキャッチ画像を取得することができた。

抜粋になるが、コードだと以下の部分になる。

https://gist.github.com/mt8/42b9bf291a968a29a161608f85ce2677#file-6-js

最後に

実際にShifter Staticで書き出したサイトを貼っておく。

ページ最下部の人気記事ランキングの部分が紹介した方法で実装した部分だ。

https://dazzling-mestorf7276.on.getshifter.io/

いつまで残すかは未定

今回作ったコードは以下に上げているので同じようなことにチャレンジする人の参考になれば嬉しい。

SGA4SS API (Serverless framework): https://github.com/mt8/sga4ss

SGA4SS (WordPress Plugin): https://github.com/mt8/sga4ss-wp

***ご利用は自己責任でお願いする***

WordPressの書籍を執筆しました。

WordPressの書籍を執筆しました。