Product Updates Statnive プラグイン · Parhum Khoshbakht

141 件のテスト、31 件のコンプライアンスチェック、ゼロの近道: Statnive を出荷する方法

ほとんどの WordPress プラグインはリンターを実行して終わりにします。Statnive はリリース前に、pre-commit フックから WordPress.org コンプライアンスゲートまで 5 層の自動検証を通過します。何をチェックし、なぜチェックするのかを正確にお伝えします。

プラグインをインストールするとき、あなたは他人のコードを信頼しています

有効化したすべての WordPress プラグインは、データベース、管理画面、訪問者データへのフルアクセス権を得ます。ほとんどのプラグインページは、星評価と「最終更新」日を表示します。それは信頼の判断を行うのに十分な情報ではありません。

私たちは、自分のサイトでも信頼できるアナリティクスプラグインとして Statnive を構築しました。本記事では、Statnive のすべてのコード行が WordPress インストールに到達するまでに通過する正確な品質パイプラインをご紹介します。曖昧な主張は無し、具体的なチェック、実数、そして自動テストが捉えられること・捉えられないことについての正直な注意点です。

ヘッドラインの数値: 141 件の PHP ユニットテスト、31 件の WordPress.org コンプライアンスセクション、10 件の専門 CI ゲート、3 件の PHP バージョンターゲット、すべてのビルドで強制される 5KB のトラッカーサイズ予算。

レイヤー 1: pre-commit フック — リポジトリにチェックなしで何も入らない

コードが Git リポジトリに入る前に、pre-commit フックがすべてのステージングファイルに対して 2 つのチェックを実行します。

PHP の変更について:

  1. PHPCS (PHP CodeSniffer) は、ステージングされたファイルを WordPress Coding Standards と照合します。これは WordPress コアと同じルールセットです。これは安全でない出力エスケープ、不足しているサニタイズ、非標準のコードパターンを捕捉します。
  2. PHPUnit がフルユニットテストスイートを実行します。141 件のテストすべてがパスする必要があります。1 件でも失敗するとコミットがブロックされます。

TypeScript / JavaScript の変更について:

  1. Vitest がすべての React コンポーネントテストを実行します。ダッシュボード UI はここで捕捉されずに退化することはできません。

pre-commit フックは意図的に高速で、開発マシン上で 5 秒未満で実行されます。CI を置き換えるのではなく、GitHub までの往復を浪費する前に最も一般的なミスを捕捉することが目的です。実際には、この単一ゲートは開発者のラップトップを離れる前に問題の概ね 80% を捕捉します。

レイヤー 2: 継続的インテグレーション — プッシュごとに 6 並列ジョブ

開発ブランチまたは main ブランチへのすべてのプッシュ、およびすべてのプルリクエストが、6 並列ジョブの GitHub Actions CI パイプラインをトリガーします。

ジョブチェック対象重要性
Lint (PHP 8.2、8.3、8.4)PHPCS + PHPStan level 63 つの PHP バージョンにわたるコーディング標準と静的型安全性
Unit Tests (PHP 8.2、8.3、8.4)PHPUnit スイート3 つの PHP バージョンにわたるロジック正確性
Minimum Floor Smoke (PHP 8.0)構文 lint + オートローダーブート宣言した最小 PHP バージョンでプラグインが読み込まれることを証明
Tracker BuildVite ビルド + gzip サイズチェックアナリティクストラッカーの 5KB gzip 予算を強制

なぜ 4 つの PHP バージョンか

WordPress サイトは現実世界では PHP 8.0 から 8.4 で動作します。PHP 8.4 で動く関数が PHP 8.0 では異なる挙動になることがあります。デフォルトのパラメータ値、型強制ルール、非推奨の機能はすべてバージョン間で異なります。私たちはフルテストスイートが動く 3 つのバージョン (8.2、8.3、8.4) でテストし、別途 PHP 8.0 — プラグインヘッダーで宣言した最小値 — でも本番コードが少なくとも構文解析・起動できることを検証します。

5KB のトラッカー予算

サイト上でページビューを収集する JavaScript トラッカーには、厳密なサイズ制限があります。5,120 バイト gzipped です。すべてのビルドで出力を計測し、トラッカーがその予算を超えるとパイプラインが失敗します。これは恣意的ではありません。私たちのパフォーマンスベンチマークは、トラッカーサイズが LCP 影響と直接相関することを示しました。予算がクリティカルパスを最小限に保ち、必須でない機能を非同期セカンダリスクリプトへ遅延させることを強制します。

# From our CI workflow — the tracker size check
- name: Verify tracker size
  run: |
    MAX_SIZE=5120  # 5KB in bytes
    GZIP_SIZE=$(gzip -c public/tracker/statnive.js | wc -c)
    if [ "$GZIP_SIZE" -gt "$MAX_SIZE" ]; then
      echo "::error::Tracker size (${GZIP_SIZE}B) exceeds limit (${MAX_SIZE}B)"
      exit 1
    fi

PHPStan level 6

PHPStan はコードを実行せずにバグを見つける静的解析ツールです。Level 6 (10 段階中) は型の不一致、未定義の変数、誤った戻り値型、デッドコードパスを捕捉します。私たちは phpstan-wordpress 拡張機能とともに実行しており、これは WordPress フックのシグネチャ、フィルタの戻り値型、$wpdb メソッドの契約を理解します。$wpdb->prepare() の強制と組み合わせることで、これは SQL インジェクションへの主要な防御線となります。静的解析器は、プリペアドステートメントを使う代わりにユーザー入力を連結するクエリにフラグを立てます。

レイヤー 3: WordPress.org コンプライアンス — 10 件の専門ゲート

ここが、Statnive の品質パイプラインがほとんどの WordPress プラグインから離れていく地点です。標準的な lint とテストを超え、WordPress.org プラグインガイドラインを強制する 10 件の専用コンプライアンスゲートを実行します。これらは、提出時にレビューチームが手動でチェックするのと同じルールです。

ほとんどのプラグイン開発者は、提出が拒否されたときに初めてこれらのルールを発見します。私たちはそれらを自動化し、違反がコミットごとに捕捉されるようにしました。

セキュリティゲート

ABSPATH ガード — すべての PHP ファイルは実行前に defined('ABSPATH') をチェックする必要があります。これにより、URL を介したプラグインファイルへの直接アクセスが防止されます。直接アクセスはサーバーパスを漏洩したり、WordPress コンテキスト外でコードを実行したりする可能性があります。私たちのゲートはソースツリー内のすべての .php ファイルをスキャンし、ガードのないファイルがあれば失敗します。

禁止パターン — 自動スキャンは WordPress.org が明示的に拒否する危険な PHP 関数をブロックします。eval()、exec()、shell_exec()、system()、passthru()、curl_init() です。また、PHP の短いタグ、生の json_encode() (wp_json_encode() を使う必要があります)、ハードコードされた wp-content パスも捕捉します。

WP API コンプライアンス — すべてのスクリプトとスタイルシートが、ハードコードされた <script> や <link> タグではなく、WordPress の enqueue システムを使うことをチェックします。また、サニタイズされていないスーパーグローバルアクセス ($_GET、$_POST、$_REQUEST) もスキャンします。これは WordPress.org がプラグイン提出を拒否する主要な理由の 1 つです。

整合性ゲート

Readme とバージョン整合性 — プラグインバージョンは 3 か所で一致する必要があります。readme.txt の Stable tag、statnive.php ヘッダー、PHP 定数 STATNIVE_VERSION です。不一致は WordPress が誤ったバージョン番号を表示することを意味します。これはユーザーを混乱させ、レビュアーへの危険信号になります。このゲートはまた、タグ数 (最大 5)、短い説明の長さ (最大 150 文字)、LICENSE ファイルの存在、External Services 開示セクションも検証します。

配布 ZIP の検証 — WordPress.org にアップロードされる実際の ZIP ファイルをビルドし、その内容を検証します。必要なファイルが存在する必要があります (statnive.php、readme.txt、LICENSE、src/Plugin.php、未圧縮トラッカーソース)。禁止ファイルが存在してはなりません (node_modules/、.git/、composer.json、tests/、phpunit、設定ファイル)。ZIP サイズは 25MB 未満である必要があります。

ヘッダーパリティ — 11 件の必須プラグインヘッダーフィールドがすべて存在し、整合していることを検証します。Tested up to の WordPress バージョンが現在の安定版の 2 マイナーリリース以内であることをチェックします。古い値は未保守のプラグインを示し、WordPress.org の検索順位に影響します。

アーキテクチャゲート

アーキテクチャブロッカー — ポリシー違反を示すパターンをスキャンします。有効化フック内のフォンホーム HTTP コール (ユーザーはプラグイン有効化時にネットワークリクエストを見るべきではありません)、カスタム自動更新フック (WordPress.org が更新を扱います)、バンドルされた MaxMind GeoIP データベース (ユーザーは独自のライセンスキーを提供する必要があります) です。

フリーミアム境界 — 無料の WordPress.org 版にはライセンスゲーティングコードを含めてはなりません。このゲートは isPro()、checkLicense()、trial_expires、premium_only のようなパターンをスキャンし、.org ビルドが本物の無料版であり、機能制限されたトライアルではないことを保証します。

外部サービス監査 — PHP ソースコードで参照されるすべての https:// ドメインを抽出し、それぞれが readme.txt の External Services セクションで文書化されていることを検証します。文書化されていない外部接続があるとビルドが失敗します。これが、データの流れる先について透明性を保証する方法です。

Statnive を入手: 信頼できるコード

本記事で説明したすべてのチェックは、すべての変更で自動的に実行されます。誰もセキュリティスキャンを実行することやバージョン整合性をチェックすることを覚えておく必要はありません。パイプラインがそれを強制します。WordPress.org から Statnive をインストールし、結果をご覧ください。あなた自身のサーバー上で動く、高速かつプライベートなアナリティクスです。

レイヤー 4: WordPress Plugin Check — 求められる以上に厳格に

Plugin Check (PCP) は WordPress.org チームが提供する公式ツールで、レビューチームが使用するのと同じ自動チェックを実行します。ほとんどのプラグインはエラーのみで失敗するように PCP を設定します。

Statnive はエラーと警告の両方で失敗します。

これは意図的な選択です。PCP の警告は、提出を技術的にブロックしないものの、時間とともにプラグイン品質を劣化させる正当な問題、つまり非推奨関数の使用、アクセシビリティの欠落、パフォーマンスの懸念、をしばしばフラグ付けします。警告をエラーとして扱うことで、他のプラグインが見過ごす問題を捕捉できます。

PCP ゲートはソースツリーではなく、ビルドされた配布ディレクトリ上で、PHP 8.0 — 宣言した最小値 — を使って実行されます。これは、ユーザーがインストールするのと正確に同じものを、サポートする最古の PHP バージョンでテストすることを意味します。

レイヤー 5: リリースゲート — どのバージョンも 31 セクションを通過

リリース前に、フルゲートが上記すべてを 1 つの合否判定に統合します。

静的テストゲート (すべて合格必須):

ゲートチェックツール
S-1WordPress Coding StandardsPHPCS
S-2静的型解析PHPStan level 6
S-3PHP ユニット + 結合テストPHPUnit
S-4React コンポーネントテストVitest
S-5公式 Plugin CheckPCP (errors + warnings)

コンプライアンス grep ゲート (17 件の自動パターンチェック):

ゲート強制内容
C-1すべての PHP ファイルでの ABSPATH ガード
C-2LICENSE ファイル検証
C-3、C-4有効化時のフォンホームなし、隠れた有料壁なし
C-5Readme 構造、バージョンパリティ、外部サービス開示
C-6サニタイズされていないスーパーグローバルアクセスなし
C-7バンドルされた GeoIP データベースなし
C-8、C-9、C-10カスタム更新機構なし、コアライブラリの同梱なし、外部 CDN なし
C-11、C-12無効化時の Cron クリーンアップ、uninstall 関数の存在
C-13SVN assets ディレクトリ構造
C-14ZIP の整合性とサイズ
C-15データベーステーブル作成が dbDelta フォーマットに従う
C-16ユーザー向け文字列がすべて国際化対応されている
C-17WordPress Privacy API フックが登録されている

自動ゲートに加えて、各リリースは手動レビューを含みます。これはパフォーマンス予算、ブラウザ互換性、アクセシビリティ (WCAG 2.2 AA)、管理 UX の明確さ、アップグレード・移行の安全性、失敗時の処理を扱います。フルチェックリストは 3 つの重大度レベルにわたる 31 セクションに広がります。

  • CRITICAL — リリースパイプラインをブロックする自動ゲート
  • RELEASE BLOCKER — バージョンタグ付け前にパスする必要がある手動チェック
  • QUALITY GATE — 自分たちに課す標準で、レビューはするが助言的なもの

セキュリティとプライバシー: 約束ではなく、パイプラインによる検証

多くのアナリティクスプラグインがマーケティングページにセキュリティとプライバシー機能をリストアップします。私たちはそれらの約束が機械的にどのように強制されているかをお見せします。

すべての SQL クエリはプリペアドステートメントを使用。 PHPStan の WordPress 拡張は、$wpdb->prepare() を使う代わりにユーザー入力を連結するすべての $wpdb メソッド呼び出しにフラグを立てます。これはコードが実行される前、静的解析の段階で捕捉されます。

クッキー、localStorage、フィンガープリンティングなし。 コンプライアンスゲートはクッキーをセットする関数とブラウザストレージ API をスキャンします。ユニットテストスイートは、トラッカーペイロードがハッシュ化された不可逆な訪問者識別子のみを含むことを検証します。

毎日ローテーションするソルト。 同じ訪問者は毎日異なるハッシュを生成し、日をまたいだ追跡を防ぎます。ソルトのローテーションを越えてハッシュの一意性を検証する専用のユニットテストでカバーされています。

トラッカーペイロードへの HMAC 署名。 すべてのページビューヒットはサーバー生成キーで署名されます。署名検証はユニットスイートでテストされ、無効または改ざんされたペイロードは拒否されます。

外部サービスの透明性。 CI ゲートはソースコードからすべての外部ドメインを抽出し、readme.txt の開示に表れていることを検証します。開発者が新しいドメインへの HTTP コールを追加すると、ドメインが文書化されるまでビルドが失敗します。

自動テストが捉えられないもの

私たちは能力だけでなく、限界についての透明性も信じています。

自動テストは、既知の条件下でコードが正しく振る舞うことを検証します。次のものは捕捉できません。

  • 微妙な UX の混乱 — 技術的には正しいが、技術者でないユーザーには誤解を招くダッシュボードチャート
  • パフォーマンスのエッジケース — 1,000 行で高速だが 100,000 行で劣化するクエリ。クリティカルパスには k6 負荷テストがありますが、すべてのデータ形状をカバーすることはできません
  • WordPress エコシステムの競合 — 特定のホスティング構成でしか表面化しないプラグインやテーマの相互作用。WP 6.4 から trunk までテストしていますが、WordPress エコシステムには 60,000 以上のプラグインがあります
  • ゼロデイ脆弱性 — どれだけ静的解析しても、未知の攻撃ベクトルの悪用は防げません

これらのギャップは、リリースごとの手動レビュー、誰でもコードを監査できる公開 GitHub リポジトリ、現実のインストールからの報告を求める WordPress.org サポートフォーラムの能動的な監視で緩和しています。

なぜこれを公開したのか

研究によれば、WordPress プラグイン開発者の 50% 以上が、公開開示前に報告された脆弱性をパッチしません。プラグインは何年も更新されないことがあります。ユーザーが、よく保守されているプラグインと放棄されたプラグインを区別する手段は、星評価と「最終更新」日しかありません。

WordPress エコシステムはより良いシグナルに値すると考えています。私たちの品質パイプラインを公開することは、私たち自身 (公開された以上、こっそりチェックを飛ばすことはできません) と、エコシステム (他のプラグイン開発者が同様のプラクティスを採用できます) の双方に対して、基準を引き上げる 1 つの方法です。

WordPress サイト用のアナリティクスプラグインを評価しているなら、すべての候補に尋ねることをお勧めします。どのようにテストしているか? リリース前にどのチェックが実行されているか? CI 設定を見せてくれるか?

Statnive のコードベース全体は GitHub 上でオープンソースです。本記事で説明したすべてのワークフローファイル、すべてのテスト、すべてのコンプライアンスゲートは公に監査可能です。

Statnive を試す

このエンジニアリングのすべては、1 つの目的に奉仕します。あなた自身の WordPress サーバー上で信頼できるアナリティクスを提供することです。サードパーティへのデータ転送はなく、クッキーもなく、サイトを遅くする追跡スクリプトもありません。

WordPress.org から Statnive を無料インストール — データはサーバーに留まり、リリースごとに 141 件のテストと 31 件のコンプライアンスチェックで検証されます。

Statnive を無料で入手